On 19 July 2017 at 06:40, George Fischhof <geo...@fischhof.hu> wrote: > I think yes ;-) > I would like to use (or I think it would be good to use) something like > pathlib.Path(package_root) > so I could use > > importlib.import_module(pathlib.Path(package_root) / plugins / plugin_name)
No, as that's fundamentally incompatible with how Python's import system works - the filesystem is *a* way of representing package namespacing, but far from the only way. Managing the import state also has nothing whatsoever to do with pathlib. That said, the idea of better encapsulating the import state so we can more readily have constrained "import engines" *is* a reasonable one, it just runs into significant practical problems related to the handling of transitive imports in both Python modules and (especially) extension modules. The last serious attempt at pursuing something like that is documented in PEP 406, "Improved Encapsulation of Import State": https://www.python.org/dev/peps/pep-0406/ Unfortunately, the main outcome of Greg Slodkowicz's GSoC work on the idea was to conclude that that particular approach wasn't viable due to the fact that import system plugins at that time were pretty much required to directly manipulate global state, which ran directly counter to the goal of encapsulation. However, we also haven't had anyone seriously revisit the idea since the updated import plugin API was defined in PEP 451 - that deliberately moved a lot of the global state management out of the plugins and into the import system, so it should be more amenable to an "import engine" style approach to state encapsulation. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
