[Python-3000] PEP 3124 - Overloading, Generic Functions, Interfaces, etc.
Phillip J. Eby
pje at telecommunity.com
Fri May 11 18:37:37 CEST 2007
At 12:05 AM 5/11/2007 -0400, Jim Jewett wrote:
>So we're mostly in agreement, but I had also wanted to leave out importString.
>I know it can seem simpler to treat everything as an object, and not
>worry about where the type switches from package to module to instance
>to attribute. I see it used in Twisted.
>But I'm not sure it is *really* simpler for someone who isn't familiar
>with your codebase,
The use case is to be able to have a string that refers to an
importable object. The unittest module has something similar, egg
entry points do, and so does mod_python. (I wouldn't be surprised if
mod_wsgi has something like that also.) Chandler's repository
(object database) also had code to "load classes" by using a string
import, before I got there.
The thing is, string-import code is tricky to get just right; it
therefore seems like a natural for "batteries included" if you're
creating a stdlib module that's already doing stuff with strings and importing.
>and I don't see why it is needed for whenImported.
It isn't. I'm just saying if we were going to add it to the stdlib,
importString (perhaps with a name change) just seems like a
no-brainer to include. (vs. importObject, importSequence, and
importSuite, which are just boilerplate over importString.)
Anyway, perhaps this should piggyback on the coming discussion of
moving the full import code to Python; it might be that lazy imports
and callbacks could be more cleanly implemented as part of that
machinery, than by being tacked on afterwards.
More information about the Python-3000