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. _______________________________________________ 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
