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 brett.cannon
Recipients Daniel Shaulov, brett.cannon, eric.snow, ncoghlan
Date 2016-04-01.22:14:54
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1459548894.48.0.542126128086.issue26646@psf.upfronthosting.co.za>
In-reply-to
Content
Referring to the other issue was more about tying the two issues together than necessarily expecting the other patch to work.

As for supporting packages as well as submodules, I'm not sure. It seems a little odd not to support the idea, but then again if something is built-in then there really isn't a need to support the concept of a directory containing more modules. But then again since there is a difference in terms of how a module vs package looks it should probably be supported.

And if you do try and support it, there might be nothing more needed than to have the module be named pkg.__init__ and have some special handling to strip out the '__init__' part of the name and to set `__path__ = []` in importlib. Then importlib can simply try for `name` and `name.__init__` and then use that to figure out if the module should be considered a package or not.

This whole issue is unfortunately one of those things where it's uncommon enough to have to think about all edge cases and the overall impact on other users if the suggested changes are made and to not have a clear-cut answer.
History
Date User Action Args
2016-04-01 22:14:54brett.cannonsetrecipients: + brett.cannon, ncoghlan, eric.snow, Daniel Shaulov
2016-04-01 22:14:54brett.cannonsetmessageid: <1459548894.48.0.542126128086.issue26646@psf.upfronthosting.co.za>
2016-04-01 22:14:54brett.cannonlinkissue26646 messages
2016-04-01 22:14:54brett.cannoncreate