[Python-Dev] python3k : imp.find_module raises SyntaxError
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
> 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