Re: [Python-Dev] Dropping __init__.py requirement for subpackages
At 01:49 PM 4/26/2006 -0700, Guido van Rossum wrote:
OK, forget it. I'll face the pitchforks.
I'm disappointed though -- it sounds like we can never change anything about Python any more because it will upset the oldtimers.
I know exactly how you feel. :) But there's always Python 3.0, and if we're refactoring the import machinery there, we can do this the right way, not just the "right now" way. ;) IMO, if Py3K does this, it can and should be inclusive of top-level packages and assemble __path__ using all the sys.path entries. If we're going to break it, let's break it all the way. :) I'm still really curious why the importer solution (especially if tucked away in a Google-defined sitecustomize) won't work, though.
On 4/26/06, Phillip J. Eby <pje@telecommunity.com> wrote:
At 01:49 PM 4/26/2006 -0700, Guido van Rossum wrote:
OK, forget it. I'll face the pitchforks.
I'm disappointed though -- it sounds like we can never change anything about Python any more because it will upset the oldtimers.
I know exactly how you feel. :)
Hardly -- you're not the BDFL. :)
But there's always Python 3.0, and if we're refactoring the import machinery there, we can do this the right way, not just the "right now" way. ;) IMO, if Py3K does this, it can and should be inclusive of top-level packages and assemble __path__ using all the sys.path entries. If we're going to break it, let's break it all the way. :)
No -- I'm actually quite happy with most of the existing behavior (though not with the APIs).
I'm still really curious why the importer solution (especially if tucked away in a Google-defined sitecustomize) won't work, though.
Well, we have a sitecustomize, and it's been decided that it's such a pain to get it to do the right thing that we're trying to get rid of it. So proposing to add more magic there would not work. -- --Guido van Rossum (home page: http://www.python.org/~guido/)
participants (2)
-
Guido van Rossum -
Phillip J. Eby