[Python-3000] PEP 3124 - Overloading, Generic Functions, Interfaces, etc.

[Phillip J. Eby]

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.