GeezerVison

So I'm of two minds on this. One, this was actually done on purpose as the expectation is to run the tests via -m test which does not have any of these issues, e.g. python -m test test_importlib.test_open. And so the entire test suite is kind of viewed as a single unit. Plus I prefer relative imports. 😁

But none of this is also important, so I don't object to this PR either. 🙂 I'll let @corona10 or someone else handle reviewing and merging.

Thanks, Brett.

I think that the main thing here is that most modules are working fine and only some are broken when invoked directly as python Lib/test/*. It might be confusing.

I think that the main thing here is that most modules are working fine and only some are broken when invoked directly as python Lib/test/*. It might be confusing.

That's fair, but I want to be clear that nothing is "broken". There is no general rule that sub-tests need to function as separate execution targets. As I have said, I don't object to the change specifically, but I'm also not going to be the one who merges it either. 😁

For me, on Windows, with fresh 3.11, python -m test.test_importlib.test_open runs the open tests. python Lib/test/test_import/test_open.py (or py ...) in a directory containing Lib fails with the import error above. If I load test_open in an IDLE editor and run it (F5), it also fails, similarly. To me, this is broken. I would feel the same if using any other editor that can run a saved file with an appropriate program.

That's fair, but I want to be clear that nothing is "broken".

Yeah, this word might a bit harsh. Let's not use it 🙂
Instead, I am going to illustrate my motivation behind this change.

Let's say I am newcomer to CPython's source code (which I +- am). And I want to work on some feature/bugfix in importlib. I obviously need to run my tests. Let's say I need Lib/test/test_importlib/builtin/test_finder.py. I read this file and I see unittest.main() in the end. Oh, I know what it does!

But, if I try to run it directly (which this module declare to support) - tests will fail.

I think, it can be improved! And an it is easy to do: change imports, add unittest.main() in some files where it was missing. Done ✨

This change causes problems within the backports (importlib_metadata, importlib_resources). This code is kept in sync with those projects and thus (a) relies on the relative imports to find the fixtures in a relative location and (b) would never expect the modules to be invoked as a script. As primary maintainer of importlib.metadata and importlib.resources, I'd prefer to keep the code portable and simple (encapsulated). It's conceivable that the backport could maintain a forked version of these files that doesn't include these behaviors, but that adds a cognitive and maintenance burden to the effort.

In my effort, the lack of __name__ == '__main__' was intentional and represented a signal that these files were not meant to be executed, but were meant to be invoked through a test runner (i.e. python -m test, python regrtest, python -m unittest discover, or pytest (in the case of the backports)). I'd like to restore that expectation and back out these changes for tests relating to importlib.metadata and importlib.resources. I have less of an opinion on the changes to other importlib modules.

@jaraco thanks! I will send a new PR with restored changes in importlib_metadata and importlib_resources in 10 mins.

@jaraco thanks! I will send a new PR with restored changes in importlib_metadata and importlib_resources in 10 mins.

Thanks sobolevn. I missed your message prior to preparing and submitting #30799. Since it's not clear the demarcation of the tests, I figured it would be better if I helped out with that part. I went through and flagged what I think are the relevant files. I'm going to use that PR to validate that I got the correct files as well (by performing a dry-run sync into the backports).