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 ncoghlan
Recipients Arfrever, Jurko.Gospodnetić, barry, christian.heimes, eric.snow, larry, ncoghlan, pitrou, python-dev, r.david.murray, rhettinger, serhiy.storchaka, vstinner
Date 2014-03-11.10:39:07
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
cx-freeze feedback is better added to issue 20884 - I currently still suspect that 3.4 has just uncovered some latent spec non-compliance in the cx-freeze import system emulation (although I need to investigate further to be sure, since it's also possible we accidentally broke backwards compatibility with certain kinds of legacy behaviour when implementing PEP 451).

For this issue, I don't think os.path can be used as a precedent - "os" isn't a package, and "os.path" isn't a normal submodule (instead, the os module does a dance to figure out which top level module to import as path - it's usually either ntpath or posixpath).

Instead, this is just normal submodule import behaviour - "import collections" doesn't necessarily imply "import", it just used to do so because that was how the backwards compatibility for the old names happened to be implemented.

Setting the attribute would also shadow the submodule, which would be a little weird (since could then refer to either that module or to _collections_abc). Really, the change to collections/ could just be reverted - the _collections_abc move was just to avoid running collections/ at startup, so there's no need to use the hack inside collections/ itself.
Date User Action Args
2014-03-11 10:39:08ncoghlansetrecipients: + ncoghlan, barry, rhettinger, pitrou, vstinner, larry, christian.heimes, Arfrever, r.david.murray, Jurko.Gospodnetić, python-dev, eric.snow, serhiy.storchaka
2014-03-11 10:39:08ncoghlansetmessageid: <>
2014-03-11 10:39:08ncoghlanlinkissue20784 messages
2014-03-11 10:39:07ncoghlancreate