PyWart: "Python's import statement and the history of external dependencies"

Steven D'Aprano steve+comp.lang.python at pearwood.info
Sun Nov 23 01:30:02 EST 2014


Chris Angelico wrote:

> On Sat, Nov 22, 2014 at 11:25 PM, Steven D'Aprano
> <steve+comp.lang.python at pearwood.info> wrote:
>> Ian Kelly wrote:
>>
>> - It's hard to keep track of what modules are in the standard library.
>> Which of the following is *not* in Python 3.3's std lib? No cheating by
>> looking them up.)
>>
>>     os2emxpath, wave, sndheader, statslib, poplist, plist,
>>     pickletools, picklelib, path, cgi, cgitb, copylib, xpath
> 
> Okay, here's my guesses.
> 
> os2emxpath: In the stdlib, but more often accessed as "os.path" while
> running under OS/2

Correct.

> wave: Not in the stdlib, though I'd avoid the name anyway.

Incorrect. The wave module is for manipulating .wav files.

> sndheader: Not in the stdlib - probably on PyPI though

Correct. It is actually spelled "sndhdr".

> poplist, plist, pickletools, picklelib: I suspect PyPI, not stdlib,
> but could be wrong

There's a pickletools, but not picklelib. plist is actually spelled
plistlib, and there is poplib, not poplist.

> path: Not in the stdlib (there's os.path and I doubt there'd be both)
> cgi, cgitb: In the stdlib

Correct.

> copylib: No idea, could be either way.

Spelled "copy", not "copylist".

> xpath: I'll guess this as not being present.

Correct.

Not bad, but as you can see, the naming convensions are all over the place.
It's easy to accidentally shadow the std lib.



[...]
>> That would be horrible. But here's an alternative which is less horrible
>> and maybe even useful.
>>
>> There's still a single process-wide search path, but there's a second
>> per-module search path which is searched first. By default it's empty.
>>
>> So a module can define it's own extra search path:
>>
>> __path__ = ['look/here', 'and/here']
>> import something
>>
>> without affecting any other modules.
> 
> That's what Rick said first, and then said that if you're going to be
> explicit, you should do the job properly and not have _any_ implicit
> paths.

Rick should ask himself why virtually every single language, from compiled
languages like Ada, C, Pascal and Java, to interpreted languages like bash,
all use search paths instead of explicit paths.

Hint: the answer is not that every single language designer in the world is
a moron.


> Thing is, though, it still breaks the sys.modules concept. Either
> __path__ is ignored if the module was found in sys.modules

Good point.



-- 
Steven




More information about the Python-list mailing list