What are expected values for module.__package__? I see two different behaviors: importlib and standard python import. importlib processes __package__ pretty simple and clean: - for toplevel modules __package__ is empty string - for packages it's package name - for modules inside packages it's again package name Standard import follows another strategy: - it tries to setup __package__ only in case of relative import (see first 'if' in import.c:get_parent) - otherwise __package__ is untouched and None by default. For me importlib's way is better. I don't see any PEP specifying __package__ behavior.
For me it's the real bug in standard python import machinery. I don't see any backward incompatibilities. There are very hard to write any import-depended code based on decision: was module imported in absolute or relative way. If it's a bug I can create issue in python bugtracker and provide a patch (for Python 3.2 and for 2.7 if later is required). On Fri, May 21, 2010 at 10:18 PM, Andrew Svetlov <andrew.svetlov@gmail.com> wrote:
What are expected values for module.__package__? I see two different behaviors: importlib and standard python import. importlib processes __package__ pretty simple and clean: - for toplevel modules __package__ is empty string - for packages it's package name - for modules inside packages it's again package name
Standard import follows another strategy: - it tries to setup __package__ only in case of relative import (see first 'if' in import.c:get_parent) - otherwise __package__ is untouched and None by default.
For me importlib's way is better. I don't see any PEP specifying __package__ behavior.
On Fri, May 21, 2010 at 14:35, Andrew Svetlov <andrew.svetlov@gmail.com> wrote:
For me it's the real bug in standard python import machinery. I don't see any backward incompatibilities. There are very hard to write any import-depended code based on decision: was module imported in absolute or relative way.
If it's a bug I can create issue in python bugtracker and provide a patch (for Python 3.2 and for 2.7 if later is required).
It's definitely not a bug. The definition of __package__ is such that not bothering to set it is still valid (see PEP 366 for the exact details of the attribute). It just happens that importlib puts in the extra effort to add/set the attribute as much as possible. Now if you want to write a patch for import.c to add the attribute properly then that could get reviewed and added as a feature request, but as it stands the current semantics are correct. -Brett
On Fri, May 21, 2010 at 10:18 PM, Andrew Svetlov <andrew.svetlov@gmail.com> wrote:
What are expected values for module.__package__? I see two different behaviors: importlib and standard python import. importlib processes __package__ pretty simple and clean: - for toplevel modules __package__ is empty string - for packages it's package name - for modules inside packages it's again package name
Standard import follows another strategy: - it tries to setup __package__ only in case of relative import (see first 'if' in import.c:get_parent) - otherwise __package__ is untouched and None by default.
For me importlib's way is better. I don't see any PEP specifying __package__ behavior.
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/brett%40python.org
participants (2)
-
Andrew Svetlov -
Brett Cannon