On Jan 03, 2015, at 03:09 AM, Nick Coghlan wrote: >This was the intended solution when PEP 420 was written - we deliberately >didn't break old-style namespace packages, we just made them redundant for >code that only needs to run on 3.3+. This is much easier to learn, since it >means creating packages as subdirectories "just works", and automatically >collecting all search path subdirectories with a given name into a common >namespace by default better matches the typical behaviour of other search >path based explicit import systems. > >However, implicit namespace packages aren't inherently *better* than the >old explicit ones at runtime, as the end result is the same in either case: >a module.__path__ entry that contains multiple directories. The only >difference is in whether you get there by leaving out __init__.py and >letting the 3.3+ import machinery handle it, or by doing it explicitly >yourself. > >That means there's a bug to be fixed in the lazr packages - they provide an >__init__.py file, thus turning off the implicit namespace package support, >but then they use a version check to also turn off the explicit namespace >package support. If you turn off both kinds of namespace package support, >you're not going to have a namespace package at the end of it :)
While I agree that the lazr package's __init__.py files should not have the version checks (and I've released fixes for the few that I care about immediately), I still think it could make sense for better support in the Python installation tools to support PEP 420 namespace packages. FWIW, the Debian packaging tools explicitly remove namespace package __init__.py files from portions when they are built for Python 3 (let's assume we don't care about any Python 3 that doesn't support PEP 420). We've not had any problems with this that I know of. I suppose with a working old-style namespace __init__.py file, there's little practical effect, but for consistency it makes sense. One reason would be introspection tools, which would see a different set of attributes for `dir(lazr)` in the two cases, one where lazr is a concrete package and the other where it's a virtual/namespace package. Cheers, -Barry
pgplmS7xxUqcu.pgp
Description: OpenPGP digital signature
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
