[issue7875] test_multiprocessing / importlib failure

Brett Cannon added the comment: Importlib actually already can do this: importlib.test.regrtest. It runs regrtest after importlib has been set for __import__. It also skips tests known to fail for stupid reasons (typically they don't expect __loader__ to be defined). You can also run the impo

[issue7875] test_multiprocessing / importlib failure

Antoine Pitrou added the comment: Option 3 is ok with me. There could also be option 4: add a special flag (or environment var) to regrtest so as to run all tests with __import__ pulled from importlib. Then we can setup a buildbot with that flag / env var. -- ___

[issue7875] test_multiprocessing / importlib failure

Brett Cannon added the comment: So option 3 would marginalize __import__ testing as importlib's finders and loaders as pulled from sys.path_importer_cache would be used over __import__'s own implicit importers that it contains. As for test.support.import_module being the culprit, it is. The r

[issue7875] test_multiprocessing / importlib failure

Antoine Pitrou added the comment: > That would be test_support.import_module, which at your recommendation > I changed to use importlib.import_module at the last pycon sprint :) I don't think it's the culprit. According to the traceback, importlib is triggered by a simple "import xmlrpc.clien

[issue7875] test_multiprocessing / importlib failure

R. David Murray added the comment: I meant test.support for py3k, of course. -- ___ Python tracker ___ ___ Python-bugs-list mailing li

[issue7875] test_multiprocessing / importlib failure

R. David Murray added the comment: That would be test_support.import_module, which at your recommendation I changed to use importlib.import_module at the last pycon sprint :) I'm not clear on why option 3 would interfere with __import__ getting tested? -- nosy: +r.david.murray __

[issue7875] test_multiprocessing / importlib failure

Changes by Brett Cannon : -- dependencies: +importlib not checking bytecode length ___ Python tracker ___ ___ Python-bugs-list mailing

[issue7875] test_multiprocessing / importlib failure

Brett Cannon added the comment: OK, I figured this one out. Someone is using importlib.import_module() which uses importlib itself to do the import and not builtins.__import__. That has the side-effect of importlib replacing all None entries in sys.path_importer_cache with the finder that imp

[issue7875] test_multiprocessing / importlib failure

Changes by Brett Cannon : -- assignee: -> brett.cannon ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://m

[issue7875] test_multiprocessing / importlib failure

Brett Cannon added the comment: I don't know who is doing this, but from what I can tell it isn't test_imoprtlib; running with -i shows __import__ to still be the built-in one along with no new sys.path_hooks entries or stale entries in sys.path_importer_cache. Same goes for when I run test_m

[issue7875] test_multiprocessing / importlib failure

Changes by Florent Xicluna : -- keywords: +buildbot ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.

[issue7875] test_multiprocessing / importlib failure

New submission from Antoine Pitrou : An interesting bug failure on one of the buildbots. It seems importlib has been enabled as the default import mechanism (when? where?). test_multiprocessing Process Process-24: Traceback (most recent call last): File "/home/buildbot/slave/py-build/3.1.nor