On 11/30/2010 07:19 PM, Nick Coghlan wrote:
On Wed, Dec 1, 2010 at 8:48 AM, Ron Adam<r...@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. :-)
Cheers,
Ron
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
