I have a few questions about the PEP 328 which I'd like discussed: * Why do we absolutely need to change the current scheme of 'local, then absolute' for name resolution ? In the past I have often had the case where I wanted to move Python software written as top-level modules into their own package. The current logic makes this painless; the proposed move to 'absolute only' introduces serious editing which is bound to be error-prone. I don't object absolute imports at all, but I like the possibilitiy to package'ify existing Python module/module sets by simply copying them into a newly created package directory. Note that Python's own name lookup behaviour is very similar to the existing import scheme (nested scopes left aside). * How will the proposed 'absolute only' strategy affect the __import__() API ? This is of special concern since quite a few applications out there rely on __import__() having the existing semantics and a change would cause these applications to fail. One such instance is the encodings package search function, which relies on first looking in the package for a suitable codec and then scans for a top-level installation. * Will the DeprecationWarning only be raised for uses of 'import xyz' and 'from xyz import a' or also for __import__() ? * How do these semantics changes affect importers that hook into __import__ ? (imputil.py, ihooks.py, etc.) * What's the affect on zip imports or tools like py2exe, McMillan's installer, etc. ? BTW, is any of this already implemented to play with ? Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, May 17 2004)

...

...

Python/Zope Consulting and Support ... http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/

EuroPython 2004, Göteborg, Sweden 20 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::