Skip to content

Not only module imports should be tested, but python -m too #92563

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
arhadthedev opened this issue May 9, 2022 · 2 comments
Closed

Not only module imports should be tested, but python -m too #92563

arhadthedev opened this issue May 9, 2022 · 2 comments
Labels
tests Tests in the Lib/test dir type-feature A feature request or enhancement

Comments

@arhadthedev
Copy link
Member

Currently all (of the most of, need verification) modules are tested for imports only.

However, if __name__ == "__main__" path needs to be tested as well to avoid bugs like gh-92546 (reported for 3.10 but also affects 3.11b1).

@arhadthedev arhadthedev added the type-feature A feature request or enhancement label May 9, 2022
@arhadthedev arhadthedev changed the title Using modules via python -m also should be tested Not only module imports should be tested, but python -m too May 9, 2022
@AlexWaygood AlexWaygood added the tests Tests in the Lib/test dir label May 9, 2022
@rhettinger
Copy link
Contributor

That would be a policy change. Generally, these sections are for internal use and not part of the public API. If someone really cared about _perfcheck(), the would have tested that function directly. One other thought it that some main sections take arguments, so it stops being a trivial matter to exercise them fully.

@arhadthedev
Copy link
Member Author

Thank you for clarification on non-public status of the script sections. However, I've got a question to remove such a confusion for future others:

Generally, these sections are for internal use and not part of the public API

If they are exclusively for CPython developers and contributors, will it be better to strip them from user-deployed modules and put into a dev-only Tools/? Except for really useful tools like tabnanny (with documented "For the time being this module is intended to be called as a script") that can be granted a public, properly documented argparse-based CLI?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
tests Tests in the Lib/test dir type-feature A feature request or enhancement
Projects
None yet
Development

No branches or pull requests

3 participants