This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author Nate Soares
Recipients Nate Soares, ezio.melotti, mrabarnett, steven.daprano, vstinner
Date 2017-06-29.17:03:40
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <CAB7CYTz5iXoRdJ2=M==ddFKhFFV06rv_WdS6tnZfmBv-UCchpQ@mail.gmail.com>
In-reply-to <1498672521.72.0.48231977361.issue30772@psf.upfronthosting.co.za>
Content
To be clear, the trouble I was trying to point at is that if foo.py didn't
have __all__, then it would still have a BB attribute. But if the module is
given __all__, the BB is normalized away into a B. This seems like pretty
strange/counterintuitive behavior. For instance, I found this bug when I
added __all__ to a mathy library, where other modules had previously been
happily importing BB and using <module>.BB etc. with no trouble.

In other words, I could accept "BB gets normalized to B always", but the
current behavior is "modules are allowed to have a BB attribute but only if
they don't use __all__, because __all__ requires putting the BB through a
process that normalizes it to B, and which otherwise doesn't get run".

If this is "working as intended" then w/e, I'll work around it, but I want
to make sure that we all understand the inconsistency before letting this
bug die in peace :-)

On Wed, Jun 28, 2017 at 10:55 AM Brett Cannon <report@bugs.python.org>
wrote:

>
> Changes by Brett Cannon <brett@python.org>:
>
>
> ----------
> resolution:  -> not a bug
> stage:  -> resolved
> status: open -> closed
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue30772>
> _______________________________________
>
History
Date User Action Args
2017-06-29 17:03:40Nate Soaressetrecipients: + Nate Soares, vstinner, ezio.melotti, mrabarnett, steven.daprano
2017-06-29 17:03:40Nate Soareslinkissue30772 messages
2017-06-29 17:03:40Nate Soarescreate