[Python-Dev] python3k : imp.find_module raises SyntaxError

Ron Adam rrr at ronadam.com
Wed Dec 1 06:59:18 CET 2010

On 11/30/2010 07:19 PM, Nick Coghlan wrote:
> On Wed, Dec 1, 2010 at 8:48 AM, Ron Adam<rrr at ronadam.com>  wrote:
>> * It almost seems like the concept of a sub-module (in a package) is flawed.
>>   I'm not sure I can explain what causes me to feel that way at the moment
>> though.
> It isn't flawed, it is just a *lot* more complicated than most people
> realise (cf. PEP 302).

Yes, it's realising that it is a *lot* more *complicated*, that gets me. 
Flawed isn't the right word, it's rather a feeling things could have been 
simpler if perhaps some things were done differently.

Here is the gist of ideas I got from these feelings.  (Food for thought and 
YMMV and all that.)

Python doesn't have a nice way to define a collection of modules that isn't 
also a package.  So we have packages used to organise modules, and packages 
inside other packages.  A collection of modules wouldn't require importing 
a package before importing a module in it.

Another idea is, to have a way to split a large module into files, and have 
it still *be* a module, and not a package.  And also be able to tell what 
is what, by looking at the directory structure.

The train of thought these things came from is, how can we get back to 
having the directory tree have enough info in it so it's clear what is 
what?  And how can we avoid some of the *interdependent* nesting?

> In this case, the signature of find_module (returning an already open
> file) is unfortunate, but probably necessary given the way the import
> internals currently work. As Brett says, returning a loader would be
> preferable, but the builtin import machinery doesn't have proper
> loaders defined (and won't until we manage to get to the point where
> importlib *is* the import machinery).

I'll be looking forward to the new loaders. :-)



More information about the Python-Dev mailing list