Géry <gery.o...@gmail.com> added the comment: @barry You gave 2 reasons for changing __spec__.origin and __file__ for namespace packages.
Your 1st reason: > I don't particularly like that its origin is "namespace". That's an odd > special case that's unhelpful to test against (what if you import a > non-namespace package from the directory "namespace"?) As far as I know, a non-namespace package always has an __init__.py file, so if it is imported from a directory named "namespace" it has a __spec__.origin and __file__ attributes equal to "path/to/package/namespace/__init__.py". So I don’t see the problem here with having a "namespace" origin for namespace package specs. In addition, PEP 420 that introduced implicit namespace packages in Python 3.3 clearly stated that having no __file__ attribute was intended for namespace packages, and more generally was left a the discretion of the module’s loader and no more limited to built-in modules (https://www.python.org/dev/peps/pep-0420/#module-reprs): > Previously, module reprs were hard coded based on assumptions about a > module's __file__ attribute. If this attribute existed and was a string, it > was assumed to be a file system path, and the module object's repr would > include this in its value. The only exception was that PEP 302 reserved > missing __file__ attributes to built-in modules, and in CPython, this > assumption was baked into the module object's implementation. Because of this > restriction, some modules contained contrived __file__ values that did not > reflect file system paths, and which could cause unexpected problems later > (e.g. os.path.join() on a non-path __file__ would return gibberish). > This PEP relaxes this constraint, and leaves the setting of __file__ to the > purview of the loader producing the module. Loaders may opt to leave __file__ > unset if no file system path is appropriate. Loaders may also set additional > reserved attributes on the module if useful. This means that the definitive > way to determine the origin of a module is to check its __loader__ attribute. > For example, namespace packages as described in this PEP will have no > __file__ attribute because no corresponding file exists. Your 2nd reason: > This is especially bad because the documentation for __spec__.origin implies > a correlation to __file__, and says: > "Name of the place from which the module is loaded, e.g. “builtin” for > built-in modules and the filename for modules loaded from source. Normally > “origin” should be set, but it may be None (the default) which indicates it > is unspecified." I agree here, so why not updating the documentation instead of changing the implementation which followed PEP 420? ---------- nosy: +eric.snow, maggyero _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32305> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
