Guido van Rossum wrote:
... Import revamp
It should be much easier to add hooks to allow importing from zip files, from a URL, etc., or (different) hooks to allow looking for different extensions (e.g. to automatically generate ILU stubs). This should help the small platforms too, since they often don't have a filesystem, so their imports will have to come from some other place.
I would recommend that Python's import mechanism be changed to use some of the concepts from my imputil.py module and in a couple of my posts to distutils-sig:
I'm tired of supporting K&R C. All code should be converted to using prototypes. The Py_PROTO macros should go. We can add const-correctness to all code. Too bad for platforms without decent compilers (let them get GCC).
Or those platforms can stick with Python 1.5.2
Jeremy Hylton's urllib2.py Greg Stein's new httplib.py (or Jeremy's?)
Mine is a drop-in replacement for the current httplib.py. httplib.HTTP is compatible with the current version and does HTTP/1.0. httplib.HTTPConnection is similar to the other (but (IMO) cleans up a few elements of the API); it does HTTP/1.1, including persistent connections. This module follows the design of the original httplib.py much more closely. Jeremy's module uses a very different design approach (no value judgement here; it's just different); also, it simply copies over the old HTTP class, while mine derives the compatible version from HTTPConnection. I'm not sure how much testing Jeremy's has had, but I use my module for all Python-based http work now. Some number of other people have downloaded and used it, too.
I would recommend my new module, given the two options.
I'll eventually have a davlib.py to add to the distribution, but it needs more work. I'll contribute that later.
I'd also like to see some cleanup of the build process. For example, (Guido:) I sent in a different way to handle the signal stuff (shifting files around and stuff) as opposed to the "hassignal" thing.
About the build process: it may be nice to move to a single makefile. Here is an interesting paper about this:
Is it reasonable to split out the Demo, Doc, Misc, and Tools subdirs since those never really end up as part of an installed Python? e.g. into a python-extras distribution? (which would allow doc and tools updates at arbitrary times)
Does it make sense to remove platform-specific modules? (e.g. the SGI modules)
While distutils doesn't have anything *yet*, there are changes that can be made in the build process to improve the distutils process. I know that Greg Ward wants distutils to work on previous versions of Python, but (IMO) things would be simpler all around if distutils-based packages were simply designed for 1.6 systems as a basic dependency. However, that choice is quite separate from the decision to generate distutils support during the build.
Oh: there were some things floating around at one point about using Python itself within the build process (e.g. for modules). Is any of that work useful?
-- Greg Stein, http://www.lyra.org/