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: http://www.python.org/pipermail/distutils-sig/1999-January/000142.html http://www.python.org/pipermail/distutils-sig/1998-December/000077.html > ANSI C > > 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 > Misc > > 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: http://www.canb.auug.org.au/~millerp/rmch/recu-make-cons-harm.html 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? Cheers, -g -- Greg Stein, http://www.lyra.org/
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4