[Python-Dev] Notice of intent: rich comparisons

[Greg Stein]

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/