[Python-Dev] __package__ attribute

[Brett Cannon]

On Fri, May 21, 2010 at 14:35, Andrew Svetlov <andrew.svetlov at 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 at 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 at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/brett%40python.org
>