Talin wrote:
> The same is true for the problem of a "plugins" dir containing modules
> to import. Yes, its only 3 lines of code to list the directory and import
> each file - but coming up with those exact 3 lines (in particular, getting
> the arguments to __import__ correct) is trickier than it looks, especially
> when you are trying not to hard-code the module name. What I came
> up with is this, which is probably incorrect:
>
> # Import all parsers
> dirname = os.path.dirname( __file__ )
> for name in os.listdir( dirname ):
> if fnmatch.fnmatch( name, "*.py" ) and name != "__init__.py":
> mod = __import__( "%s.%s" % ( __name__, os.path.splitext( name )[ 0 ]
> ) )
>
> Perhaps the answer is better docs? For example, there's a number of
> docs on the package / module loading mechanism, but they all seem
> like pieces of an incomplete puzzle to me.
I think this is a fair cop, but its not really a Py3k problem. At the moment,
Python's import mechanism is only properly documented in PEP 302, and the
answer to most of your questions is that "assuming your module is on a real
filesystem may not be a safe assumption". But the standard import mechanism
doesn't provide the __loader__ attributes that would let you get around that
problem in a consistent fashion.
Until PEP 302 itself is completely implemented, I can't really see these kinds
of niceties being added.
At this point, I don't even know how thoroughly the integration of PEP 302 and
PEP 328 (absolute/relative imports) has been tested. . .
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---------------------------------------------------------------
http://www.boredomandlaziness.org
_______________________________________________
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
