Nate Soares added the comment: 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 <rep...@bugs.python.org> wrote: > > Changes by Brett Cannon <br...@python.org>: > > > ---------- > resolution: -> not a bug > stage: -> resolved > status: open -> closed > > _______________________________________ > Python tracker <rep...@bugs.python.org> > <http://bugs.python.org/issue30772> > _______________________________________ > ---------- title: If I make an attribute "[a unicode version of B]", it gets assigned to "[ascii B]", and so on. -> If I make an attribute " _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30772> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
