[Import-SIG] My objections to implicit package directories

Nick Coghlan ncoghlan at gmail.com
Tue Mar 13 04:35:13 CET 2012

On Tue, Mar 13, 2012 at 12:50 PM, Eric Snow <ericsnowcurrently at gmail.com> wrote:
>> Ultimately this is a form of PEP 402 without so much complexity.  The
>> trade-off is it requires a new kind of package.  As far as I
>> understand them, most of your concerns are based on the idea that
>> namespace packages would be included in the initial traversal of
>> sys.path, which is not the case.  It sounds like there are a couple
>> points you made that may still need attention, but hopefully this at
>> least helps clarify what we talked about.

No, the backwards compatibility issue was only one minor concern. I'm
pleased to hear it was a misreading of MvL's message on my part, but
dealing with implicit package directories in a backwards compatible
way is still a lot more complicated than "hey, instead of including
'__init__.py' as a marker file, you can just append '.pyp' to the
directory name. If Python encounters a 'foo.pyp' directory when trying
to import 'foo', it will create a new 'foo' package, then keep
scanning  sys.path and append any additional 'foo.pyp' directories it
finds to foo.__path__."

The deal breaker for me is the loss of the 1:1 mapping between
filesystem layouts and the module heirarchy. Losing that sucks, but
people appear to be willing to throw it away for no payoff beyond
"Java and Perl users don't have to explicitly mark their package
directories, why do Python users?". Python chooses explicit rather
than implicit self, why should package directories be any different?

Anything implicit should require an extraordinary pay-off in
expressiveness before it gets added to Python, and I haven't seen
anything remotely like that in this case. Instead, it looks like we're
going to get a solution that is both implicit and *less* expressive
than the status quo.

I could actually fix the interaction between multiprocessing and -m
*today* in 2.7 and 3.2, but what's the point if 3.3 is just going to
add a feature that makes that fix invalid?

(To elaborate on that last point: I recently realised that the
algorithm described in PEP 395 could be applied *today* in the part of
multiprocessing that figures out how to launch the child process on
Windows. No PEP needed or public API change needed)


Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

More information about the Import-SIG mailing list