From skip@mojam.com (Skip Montanaro)  Wed Apr 21 14:17:32 1999
From: skip@mojam.com (Skip Montanaro) (skip@mojam.com (Skip Montanaro))
Date: Wed, 21 Apr 1999 09:17:32 -0400
Subject: [Python-Dev] ZServer 1.0b1: spurious colon in HTTP response line
Message-ID: <199904211317.JAA26167@cm-29-94-14.nycap.rr.com>

(Also reported to the bug catcher.)

I'm trying to migrate from ZopeHTTPServer to ZServer 1.0b1.  I was seeing
the ZServer headers turning up in pages generated by the process.  When I
viewed the page source of the generated HTML I saw:

    HTTP/1.0: 200 OK
    Server: Zope/experimental ZServer/1.1b1
    Date: Wed, 21 Apr 1999 13:00:38 GMT
    X-Powered-By: Zope (www.zope.org), Python (www.python.org)
    Connection: close
    Content-Type: text/html
    Content-Length: 7802
    

    <!-- -*-html-helper -*- -->
    <HTML>
    <HEAD>
    <TITLE>Musi-Cal... Concert Schedules: Folk Music, Country Music, Rock Music &amp; more!</TITLE>
    ...

I run ZServer behind an Apache 1.3.3 running mod_proxy.  Apparently Apache
doesn't recognize the HTTP response when there is a colon following the
version number and adds a simple set of headers itself.  I guess web
browsers either ignore that line or are more lenient in their parsing of the
response.

The following simple patch corrects the problem:

diff -c2 HTTPResponse.py.~1~ HTTPResponse.py
*** HTTPResponse.py.~1~	Tue Apr 13 15:21:12 1999
--- HTTPResponse.py	Wed Apr 21 09:05:00 1999
***************
*** 146,150 ****
       
          # status header must come first.
!         append("HTTP/%s: %s" % (self._http_version, status))
          if headers.has_key('status'):
              del headers['status']
--- 146,150 ----
       
          # status header must come first.
!         append("HTTP/%s %s" % (self._http_version, status))
          if headers.has_key('status'):
              del headers['status']
***************


Skip Montanaro	| Mojam: "Uniting the World of Music" http://www.mojam.com/
skip@mojam.com  | Musi-Cal: http://www.musi-cal.com/
518-372-5583


From da@ski.org  Wed Apr 21 19:47:56 1999
From: da@ski.org (David Ascher)
Date: Wed, 21 Apr 1999 11:47:56 -0700 (Pacific Daylight Time)
Subject: [Python-Dev] Notice of intent: rich comparisons
Message-ID: <Pine.WNT.4.04.9904211142330.174-100000@rigoletto.ski.org>

Now that 1.5.2 is finalized, I'll be starting to prepare a patch for the
rich comparisons.  

Guido, how do you envision python-dev working?  Do you want to hand out a
TODO list for 1.6?

--david




From guido@CNRI.Reston.VA.US  Wed Apr 21 20:04:40 1999
From: guido@CNRI.Reston.VA.US (Guido van Rossum)
Date: Wed, 21 Apr 1999 15:04:40 -0400
Subject: [Python-Dev] Notice of intent: rich comparisons
In-Reply-To: Your message of "Wed, 21 Apr 1999 11:47:56 PDT."
 <Pine.WNT.4.04.9904211142330.174-100000@rigoletto.ski.org>
References: <Pine.WNT.4.04.9904211142330.174-100000@rigoletto.ski.org>
Message-ID: <199904211904.PAA14966@eric.cnri.reston.va.us>

> Now that 1.5.2 is finalized, I'll be starting to prepare a patch for the
> rich comparisons.  

Cool!

> Guido, how do you envision python-dev working?

I though we'd just crack Monty Python jokes while pretending to work :-)

> Do you want to hand out a TODO list for 1.6?

Well, I'm not saying that this is the definitive list, but certainly
there are a bunch of things that definitely need to be incorporated.
Here's an excerpt of a list that I keep for myself, in no particular
order, with brief annotations (I have a meeting in 15 minutes :):

Redesign thread/init APIs

	See the recent discussion in the thread-sig.  There should be
	some kind of micro-init that initializes essential components
	(including the thread lock!) but doesn't create an interpreter
	or a threadstate object.  There should also be a notion of a
	default interpreter.

Break up into VM, parser, import, mainloop, and other components?

	The porting efforts to seriously small machines (Win/CE,
	Pilot, etc.) all seem to need a Python VM that doesn't
	automatically pull in the parser and interactive main loop.
	There are other reasons as well to isolate various parts
	of the functionality (including all numeric data types except
	ints).

	This could include: restructuring of the parser so codeop.py
	can be simplified; making the interactive main loop a script.

String methods

	Barry has his patches ready.

Unicode

	What is the status of /F's latest attempts?

Rich comparisons

	This is Dave's plan.

Coercions

	Marc-Andre Lemburg has some good suggestions here:
	http://starship.python.net/~lemburg/coercion-0.6.zip

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.

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

Buffer object API extensions

	Marc-Andre Lemburg has a patch

Distutil

	Should we start integrating some of the results of the
	distutil SIG?  (What's the status?  I haven't been paying
	attention.)

Misc

	Jeremy Hylton's urllib2.py

	Greg Stein's new httplib.py (or Jeremy's?)

	Andrew Kuchling's new PCRE release?

	The IPv6 patches?

Gotta run!

--Guido van Rossum (home page: http://www.python.org/~guido/)


From gward@cnri.reston.va.us  Wed Apr 21 20:10:08 1999
From: gward@cnri.reston.va.us (Greg Ward)
Date: Wed, 21 Apr 1999 15:10:08 -0400
Subject: [Python-Dev] Notice of intent: rich comparisons
In-Reply-To: <199904211904.PAA14966@eric.cnri.reston.va.us>; from Guido van Rossum on Wed, Apr 21, 1999 at 03:04:40PM -0400
References: <Pine.WNT.4.04.9904211142330.174-100000@rigoletto.ski.org> <199904211904.PAA14966@eric.cnri.reston.va.us>
Message-ID: <19990421151008.D6167@cnri.reston.va.us>

On 21 April 1999, Guido van Rossum said:
> Distutil
> 
> 	Should we start integrating some of the results of the
> 	distutil SIG?  (What's the status?  I haven't been paying
> 	attention.)

It's in a state that other people can look at the code, but (apparently)
not yet good enough for floods of patches to come in.  Right now,
Distutils has *just* enough marbles to "build" and install itself on
Unix systems, and someone has contributed a patch so it works on NT.  No
support yet for compiling extensions, which of course is the important
thing.

        Greg
-- 
Greg Ward - software developer                    gward@cnri.reston.va.us
Corporation for National Research Initiatives    
1895 Preston White Drive                           voice: +1-703-620-8990
Reston, Virginia, USA  20191-5434                    fax: +1-703-620-0913


From da@ski.org  Wed Apr 21 20:19:42 1999
From: da@ski.org (David Ascher)
Date: Wed, 21 Apr 1999 12:19:42 -0700 (Pacific Daylight Time)
Subject: [Python-Dev] Notice of intent: rich comparisons
In-Reply-To: <199904211904.PAA14966@eric.cnri.reston.va.us>
Message-ID: <Pine.WNT.4.04.9904211207010.174-100000@rigoletto.ski.org>

On Wed, 21 Apr 1999, Guido van Rossum wrote:

> > Guido, how do you envision python-dev working?
> 
> I though we'd just crack Monty Python jokes while pretending to work :-)

That'd be better than what I've read on the perl5-porters list in the last
couple of days (which I'm reading because of the ad hoopla).  They seem to
spend their time arguing about whether Perl codes are programs or scripts.  
Viciously, too. =)

More seriously, some of the discussions they're having a worth keeping an
eye on, just as a form of legal industrial spying.

> Import revamp

There was an interesting bit from Greg, Jack, and MarkH on this topic
recently in the distutil-sig.  Maybe one of them can bring the rest of us
up to date on the effort.

--david





From fredrik@pythonware.com  Wed Apr 21 21:04:54 1999
From: fredrik@pythonware.com (Fredrik Lundh)
Date: Wed, 21 Apr 1999 22:04:54 +0200
Subject: [Python-Dev] Notice of intent: rich comparisons
References: <Pine.WNT.4.04.9904211142330.174-100000@rigoletto.ski.org>  <199904211904.PAA14966@eric.cnri.reston.va.us>
Message-ID: <092701be8c32$3a4ad9f0$f29b12c2@pythonware.com>

Guido wrote:

> String methods
> 
> Barry has his patches ready.
> 
> Unicode
> 
> What is the status of /F's latest attempts?

most of the code is written and tested; the API still
needs some cleaning up. I also have a few patches
and other contributions in my inbox that I gotta
look into...

btw, the unicode module can be compiled for 8-bit
characters too.  we could merge it with the string
module (one place to fix bugs...)

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

something similar to greg's imputil.py should definitely
be in the core...

> 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 ansi2knr.c (available from http://www.cs.wisc.edu/~ghost/).
otoh, it only converts function headers, so I'm not sure it's
worth the effort...

</F>



From beazley@cs.uchicago.edu  Wed Apr 21 21:06:50 1999
From: beazley@cs.uchicago.edu (David Beazley)
Date: Wed, 21 Apr 1999 15:06:50 -0500 (CDT)
Subject: [Python-Dev] Notice of intent: rich comparisons
References: <Pine.WNT.4.04.9904211142330.174-100000@rigoletto.ski.org>
 <199904211904.PAA14966@eric.cnri.reston.va.us>
Message-ID: <199904212006.PAA17138@tartarus.cs.uchicago.edu>

Guido van Rossum writes:
> 
> 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).
> 

Maybe I'm just lucky, but I've written nothing but ANSI C for the last
8 years and have never had a problem compiling it on any machine.  I
don't see this as being a huge issue.

> 
> Misc
>

Depending on how deep I want to dig, I may have some patches to
ParseTuple() that would make life easier for some of us extension
writing fans.  As it is right now, my experimental version of Swig
is using it's own version of ParseTuple (for various reasons).
Also, out of curiousity, is anyone making heavy use of the CObject
type right now?  

Cheers,

Dave




From jim@digicool.com  Wed Apr 21 22:15:24 1999
From: jim@digicool.com (Jim Fulton)
Date: Wed, 21 Apr 1999 17:15:24 -0400
Subject: [Python-Dev] Notice of intent: rich comparisons
References: <Pine.WNT.4.04.9904211142330.174-100000@rigoletto.ski.org>
 <199904211904.PAA14966@eric.cnri.reston.va.us> <199904212006.PAA17138@tartarus.cs.uchicago.edu>
Message-ID: <371E3FEC.9D19607A@digicool.com>


David Beazley wrote:
> 
> Guido van Rossum writes:
> >
> > 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).
> >
> 
> Maybe I'm just lucky, but I've written nothing but ANSI C for the last
> 8 years and have never had a problem compiling it on any machine.  I
> don't see this as being a huge issue.

I've had the same experience with things like prototypes.
The recent introduction of indented preprocessor instructions
caused me significant pain on some platforms.  Fortunately, I 
haven't had to deal with those platforms recently, still, the elegence
of indented preporicessor instructions wasn't worth the pain it caused.

As far as choice of compilers goes, sometimes gcc isn't an option.
I've had cases where I *had* to use the native compiler in order to
link to third-party libraries.

I support moving to ANSI C, for example, wrt prototypes, but
lets still be somewhat sensative to portability and not abuse 
bad compilers without good reason.


> 
> >
> > Misc
> >
> 
> Depending on how deep I want to dig, I may have some patches to
> ParseTuple() that would make life easier for some of us extension
> writing fans.  As it is right now, my experimental version of Swig
> is using it's own version of ParseTuple (for various reasons).
> Also, out of curiousity, is anyone making heavy use of the CObject
> type right now?

Yes.

Jim

--
Jim Fulton           mailto:jim@digicool.com   Python Powered!        
Technical Director   (888) 344-4332            http://www.python.org  
Digital Creations    http://www.digicool.com   http://www.zope.org    

Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email
address may not be added to any commercial mail list with out my
permission.  Violation of my privacy with advertising or SPAM will
result in a suit for a MINIMUM of $500 damages/incident, $1500 for
repeats.


From jeremy@cnri.reston.va.us  Wed Apr 21 22:23:57 1999
From: jeremy@cnri.reston.va.us (Jeremy Hylton)
Date: Wed, 21 Apr 1999 17:23:57 -0400 (EDT)
Subject: [Python-Dev] Notice of intent: rich comparisons
In-Reply-To: <199904212006.PAA17138@tartarus.cs.uchicago.edu>
References: <Pine.WNT.4.04.9904211142330.174-100000@rigoletto.ski.org>
 <199904211904.PAA14966@eric.cnri.reston.va.us>
 <199904212006.PAA17138@tartarus.cs.uchicago.edu>
Message-ID: <14110.16787.893181.642806@bitdiddle.cnri.reston.va.us>

>>>>> "DB" == David Beazley <beazley@cs.uchicago.edu> writes:

  DB> various reasons).  Also, out of curiousity, is anyone making
  DB> heavy use of the CObject type right now?

I used it a little, but only in a modified Python backend for SWIG. 

Jeremy


From mal@lemburg.com  Wed Apr 21 22:46:46 1999
From: mal@lemburg.com (M.-A. Lemburg)
Date: Wed, 21 Apr 1999 23:46:46 +0200
Subject: [Python-Dev] Notice of intent: rich comparisons
References: <Pine.WNT.4.04.9904211142330.174-100000@rigoletto.ski.org> <199904211904.PAA14966@eric.cnri.reston.va.us>
Message-ID: <371E4746.22A84506@lemburg.com>

Guido van Rossum wrote:
> 
> Break up into VM, parser, import, mainloop, and other components?
> 
>         The porting efforts to seriously small machines (Win/CE,
>         Pilot, etc.) all seem to need a Python VM that doesn't
>         automatically pull in the parser and interactive main loop.
>         There are other reasons as well to isolate various parts
>         of the functionality (including all numeric data types except
>         ints).
> 
>         This could include: restructuring of the parser so codeop.py
>         can be simplified; making the interactive main loop a script.

There's some good work out there by Skip Montanaro to revamp the
VM into a combined register/stack machine. He calls it rattlesnake.
More infos can be found in the list archive (it's currently sleeping):

	http://www.egroups.com/folders/rattlesnake

I would like to see the VM/compiler pluggable so that experiments
like rattlesnake become easier to implement (extension modules vs.
patches to the core interpreter).

> Coercions
> 
>         Marc-Andre Lemburg has some good suggestions here:
>         http://starship.python.net/~lemburg/coercion-0.6.zip

I will continue to work on these patches now that 1.5.2 is out.

There is a (more or less) detailed explanation of the patch set
at:

	http://starship.skyport.net/~lemburg/CoercionProposal.html

Instead of using of using the PY_NEWSTYLENUMBER approach I'll
turn to the new type flags that were introduced in 1.5.2. The
Py_NotImplemented singleton return value will stay, because
performance tests have shown that this method does not cause
any significant hit where as the exception raise and catch
method does introduce a significant slow-down.

> Import revamp

Greg's imputil.py (it's in the distutils package) should provide
a good start.

> Buffer object API extensions

I'll put the complete patch up on starship later this week...
here are the basic prototypes:

    DL_IMPORT(int) PyObject_AsCharBuffer Py_PROTO((PyObject *obj,
                                                   const char **buffer,
                                                   int *buffer_len));

    /* Takes an arbitrary object which must support the (character,
       single segment) buffer interface and returns a pointer to a
       read-only memory location useable as character based input for
       subsequent processing.

       buffer and buffer_len are only set in case no error
       occurrs. Otherwise, -1 is returned and an exception set.

    */

    DL_IMPORT(int) PyObject_AsReadBuffer Py_PROTO((PyObject *obj,
                                                   const void **buffer,
                                                   int *buffer_len));

    /* Same as PyObject_AsCharBuffer() except that this API expects
       (readable, single segment) buffer interface and returns a
       pointer to a read-only memory location which can contain
       arbitrary data.

       buffer and buffer_len are only set in case no error
       occurrs. Otherwise, -1 is returned and an exception set.

    */

    DL_IMPORT(int) PyObject_AsWriteBuffer Py_PROTO((PyObject *obj,
                                                    void **buffer,
                                                    int *buffer_len));
    
    /* Takes an arbitrary object which must support the (writeable,
       single segment) buffer interface and returns a pointer to a
       writeable memory location in buffer of size buffer_len.

       buffer and buffer_len are only set in case no error
       occurrs. Otherwise, -1 is returned and an exception set.

    */

> Distutil
> 
>         Should we start integrating some of the results of the
>         distutil SIG?  (What's the status?  I haven't been paying
>         attention.)

With all the different modules and packages available for Python
starting to slowly introduce dependencies, I think the main
objective should be introducing a well organized installation
info system, e.g. a registry where modules and packages can
query and save version and dependency information. Someone on
the main list mentioned that JPython has something like this...

> Misc
> 
>         Jeremy Hylton's urllib2.py
> 
>         Greg Stein's new httplib.py (or Jeremy's?)
> 
>         Andrew Kuchling's new PCRE release?
> 
>         The IPv6 patches?

These are on my wish list, so I'll simply add them here:

· APIs to faciliate creation of extensions classes (using Python
  classes and C functions as methods)

The main open question here is where and how to store C data in
the instances. This could also provide a way to migrate to
all Python classes for some future version.

· Restructure the calling mechanism used in ceval.c to make
  it clearer, more flexible and faster (of course, :-). Also,
  inline calling of C functions/methods (this produces a noticable
  speedup).

I have a patch for the restructuring and an old one (against 1.5)
for the C function call inlining.

· A "fastpath" hook made available through the sys module.

This should hook into the module/package loader and should be
used whenever set to find a module (reverting to the standard
lookup method in case it can't find it). I have an old patch
that does this. It uses a simple Python function to redirect the
lookup to a precalculated dictionary of installed modules/packages.
This results in faster startup of the Python interpreter (by saving
a few hundred stat() calls).

-- 
Marc-Andre Lemburg                               Y2000: 254 days left
---------------------------------------------------------------------
          : Python Pages >>> http://starship.skyport.net/~lemburg/  :
           ---------------------------------------------------------



From mal@lemburg.com  Wed Apr 21 22:51:11 1999
From: mal@lemburg.com (M.-A. Lemburg)
Date: Wed, 21 Apr 1999 23:51:11 +0200
Subject: [Python-Dev] Notice of intent: rich comparisons
References: <Pine.WNT.4.04.9904211142330.174-100000@rigoletto.ski.org>
 <199904211904.PAA14966@eric.cnri.reston.va.us> <199904212006.PAA17138@tartarus.cs.uchicago.edu>
Message-ID: <371E484F.22046FE9@lemburg.com>

David Beazley wrote:
> 
> >
> > Misc
> >
> 
> Depending on how deep I want to dig, I may have some patches to
> ParseTuple() that would make life easier for some of us extension
> writing fans.  As it is right now, my experimental version of Swig
> is using it's own version of ParseTuple (for various reasons).
> Also, out of curiousity, is anyone making heavy use of the CObject
> type right now?

You mean the one in Objects/cobject.c ? Sure, all my type extensions
export their C API that way... and it works just great (no more
linker problems, nice error messages when extensions are not found,
etc.).

-- 
Marc-Andre Lemburg                               Y2000: 254 days left
---------------------------------------------------------------------
          : Python Pages >>> http://starship.skyport.net/~lemburg/  :
           ---------------------------------------------------------



From da@ski.org  Wed Apr 21 22:56:17 1999
From: da@ski.org (David Ascher)
Date: Wed, 21 Apr 1999 14:56:17 -0700 (Pacific Daylight Time)
Subject: [Python-Dev] Notice of intent: rich comparisons
In-Reply-To: <371E484F.22046FE9@lemburg.com>
Message-ID: <Pine.WNT.4.04.9904211453390.201-100000@rigoletto.ski.org>

David Beazley wrote:

> Also, out of curiousity, is anyone making heavy use of the CObject
> type right now?

NumPy does.

--da



From MHammond@skippinet.com.au  Thu Apr 22 00:45:19 1999
From: MHammond@skippinet.com.au (Mark Hammond)
Date: Thu, 22 Apr 1999 09:45:19 +1000
Subject: [Python-Dev] Notice of intent: rich comparisons
In-Reply-To: <092701be8c32$3a4ad9f0$f29b12c2@pythonware.com>
Message-ID: <004c01be8c51$043f27c0$0801a8c0@bobcat>

[Guido and /F]
> > Unicode
> >
> > What is the status of /F's latest attempts?
>
> most of the code is written and tested; the API still
> needs some cleaning up. I also have a few patches
> and other contributions in my inbox that I gotta
> look into...

Im one of those contributors :-)  I have made changes to the Win32
extensions that allows it to use /F's type instead of its own built-in
Unicode type.  Further, the Windows CE port of these extensions actually
enables this - so we have some code actively using it.

However, this still doesnt give me anything more than I had before.  We
need at least _some_ level of integration of this type into Python.  The
key areas to me are:

* PyArg_ParseTuple and Py_BuildValue - Seems OK we use the "u" format
character analogous to "s".  We havent thought of a "z" equivilent.  This
is fairly easy.

* Some way for these functions to auto-convert.  Eg, when the user passes
an 8bit string object, but the C side of the world wants a Unicode string.
This is harder, as an extra memory buffer for the conversion is needed.

This second problem is, to me, the next stumbling block.  When we sort
these out, I feel we would have the start of a good platform to start
experimenting.

Mark.



From Fred L. Drake, Jr." <fdrake@acm.org  Thu Apr 22 15:47:35 1999
From: Fred L. Drake, Jr." <fdrake@acm.org (Fred L. Drake)
Date: Thu, 22 Apr 1999 10:47:35 -0400 (EDT)
Subject: [Python-Dev] Notice of intent: rich comparisons
In-Reply-To: <16290078@toto.iv>
Message-ID: <14111.13959.211874.750734@weyr.cnri.reston.va.us>

David Beazley writes:
 > Maybe I'm just lucky, but I've written nothing but ANSI C for the last
 > 8 years and have never had a problem compiling it on any machine.  I
 > don't see this as being a huge issue.

  Wasn't SunOS 4.x the problem child here?  There are still a lot of
people using these systems, for reasons that aren't clear to me.  (Did 
support for some older hardware get dropped?  Sounds like the most
reasonable reason to use the old OS is legacy hardware.)


  -Fred

--
Fred L. Drake, Jr.	     <fdrake@acm.org>
Corporation for National Research Initiatives


From bwarsaw@cnri.reston.va.us (Barry A. Warsaw)  Thu Apr 22 16:37:46 1999
From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw)
Date: Thu, 22 Apr 1999 11:37:46 -0400 (EDT)
Subject: [Python-Dev] Notice of intent: rich comparisons
References: <16290078@toto.iv>
 <14111.13959.211874.750734@weyr.cnri.reston.va.us>
Message-ID: <14111.16970.839894.147748@anthem.cnri.reston.va.us>

>>>>> "Fred" == Fred L Drake <fdrake@cnri.reston.va.us> writes:

    Fred>   Wasn't SunOS 4.x the problem child here?  There are still
    Fred> a lot of people using these systems, for reasons that aren't
    Fred> clear to me.  (Did support for some older hardware get
    Fred> dropped?  Sounds like the most reasonable reason to use the
    Fred> old OS is legacy hardware.)

There might be, but the bundled compiler in SunOS 4 was never intended 
to be used for anything more than recompiling the kernel.  Years ago,
I had conversations with Sun engineers who claimed that no bug in the
bundled compiler was ever fixed unless it directly impacted on kernel
rebuilds.  Even back then they recommended using something other than
the bundled crufty old K&R compiler for building all other stuff, and
this was when there was that huge hoopla over the unbundling of the
compiler.

SunOS 4 users can probably be mostly satisfied with gcc.

-Barry


From Fred L. Drake, Jr." <fdrake@acm.org  Thu Apr 22 16:42:57 1999
From: Fred L. Drake, Jr." <fdrake@acm.org (Fred L. Drake)
Date: Thu, 22 Apr 1999 11:42:57 -0400 (EDT)
Subject: [Python-Dev] Notice of intent: rich comparisons
In-Reply-To: <14111.16970.839894.147748@anthem.cnri.reston.va.us>
References: <16290078@toto.iv>
 <14111.13959.211874.750734@weyr.cnri.reston.va.us>
 <14111.16970.839894.147748@anthem.cnri.reston.va.us>
Message-ID: <14111.17281.999490.718527@weyr.cnri.reston.va.us>

Barry A. Warsaw writes:
 > There might be, but the bundled compiler in SunOS 4 was never intended 
 > to be used for anything more than recompiling the kernel.  Years ago,
...
 > SunOS 4 users can probably be mostly satisfied with gcc.

Barry,
  This is good enough for me.  I'd certainly rather avoid K&R C!


  -Fred

--
Fred L. Drake, Jr.	     <fdrake@acm.org>
Corporation for National Research Initiatives


From skip@mojam.com (Skip Montanaro)  Thu Apr 22 18:18:39 1999
From: skip@mojam.com (Skip Montanaro) (skip@mojam.com (Skip Montanaro))
Date: Thu, 22 Apr 1999 13:18:39 -0400 (EDT)
Subject: [Python-Dev] Notice of intent: rich comparisons
In-Reply-To: <14111.17281.999490.718527@weyr.cnri.reston.va.us>
References: <16290078@toto.iv>
 <14111.13959.211874.750734@weyr.cnri.reston.va.us>
 <14111.16970.839894.147748@anthem.cnri.reston.va.us>
 <14111.17281.999490.718527@weyr.cnri.reston.va.us>
Message-ID: <14111.22873.161727.15206@cm-29-94-14.nycap.rr.com>

    Barry> SunOS 4 users can probably be mostly satisfied with gcc.

    Fred>  This is good enough for me.  I'd certainly rather avoid K&R C!

Besides, aren't there tools available that can strip most of the ANSI-ness
out of ANSI C?  (Un)Protoize?  For those (few?) people who are really still
stuck using a K&R compiler I would think those tools, perhaps supplemented
with some patch files maintained outside the main Python source tree, would
be sufficient.

Skip Montanaro	| Mojam: "Uniting the World of Music" http://www.mojam.com/
skip@mojam.com  | Musi-Cal: http://www.musi-cal.com/
518-372-5583


From bwarsaw@python.org  Thu Apr 22 19:07:57 1999
From: bwarsaw@python.org (Barry A. Warsaw)
Date: Thu, 22 Apr 1999 14:07:57 -0400 (EDT)
Subject: [Python-Dev] Notice of intent: rich comparisons
References: <16290078@toto.iv>
 <14111.13959.211874.750734@weyr.cnri.reston.va.us>
 <14111.16970.839894.147748@anthem.cnri.reston.va.us>
 <14111.17281.999490.718527@weyr.cnri.reston.va.us>
 <14111.22873.161727.15206@cm-29-94-14.nycap.rr.com>
Message-ID: <14111.25981.74738.355264@anthem.cnri.reston.va.us>

>>>>> "skip" ==   <skip@mojam.com> writes:

    skip> Besides, aren't there tools available that can strip most of
    skip> the ANSI-ness out of ANSI C?  (Un)Protoize?

I think so.  Seems I have unprotoize already; probably got it for free
with gcc, or some other GNU tool.

-B


From skip@mojam.com (Skip Montanaro)  Thu Apr 22 19:22:51 1999
From: skip@mojam.com (Skip Montanaro) (skip@mojam.com (Skip Montanaro))
Date: Thu, 22 Apr 1999 14:22:51 -0400 (EDT)
Subject: [Python-Dev] Notice of intent: rich comparisons
In-Reply-To: <371E4746.22A84506@lemburg.com>
References: <Pine.WNT.4.04.9904211142330.174-100000@rigoletto.ski.org>
 <199904211904.PAA14966@eric.cnri.reston.va.us>
 <371E4746.22A84506@lemburg.com>
Message-ID: <14111.23085.737365.582406@cm-29-94-14.nycap.rr.com>

    mal> There's some good work out there by Skip Montanaro to revamp the VM
    mal> into a combined register/stack machine. He calls it rattlesnake.
    mal> More infos can be found in the list archive (it's currently
    mal> sleeping):

Thanks to Marc-Andre for mentioning this.  Rattlesnake is indeed sleeping at
the moment.  If anyone is interested in the idea I'd be happy to awaken it.

The main observation was that much of the virtual machine's activity is
pushing/popping objects to/from the stack.  By treating a chunk of storage
as a register file much of that churn can be avoided.

Skip Montanaro	| Mojam: "Uniting the World of Music" http://www.mojam.com/
skip@mojam.com  | Musi-Cal: http://www.musi-cal.com/
518-372-5583


From fredrik@pythonware.com  Fri Apr 23 08:48:14 1999
From: fredrik@pythonware.com (Fredrik Lundh)
Date: Fri, 23 Apr 1999 09:48:14 +0200
Subject: [Python-Dev] Compiling ANSI C on K&R compilers
References: <16290078@toto.iv><14111.13959.211874.750734@weyr.cnri.reston.va.us><14111.16970.839894.147748@anthem.cnri.reston.va.us><14111.17281.999490.718527@weyr.cnri.reston.va.us> <14111.22873.161727.15206@cm-29-94-14.nycap.rr.com>
Message-ID: <00df01be8d5d$a82b2f70$f29b12c2@pythonware.com>

> Besides, aren't there tools available that can strip most of the ANSI-ness
> out of ANSI C?  (Un)Protoize?  For those (few?) people who are really still
> stuck using a K&R compiler I would think those tools, perhaps supplemented
> with some patch files maintained outside the main Python source tree, would
> be sufficient.

I mentioned ansi2knr.c in an earlier post.  It's a small utility,
and can be distributed with the Python core (it's GPL'd, but
since it isn't linked with Python, that's not a problem).

this is used by ghostscript and the ijg jpeg library, among
others:

ftp://ftp.cs.wisc.edu/ghost/ansi2knr.c
(or via http://www.cs.wisc.edu/~ghost/)

Cheers /F
fredrik@pythonware.com
http://www.pythonware.com



From gstein@lyra.org  Fri Apr 23 11:37:02 1999
From: gstein@lyra.org (Greg Stein)
Date: Fri, 23 Apr 1999 03:37:02 -0700
Subject: [Python-Dev] Notice of intent: rich comparisons
References: <Pine.WNT.4.04.9904211142330.174-100000@rigoletto.ski.org> <199904211904.PAA14966@eric.cnri.reston.va.us>
Message-ID: <37204D4E.2C02ABE2@lyra.org>

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/


From Fred L. Drake, Jr." <fdrake@acm.org  Fri Apr 23 14:28:12 1999
From: Fred L. Drake, Jr." <fdrake@acm.org (Fred L. Drake)
Date: Fri, 23 Apr 1999 09:28:12 -0400 (EDT)
Subject: [Python-Dev] Notice of intent: rich comparisons
In-Reply-To: <37204D4E.2C02ABE2@lyra.org>
References: <Pine.WNT.4.04.9904211142330.174-100000@rigoletto.ski.org>
 <199904211904.PAA14966@eric.cnri.reston.va.us>
 <37204D4E.2C02ABE2@lyra.org>
Message-ID: <14112.30060.552422.975547@weyr.cnri.reston.va.us>

Greg Stein writes:
 > 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)

  The Doc/ stuff is already in a separate distribution; this has been
in place for about a year (if I recall correctly).  I try to make doc
releases shortly after Python releases (I think the 1.5.2 doc release
is the longest I've waited past the Python release so far, and it may
end up being next week), and I have made interim releases as the
documentation has grown.
  I certainly think that doing something similar for the Demo/ and
Tools/ directories would be reasonable; they could share a single
distribution.


  -Fred

--
Fred L. Drake, Jr.	     <fdrake@acm.org>
Corporation for National Research Initiatives


From skip@mojam.com (Skip Montanaro)  Fri Apr 23 14:59:02 1999
From: skip@mojam.com (Skip Montanaro) (skip@mojam.com (Skip Montanaro))
Date: Fri, 23 Apr 1999 09:59:02 -0400 (EDT)
Subject: [Python-Dev] Notice of intent: rich comparisons
In-Reply-To: <14112.30060.552422.975547@weyr.cnri.reston.va.us>
References: <Pine.WNT.4.04.9904211142330.174-100000@rigoletto.ski.org>
 <199904211904.PAA14966@eric.cnri.reston.va.us>
 <37204D4E.2C02ABE2@lyra.org>
 <14112.30060.552422.975547@weyr.cnri.reston.va.us>
Message-ID: <14112.31858.374462.469793@cm-29-94-14.nycap.rr.com>

    Fred> I certainly think that doing something similar for the Demo/ and
    Fred> Tools/ directories would be reasonable; they could share a single
    Fred> distribution.

We need to make sure none of the tools are needed in the install
process. h2py comes to mind.

Skip Montanaro	| Mojam: "Uniting the World of Music" http://www.mojam.com/
skip@mojam.com  | Musi-Cal: http://www.musi-cal.com/
518-372-5583


From jeremy@cnri.reston.va.us  Mon Apr 26 16:26:28 1999
From: jeremy@cnri.reston.va.us (Jeremy Hylton)
Date: Mon, 26 Apr 1999 11:26:28 -0400 (EDT)
Subject: [Python-Dev] Notice of intent: rich comparisons
In-Reply-To: <37204D4E.2C02ABE2@lyra.org>
References: <Pine.WNT.4.04.9904211142330.174-100000@rigoletto.ski.org>
 <199904211904.PAA14966@eric.cnri.reston.va.us>
 <37204D4E.2C02ABE2@lyra.org>
Message-ID: <14116.33341.371508.53071@bitdiddle.cnri.reston.va.us>

>>>>> "GS" == Greg Stein <gstein@lyra.org> writes:

  >> Greg Stein's new httplib.py (or Jeremy's?)

  GS> Mine is a drop-in replacement for the current
  GS> httplib.py. httplib.HTTP is compatible with the current version
  GS> and does HTTP/1.0.  httplib.HTTPConnection is similar to the
  GS> other (but (IMO) cleans up a few elements of the API); it does
  GS> HTTP/1.1, including persistent connections. This module follows
  GS> the design of the original httplib.py much more
  GS> closely. Jeremy's module uses a very different design approach
  GS> (no value judgement here; it's just different); also, it simply
  GS> copies over the old HTTP class, while mine derives the
  GS> compatible version from HTTPConnection. I'm not sure how much
  GS> testing Jeremy's has had, but I use my module for all
  GS> Python-based http work now. Some number of other people have
  GS> downloaded and used it, too.

  GS> I would recommend my new module, given the two options.

I think I agree.  I stopped working on my version quite some time ago, 
before I made enough progress to make it useful.  Thus, it makes a lot 
of sense to use Greg's working code.

I'd be curious to see how to use HTTPConnection to do persistent
connections and pipelined requests.  It wasn't entirely clear from the 
code what I would need to do to keep the connection open.  Do you just
re-use the HTTPConnection object -- call putrequest again after
getreply? 

I like the revised API that Greg's code uses.  The request method on
HTTPConnection objects cleans the API up in exactly the right way.  It 
has always seemed unnecessary to have many separate calls to add
headers and then a call to endheaders after putrequest.  Packaging
them all together in one method will simplify client code a lot.

  GS> I'll eventually have a davlib.py to add to the distribution, but
  GS> it needs more work. I'll contribute that later.

Cool!

Jeremy



From guido@CNRI.Reston.VA.US  Mon Apr 26 17:16:11 1999
From: guido@CNRI.Reston.VA.US (Guido van Rossum)
Date: Mon, 26 Apr 1999 12:16:11 -0400
Subject: [Python-Dev] Public or private python-dev archives?
Message-ID: <199904261616.MAA22036@eric.cnri.reston.va.us>

In a private mail, Greg Stein suggested that the python-dev archives
should be restricted to the members of the list.  I prefer to make
them public, but I won't want to impose this on others without
discussion.  So I've made the archives private for the time being
while we discuss this meta-issue.  (Also, the existence of the list
isn't announced by mailman on its listinfo page.)

Here's my argument for open archives.  I don't think that we have
anything to hide from the public -- I think of us as a technical forum
whose discussions may affect others (e.g. Python users) and I think
it's often useful for those others to be able to see what we've said.

I want to keep membership of the list closed as a gentle way to
enforce focus and quality of discussion.

Jeremy pointed out that there's no restiction on posting, and
mentioned that together with open archives this makes the list just as
open as an open-subscription list.  I don't see this equivalence --
certainly it makes a difference in practice, and the open posting is
simply a mechanism to allow members with multiple email addresses to
post from whereever they are.  If we regularly get spammed or find the 
list is targeted by angry Python users we might have to restrict
posting to members (and deal with the multiple address problem).

I hope the discussion about this issue will be short (otherwise it
would detract from the real goal of this list).  I'll follow the
desire of the majority of current members; once we have a decision I
propose to stick with it and simply present new members with the
facts.

--Guido van Rossum (home page: http://www.python.org/~guido/)


From gward@cnri.reston.va.us  Mon Apr 26 17:30:43 1999
From: gward@cnri.reston.va.us (Greg Ward)
Date: Mon, 26 Apr 1999 12:30:43 -0400
Subject: [Python-Dev] Public or private python-dev archives?
In-Reply-To: <199904261616.MAA22036@eric.cnri.reston.va.us>; from Guido van Rossum on Mon, Apr 26, 1999 at 12:16:11PM -0400
References: <199904261616.MAA22036@eric.cnri.reston.va.us>
Message-ID: <19990426123042.A2617@cnri.reston.va.us>

On 26 April 1999, Guido van Rossum said:
> In a private mail, Greg Stein suggested that the python-dev archives
> should be restricted to the members of the list.  I prefer to make
> them public, but I won't want to impose this on others without
> discussion.  So I've made the archives private for the time being
> while we discuss this meta-issue.  (Also, the existence of the list
> isn't announced by mailman on its listinfo page.)
> 
> Here's my argument for open archives.  I don't think that we have
> anything to hide from the public -- I think of us as a technical forum
> whose discussions may affect others (e.g. Python users) and I think
> it's often useful for those others to be able to see what we've said.

I favour as much openness as possible that's consistent with high
signal-to-noise.  Opening the archives doesn't affect SN ratio; for that
matter, neither does allowing anyone to *read* the list while keeping
posting privileges restricted.  And letting the world know that the list
exists -- even though posting privileges are restricted -- shouldn't
affect quality.

So I guess my position is: definitely open the archives and publicise
the list -- the benefit of an open archive is reduced if people can't
stumble across it like they can any sig.  And consider the possibility
of open subscription while keeping posting restricted.  Not sure how
easy that is with Mailman, but we can still consider the idea.

The open, friendly nature of the Python community is a huge strength.  I
tentatively agree that posting privileges should be restricted to keep
quality high, but the idea of a "secret cabal" discussing Python
development off in a dark corner away from the grubby masses seems very
counter to the spirit I've seen so far.

        Greg
-- 
Greg Ward - software developer                    gward@cnri.reston.va.us
Corporation for National Research Initiatives    
1895 Preston White Drive                           voice: +1-703-620-8990
Reston, Virginia, USA  20191-5434                    fax: +1-703-620-0913


From da@ski.org  Mon Apr 26 17:29:56 1999
From: da@ski.org (David Ascher)
Date: Mon, 26 Apr 1999 09:29:56 -0700 (Pacific Daylight Time)
Subject: [Python-Dev] Public or private python-dev archives?
In-Reply-To: <199904261616.MAA22036@eric.cnri.reston.va.us>
Message-ID: <Pine.WNT.4.04.9904260922170.273-100000@rigoletto.ski.org>

On Mon, 26 Apr 1999, Guido van Rossum wrote:

> In a private mail, Greg Stein suggested that the python-dev archives
> should be restricted to the members of the list.  I prefer to make
> them public, but I won't want to impose this on others without
> discussion.  So I've made the archives private for the time being
> while we discuss this meta-issue.  (Also, the existence of the list
> isn't announced by mailman on its listinfo page.)

If one has a public archive with restricted membership, then one needs to
have a process for people to petition membership, including policies on
deciding admission (which could be as vague as "up to GvR's whim").

FWIW, the perl5-porters list is open but the perl6-porters list is closed.

My suggestion is that we can start with an open policy on archives, and
the lax posting policy for the multiple email address business (which
should be incorporated in mailman++ =), with the explicitely stated caveat
that if it turns out that that policy doesn't work, we reserve the right
to tighten things up. I also suggest that we don't advertise the fact that
anyone can post.  [Except of course that we've just mentioned this in
archives which I'm arguing should be public =)]

--david




From bwarsaw@cnri.reston.va.us (Barry A. Warsaw)  Mon Apr 26 18:44:36 1999
From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw)
Date: Mon, 26 Apr 1999 13:44:36 -0400 (EDT)
Subject: [Python-Dev] Public or private python-dev archives?
References: <199904261616.MAA22036@eric.cnri.reston.va.us>
 <19990426123042.A2617@cnri.reston.va.us>
Message-ID: <14116.42500.284907.569281@anthem.cnri.reston.va.us>

>>>>> "GW" == Greg Ward <gward@cnri.reston.va.us> writes:

    GW> And consider the possibility of open subscription while
    GW> keeping posting restricted.  Not sure how easy that is with
    GW> Mailman, but we can still consider the idea.

It could be done in a number of ways.  You could restrict postings to
members only, but as Guido has pointed out, a lot of people post from
more than one account and Mailman doesn't handle that very well yet.
Or you could moderate the list, but then someone has to approve
postings and that's more work than I think anybody wants to do.

I'm also for an open-as-possible policy, with the right to restrict
later if the s/n gets too low.  I sort of view Python-dev to be the
place that serious c.l.py proposals get fleshed out and implementation 
strategies discussed.  The (hopefully) high level of technical detail
on the list should self-select.

-Barry


From gmcm@hypernet.com  Mon Apr 26 19:56:52 1999
From: gmcm@hypernet.com (Gordon McMillan)
Date: Mon, 26 Apr 1999 13:56:52 -0500
Subject: [Python-Dev] Public or private python-dev archives?
In-Reply-To: <14116.42500.284907.569281@anthem.cnri.reston.va.us>
Message-ID: <1286969269-56980208@hypernet.com>

[Barry]
> The (hopefully) high level of
> technical detail on the list should self-select.

I thought the humor did that.

If the public-archive were only updated weekly, it would make it's 
use (or abuse) as glorified help list pretty tenuous.

No one has espoused Greg's reasoning. In the abscense of 
said arguments, I'm certainly inclined to vote for "as public as can 
be and still be focused".

-OTOH-then-I'll-never-know-what-goes-on-in-the-smoke-filled-room-ly 
y'rs

- Gordon


From da@ski.org  Mon Apr 26 20:12:54 1999
From: da@ski.org (David Ascher)
Date: Mon, 26 Apr 1999 12:12:54 -0700 (Pacific Daylight Time)
Subject: [Python-Dev] Why unbundle Tools and Demo?
Message-ID: <Pine.WNT.4.04.9904261203430.59-100000@rigoletto.ski.org>

Several people argue for unbundling Tools/ and Demo/ in 1.6.  I'd like to
argue to leave them in.  They're not especially big, and IMHO they are
quite valuable, *especially* to the novice user.  In fact, I'd like to
argue that Demo/ should be promoted to the same status as Tools/ (by which
I mean included in the Windows binary distribution). Unbundling Tools/
would mean unbundling IDLE, which IMHO would be a big strategic mistake.

However, I wouldn't be against a cleanup of said directories.  Some things
should probably be removed (anything which uses stdwin), some of the code
in classes is showing its age (notes about "being upgraded for Python 1.1"
=), etc.  That said, the tkinter/ directory is the best place to look for
simple Tkinter code, and should be included, IMHO.

--david










From guido@CNRI.Reston.VA.US  Mon Apr 26 20:20:26 1999
From: guido@CNRI.Reston.VA.US (Guido van Rossum)
Date: Mon, 26 Apr 1999 15:20:26 -0400
Subject: [Python-Dev] Why unbundle Tools and Demo?
In-Reply-To: Your message of "Mon, 26 Apr 1999 12:12:54 PDT."
 <Pine.WNT.4.04.9904261203430.59-100000@rigoletto.ski.org>
References: <Pine.WNT.4.04.9904261203430.59-100000@rigoletto.ski.org>
Message-ID: <199904261920.PAA22415@eric.cnri.reston.va.us>

> Several people argue for unbundling Tools/ and Demo/ in 1.6.  I'd like to
> argue to leave them in.  They're not especially big, and IMHO they are
> quite valuable, *especially* to the novice user.  In fact, I'd like to
> argue that Demo/ should be promoted to the same status as Tools/ (by which
> I mean included in the Windows binary distribution). Unbundling Tools/
> would mean unbundling IDLE, which IMHO would be a big strategic mistake.
> 
> However, I wouldn't be against a cleanup of said directories.  Some things
> should probably be removed (anything which uses stdwin), some of the code
> in classes is showing its age (notes about "being upgraded for Python 1.1"
> =), etc.  That said, the tkinter/ directory is the best place to look for
> simple Tkinter code, and should be included, IMHO.

Agreed.  One simple thing that would help me immensely would be for
someone to go through all the various Demo directories and make an
inventary of what is there and how useful it is, (1) to all Python
users, (2) to Windows users.  Then, perhaps someone could write a
simple document making these files (and Tools) more accessible...

--Guido van Rossum (home page: http://www.python.org/~guido/)


From da@ski.org  Mon Apr 26 20:20:40 1999
From: da@ski.org (David Ascher)
Date: Mon, 26 Apr 1999 12:20:40 -0700 (Pacific Daylight Time)
Subject: [Python-Dev] Why unbundle Tools and Demo?
In-Reply-To: <199904261920.PAA22415@eric.cnri.reston.va.us>
Message-ID: <Pine.WNT.4.04.9904261220200.59-100000@rigoletto.ski.org>

> someone to go through all the various Demo directories and make an
> inventary of what is there and how useful it is, (1) to all Python
> users, (2) to Windows users.  Then, perhaps someone could write a
> simple document making these files (and Tools) more accessible...

Ok.  I can do that.





From guido@CNRI.Reston.VA.US  Mon Apr 26 20:22:55 1999
From: guido@CNRI.Reston.VA.US (Guido van Rossum)
Date: Mon, 26 Apr 1999 15:22:55 -0400
Subject: [Python-Dev] Why unbundle Tools and Demo?
In-Reply-To: Your message of "Mon, 26 Apr 1999 12:20:40 PDT."
 <Pine.WNT.4.04.9904261220200.59-100000@rigoletto.ski.org>
References: <Pine.WNT.4.04.9904261220200.59-100000@rigoletto.ski.org>
Message-ID: <199904261922.PAA22447@eric.cnri.reston.va.us>

[me]
> > someone to go through all the various Demo directories and make an
> > inventary of what is there and how useful it is, (1) to all Python
> > users, (2) to Windows users.  Then, perhaps someone could write a
> > simple document making these files (and Tools) more accessible...

[Dave]
> Ok.  I can do that.

Great!  I didn't mean to volunteer you -- but I think you'd do a great 
job.

--Guido van Rossum (home page: http://www.python.org/~guido/)


From tim_one@email.msn.com  Tue Apr 27 05:25:19 1999
From: tim_one@email.msn.com (Tim Peters)
Date: Tue, 27 Apr 1999 00:25:19 -0400
Subject: [Python-Dev] Public or private python-dev archives?
In-Reply-To: <19990426123042.A2617@cnri.reston.va.us>
Message-ID: <000501be9065$f5e3db80$ab9e2299@tim>

[Greg Ward, arguing in favor of
    ...
    a "secret cabal" discussing Python development off in a dark corner
    away from the grubby masses
]

That's what I'd like too -- but somebody already let Gordon in <wink>.

voting-to-leave-it-public-until-there's-a-problem-ly y'rs  - tim




From da@ski.org  Tue Apr 27 20:23:55 1999
From: da@ski.org (David Ascher)
Date: Tue, 27 Apr 1999 12:23:55 -0700 (Pacific Daylight Time)
Subject: [Python-Dev] numpy
Message-ID: <Pine.WNT.4.04.9904271220520.64-100000@rigoletto.ski.org>

What are the thoughts on NumPy integration into the core?

--David



From MHammond@skippinet.com.au  Wed Apr 28 00:28:59 1999
From: MHammond@skippinet.com.au (Mark Hammond)
Date: Wed, 28 Apr 1999 09:28:59 +1000
Subject: [Python-Dev] numpy
In-Reply-To: <Pine.WNT.4.04.9904271220520.64-100000@rigoletto.ski.org>
Message-ID: <001c01be9105$bae7ccd0$0801a8c0@bobcat>

> What are the thoughts on NumPy integration into the core?

he he - and while we are at it :-)  mxDateTime would need to be a popular
choice for inclusion, and Guido has offered in-principle support for moving
some of the Win32 stuff into the core - particularly the Registry stuff and
the native Window Handle support...

How far do we go :-)

Personally, I would simply like to see the distutils SIG solve this problem
for us.  (sure).  Eg, the "build" or "install" process (depending on the
OS) could build a local HTML file with knowledge many "common" extensions -
a single click, and it is downloaded, configured and built.   Oh well, back
to reality...

[Which isnt to say I am opposed to NumPy and mxDateTime.  Definately keen
on the win32 stuff tho :-]

Mark.



From da@ski.org  Wed Apr 28 00:31:56 1999
From: da@ski.org (David Ascher)
Date: Tue, 27 Apr 1999 16:31:56 -0700 (Pacific Daylight Time)
Subject: [Python-Dev] numpy
In-Reply-To: <001c01be9105$bae7ccd0$0801a8c0@bobcat>
Message-ID: <Pine.WNT.4.04.9904271628320.64-100000@rigoletto.ski.org>

On Wed, 28 Apr 1999, Mark Hammond wrote:

> > What are the thoughts on NumPy integration into the core?
> 
> he he - and while we are at it :-)  mxDateTime would need to be a popular
> choice for inclusion, and Guido has offered in-principle support for moving
> some of the Win32 stuff into the core - particularly the Registry stuff and
> the native Window Handle support...

It may seem strange, but I'll argue for the win32 registry calls before
the NumPy stuff.  That could be because I've looked at NumPy code and not
the win32 code.  Not Jim's cleanest code. =)

Mark, can you describe 'native Window Handle' support?

--david




From MHammond@skippinet.com.au  Wed Apr 28 06:03:48 1999
From: MHammond@skippinet.com.au (Mark Hammond)
Date: Wed, 28 Apr 1999 15:03:48 +1000
Subject: [Python-Dev] numpy
In-Reply-To: <Pine.WNT.4.04.9904271628320.64-100000@rigoletto.ski.org>
Message-ID: <001e01be9134$809ca8f0$0801a8c0@bobcat>

> It may seem strange, but I'll argue for the win32 registry
> calls before
> the NumPy stuff.  That could be because I've looked at NumPy
> code and not
> the win32 code.  Not Jim's cleanest code. =)

he he - and I can even get out of the Win32 stuff - I wrote a string-only
first version, and Bill Tutt rehashed it into what it is today, handling
all the registry types.

OTOH, there could also be a case for moving "win32api" completely to "core
status" (whether that means truly core or simply a standard .pyd).  For
example, ntpath.py now has code that attempts to use
"win32api.GetFullPathName()".

The down-side is that win32api has nowhere near complete coverage, and is
really a mixed bag of bits and pieces.  Most later efforts where complete
API sets are given coverage have different names - eg, win32file has the
complete Win32 file API wrapped up - even if there are overlaps with
existing functions in win32api.

Im not sure what the answer is - my guess is a new core module with Win32
features deemed absolutely necessary for the core - stuff like the
registry, and a few assorted other functions, such as GetFullPathName, but
stopping well short of the full win32api set.

> Mark, can you describe 'native Window Handle' support?

Sure!  We have a very light-weight "handle" object, representing a Win32
handle.  It has no methods, and a single property for returning the
underlying win32 handle as an integer.  When the object destructs, it calls
"CloseHandle()".  Thats about it!

It has no methods, so is passed as an argument.  There has been no attempt
to implement things like "handle.Read()" to represent "ReadFile(handle,
...)".  There are 2 reasons for this:
1) Handles are fairly general purpose, and not restricted to IO operations.
A handle is also used to represent a Mutex/Semaphores and
threads/processes - certainly doesnt make sense to have a "Read()" method
for those handles.
2) IMO, this should be done at the .py level anyway.  The Win32 Handle
support is pure C++ at the moment.

A simple complication is that there are 3 types of handles in use at the
moment - those that call "CloseHandle", those that call "RegCloseHandle"
(registry handles) and a 3rd I cant recall.  This is currently implemented
using C++ inheritance.  But even if the current implementation is not
favoured, the object is so small that a rewrite would not be a problem.

And for those that can be bothered to read this far, some more background:
Some time ago, Greg and I decided to implement a "pywintypes" module.  This
defines what we considered "core types" for the Win32 world.  All our
extension modules (including win32api, COM; basically win32*.pyd) use this
module.  The objects it supports are: Unicode, Handles, Win32 Time, IIDs,
Overlapped IO objects, 3 NT security related objects and importantly a
standard Win32 exception and functions for filling it.

Moving the registry stuff is dependant on the core having the Exception,
Handle and Registry support (hence this discussion).  We have our own Time
object, but mxDateTime would be fine.  One day, we hope to remove this
pywintypes entirely, as the core will have it all :-)

Mark.



From gward@cnri.reston.va.us  Wed Apr 28 13:51:43 1999
From: gward@cnri.reston.va.us (Greg Ward)
Date: Wed, 28 Apr 1999 08:51:43 -0400
Subject: [Python-Dev] numpy
In-Reply-To: <001c01be9105$bae7ccd0$0801a8c0@bobcat>; from Mark Hammond on Wed, Apr 28, 1999 at 09:28:59AM +1000
References: <Pine.WNT.4.04.9904271220520.64-100000@rigoletto.ski.org> <001c01be9105$bae7ccd0$0801a8c0@bobcat>
Message-ID: <19990428085143.A5571@cnri.reston.va.us>

On 28 April 1999, Mark Hammond said:
> How far do we go :-)
> 
> Personally, I would simply like to see the distutils SIG solve this problem
> for us.  (sure).  Eg, the "build" or "install" process (depending on the
> OS) could build a local HTML file with knowledge many "common" extensions -
> a single click, and it is downloaded, configured and built.   Oh well, back
> to reality...

It's not impossible, it just takes a while.  I think it took the Perl
community about three years to go from "hey! let's have a standard build
mechanism for modules!" to the point where I can install (almost) any
module from CPAN with one shell command:

  perl -MCPAN -e 'install ("MIME::Base64");'

which is insanely cool.  (It took about two minutes to do the above just
now; that included trying two CPAN mirrors that aren't being cooperative
this morning, finding one that was working, downloading the current
module list from it, determining that there is a more recent version
available than the one installed here, downloading it, unpacking it,
running "Makefile.PL" to generate the Makefile, running "make" [which
compiles any extensions in the distribution, copies all the .pm files
around, and generates the documentation], "make test" [run the module's
self-test suite], and "make install" [install it in the "site-perl"
library directory].  Amount of user interaction required: typing the
above command line.)

It's *still* rough around the edges, though, especially when building a
new installation from scratch -- mainly because Perl doesn't ship with
ftp or http libraries, so the CPAN.pm module has to try downloading
stuff with lynx, ncftp, or plain ol' ftp until it has downloaded and
installed the libnet and libwww-perl distributions.  That's one problem
we won't have with Python, at least.  Oh yeah, and it all works *great*
under Unix... but the rest of the world lags behind.

Also, two major components of being able to do this -- the Perl Module
List and CPAN -- are still vapourware in Python-land.  But hey, if we
can get to the "we *have* a standard build mechanism for modules!"
point, then all the rest becomes a lot more feasible.

Pep talk over...

        Greg
-- 
Greg Ward - software developer                    gward@cnri.reston.va.us
Corporation for National Research Initiatives    
1895 Preston White Drive                           voice: +1-703-620-8990
Reston, Virginia, USA  20191-5434                    fax: +1-703-620-0913


From mal@lemburg.com  Wed Apr 28 08:44:25 1999
From: mal@lemburg.com (M.-A. Lemburg)
Date: Wed, 28 Apr 1999 09:44:25 +0200
Subject: [Python-Dev] numpy
References: <001c01be9105$bae7ccd0$0801a8c0@bobcat>
Message-ID: <3726BC59.35E3C9DB@lemburg.com>

Mark Hammond wrote:
> 
> > What are the thoughts on NumPy integration into the core?
> 
> he he - and while we are at it :-)  mxDateTime would need to be a popular
> choice for inclusion, and Guido has offered in-principle support for moving
> some of the Win32 stuff into the core - particularly the Registry stuff and
> the native Window Handle support...
> 
> How far do we go :-)
> 
> Personally, I would simply like to see the distutils SIG solve this problem
> for us.  (sure).  Eg, the "build" or "install" process (depending on the
> OS) could build a local HTML file with knowledge many "common" extensions -
> a single click, and it is downloaded, configured and built.   Oh well, back
> to reality...

You're talking about fast moving targets there... are you sure that
you want those in the standard distribution ?

Maybe we have two distributions: the standard one and a pro
edition with all the slick stuff included (together with a
proper setup script to get those references to external libs
and include files right).

Actually, this is something I've been wanting to do for nearly
a year now... just haven't found the time to really get things
the way I want them. It's a project called Python Power Tools
and includes many generic extensions (currently only ones that
don't rely on external libs).

If you're interested, have a look at an old version available at:

    http://starship.skyport.net/~lemburg/PowerTools-0.2.zip

It includes the extensions BTree, mxDateTime, mxTools, mxStack,
Trie, avl and kjbuckets. NumPy should probably also be included.
The current setup uses a recursive Makefile approach (not too
elegant, but works). A distutils setup would be much better.

-- 
Marc-Andre Lemburg                               Y2000: 247 days left
---------------------------------------------------------------------
          : Python Pages >>> http://starship.skyport.net/~lemburg/  :
           ---------------------------------------------------------




From jack@oratrix.nl  Wed Apr 28 14:48:21 1999
From: jack@oratrix.nl (Jack Jansen)
Date: Wed, 28 Apr 1999 15:48:21 +0200
Subject: [Python-Dev] numpy
In-Reply-To: Message by "Mark Hammond" <MHammond@skippinet.com.au> ,
 Wed, 28 Apr 1999 09:28:59 +1000 , <001c01be9105$bae7ccd0$0801a8c0@bobcat>
Message-ID: <19990428134821.E9A68300F57@snelboot.oratrix.nl>

> [...] Guido has offered in-principle support for moving
> some of the Win32 stuff into the core - particularly the Registry stuff and
> the native Window Handle support...

I think it would be nice to put all the stuff that is shared between modules 
(I think that's only PyWinTypes, but who am I to think I have a clue about the 
windows port:-) into the core.

I just did the same for MacPython, and it makes life a whole lot easier.
--
Jack Jansen             | ++++ stop the execution of Mumia Abu-Jamal ++++
Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++
www.oratrix.nl/~jack    | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm 




From skip@mojam.com (Skip Montanaro)  Wed Apr 28 16:57:40 1999
From: skip@mojam.com (Skip Montanaro) (skip@mojam.com (Skip Montanaro))
Date: Wed, 28 Apr 1999 11:57:40 -0400
Subject: [Python-Dev] LLNL C++ as base for Python 2?
Message-ID: <199904281557.LAA06491@cm-29-94-14.nycap.rr.com>

Have we been talking about Python 2 or Python 1.6?  If we're talking about
Python 2, has anyone given a serious look at the LLNL gang's C++/Python
stuff?  If I recall Paul Dubois' talk at the last conference, it sounded
like their work made it much easier to implement extension modules.

Skip Montanaro	| Mojam: "Uniting the World of Music" http://www.mojam.com/
skip@mojam.com  | Musi-Cal: http://www.musi-cal.com/
518-372-5583



From guido@CNRI.Reston.VA.US  Wed Apr 28 17:06:03 1999
From: guido@CNRI.Reston.VA.US (Guido van Rossum)
Date: Wed, 28 Apr 1999 12:06:03 -0400
Subject: [Python-Dev] LLNL C++ as base for Python 2?
In-Reply-To: Your message of "Wed, 28 Apr 1999 11:57:40 EDT."
 <199904281557.LAA06491@cm-29-94-14.nycap.rr.com>
References: <199904281557.LAA06491@cm-29-94-14.nycap.rr.com>
Message-ID: <199904281606.MAA27526@eric.cnri.reston.va.us>

> Have we been talking about Python 2 or Python 1.6?  If we're talking about
> Python 2, has anyone given a serious look at the LLNL gang's C++/Python
> stuff?  If I recall Paul Dubois' talk at the last conference, it sounded
> like their work made it much easier to implement extension modules.

I've mostly had 1.6 in mind.  See recent traffic in the C++ SIG
archives for the status of Paul's CXX.

--Guido van Rossum (home page: http://www.python.org/~guido/)


From da@ski.org  Wed Apr 28 18:24:00 1999
From: da@ski.org (David Ascher)
Date: Wed, 28 Apr 1999 10:24:00 -0700 (Pacific Daylight Time)
Subject: [Python-Dev] LLNL C++ as base for Python 2?
In-Reply-To: <199904281606.MAA27526@eric.cnri.reston.va.us>
Message-ID: <Pine.WNT.4.04.9904281021061.346-100000@rigoletto.ski.org>

On Wed, 28 Apr 1999, Guido van Rossum wrote:

> > Have we been talking about Python 2 or Python 1.6?  If we're talking about
> > Python 2, has anyone given a serious look at the LLNL gang's C++/Python
> > stuff?  If I recall Paul Dubois' talk at the last conference, it sounded
> > like their work made it much easier to implement extension modules.
> 
> I've mostly had 1.6 in mind.  See recent traffic in the C++ SIG
> archives for the status of Paul's CXX.

Recent traffic?  There's nothing in there that's substantive since... uh,
well, I got tired of looking back. =)

CXX is very cool, but it is still pushing the envelope of many C++
compilers.  From what I gather, recent egcs' do manage with it, and since
egcs is going to replace gcc, I expect that many platforms will be able to
"do" CXX relatively soon.

I vote to stay on the 1.6 track for now.



From MHammond@skippinet.com.au  Fri Apr 30 03:40:09 1999
From: MHammond@skippinet.com.au (Mark Hammond)
Date: Fri, 30 Apr 1999 12:40:09 +1000
Subject: [Python-Dev] More flexible namespaces.
Message-ID: <008d01be92b2$c56ef5d0$0801a8c0@bobcat>

Here is a bit of an idea that I first came up with some years ago.  Guido's
response at the time was "sounds reasonable as long as we dont slow the
normal case down".

To cut a long story short, I would like eval and exec to be capable of
working with arbitrary mapping objects rather than only dictionaries.  The
general idea is that I can provide a class with mapping semantics, and pass
this to exec/eval.

This would give us 2 seriously cool features (that I want <wink>), should
anyone decide to write code that enables them:

* Case insensitive namespaces.  This would be very cool for COM, and as far
as I know would please the Alice people.  May open up more embedding
opportunities that are lost if people feel strongly about this issue.

* Dynamic name lookups.  At the moment, dynamic attribute lookups are
simple, but dynamic name lookups are hard.  If I execute code "print foo",
foo _must_ pre-exist in the namespace.  There is no reasonable way I can
some up with so that I can fetch "foo" as it is requested (raising the
NameError if necessary).  This would also be very cool for some of the COM
work - particularly Active Scripting.

Of course, these would not be enabled by standard Python, but would allow
people to create flexible execution environments that suit their purpose.

Any comments on this?  Is it a dumb idea?  Anyone have a feel for how deep
these changes would cut?  Its not something I want to happen soon, but it
does seem a reasonable mechanism that can provide very flexible
solutions...

Mark.



From guido@CNRI.Reston.VA.US  Fri Apr 30 04:00:52 1999
From: guido@CNRI.Reston.VA.US (Guido van Rossum)
Date: Thu, 29 Apr 1999 23:00:52 -0400
Subject: [Python-Dev] More flexible namespaces.
In-Reply-To: Your message of "Fri, 30 Apr 1999 12:40:09 +1000."
 <008d01be92b2$c56ef5d0$0801a8c0@bobcat>
References: <008d01be92b2$c56ef5d0$0801a8c0@bobcat>
Message-ID: <199904300300.XAA00608@eric.cnri.reston.va.us>

> To cut a long story short, I would like eval and exec to be capable of
> working with arbitrary mapping objects rather than only dictionaries.  The
> general idea is that I can provide a class with mapping semantics, and pass
> this to exec/eval.

I agree that this would be seriously cool.  It will definitely be in
Python 2.0; it's already in JPython.

Quite a while ago, Ian Castleden sent me patches for 1.5.1 to do this.
It was a lot of code and I was indeed worried about slowing things
down too much (and also about checking that he got all the endcases
right).

Ian did benchmarks and found that the new code was consistently
slower, by 3-6%.  Perhaps for Python 1.6 this will be acceptable (the
"Python IS slow" thread notwithstanding :-); or perhaps someone can
have a look at it and squeeze some more time out of it?  I'll gladly
forward the patches.

--Guido van Rossum (home page: http://www.python.org/~guido/)


From da@ski.org  Fri Apr 30 04:21:04 1999
From: da@ski.org (David Ascher)
Date: Thu, 29 Apr 1999 20:21:04 -0700 (Pacific Daylight Time)
Subject: [Python-Dev] More flexible namespaces.
In-Reply-To: <199904300300.XAA00608@eric.cnri.reston.va.us>
Message-ID: <Pine.WNT.4.05.9904292018290.153-100000@david.ski.org>

> > To cut a long story short, I would like eval and exec to be capable of
> > working with arbitrary mapping objects rather than only dictionaries.  The
> > general idea is that I can provide a class with mapping semantics, and pass
> > this to exec/eval.
> 
> I agree that this would be seriously cool.  It will definitely be in
> Python 2.0; it's already in JPython.

Seriously cool is an understatement. 

--david



From MHammond@skippinet.com.au  Fri Apr 30 05:13:25 1999
From: MHammond@skippinet.com.au (Mark Hammond)
Date: Fri, 30 Apr 1999 14:13:25 +1000
Subject: [Python-Dev] More flexible namespaces.
In-Reply-To: <199904300300.XAA00608@eric.cnri.reston.va.us>
Message-ID: <009001be92bf$cb998f80$0801a8c0@bobcat>

> Ian did benchmarks and found that the new code was consistently
> slower, by 3-6%.  Perhaps for Python 1.6 this will be acceptable (the
> "Python IS slow" thread notwithstanding :-); or perhaps someone can

As long as we get someone working on a consistent 3-6% speedup in other
areas this wont be a problem :-)

I will attach it to my long list - but Im going to put all my efforts here
into Unicode first, and probably the threading stuff second :-)

Mark.



From tismer@appliedbiometrics.com  Fri Apr 30 08:49:42 1999
From: tismer@appliedbiometrics.com (Christian Tismer)
Date: Fri, 30 Apr 1999 09:49:42 +0200
Subject: [Python-Dev] More flexible namespaces.
References: <008d01be92b2$c56ef5d0$0801a8c0@bobcat> <199904300300.XAA00608@eric.cnri.reston.va.us>
Message-ID: <37296096.D0C9C2CC@appliedbiometrics.com>


Guido van Rossum wrote:
...
> Ian did benchmarks and found that the new code was consistently
> slower, by 3-6%.  Perhaps for Python 1.6 this will be acceptable (the
> "Python IS slow" thread notwithstanding :-); or perhaps someone can
> have a look at it and squeeze some more time out of it?  I'll gladly
> forward the patches.

I'd really like to look into that.
Also I wouldn't worry too much about speed, since this is 
such a cool feature. It might even be a speedup in some cases
which otherwise would need more complex handling.

May I have a look?

ciao - chris

-- 
Christian Tismer             :^)   <mailto:tismer@appliedbiometrics.com>
Applied Biometrics GmbH      :     Have a break! Take a ride on Python's
Kaiserin-Augusta-Allee 101   :    *Starship* http://starship.python.net
10553 Berlin                 :     PGP key -> http://wwwkeys.pgp.net
PGP Fingerprint       E182 71C7 1A9D 66E9 9D15  D3CC D4D7 93E2 1FAE F6DF
     we're tired of banana software - shipped green, ripens at home


From mal@lemburg.com  Fri Apr 30 09:22:46 1999
From: mal@lemburg.com (M.-A. Lemburg)
Date: Fri, 30 Apr 1999 10:22:46 +0200
Subject: [Python-Dev] More flexible namespaces.
References: <008d01be92b2$c56ef5d0$0801a8c0@bobcat>
Message-ID: <37296856.5875AAAF@lemburg.com>

Mark Hammond wrote:
> 
> Here is a bit of an idea that I first came up with some years ago.  Guido's
> response at the time was "sounds reasonable as long as we dont slow the
> normal case down".
> 
> To cut a long story short, I would like eval and exec to be capable of
> working with arbitrary mapping objects rather than only dictionaries.  The
> general idea is that I can provide a class with mapping semantics, and pass
> this to exec/eval.

This involves a whole lot of changes: not only in the Python core,
but also in extensions that rely on having real dictionaries available.

Since you put out to objectives, I'd like to propose a little
different approach...

1. Have eval/exec accept any mapping object as input

2. Make those two copy the content of the mapping object into real
   dictionaries

3. Provide a hook into the dictionary implementation that can be
   used to redirect KeyErrors and use that redirection to forward
   the request to the original mapping objects

> This would give us 2 seriously cool features (that I want <wink>), should
> anyone decide to write code that enables them:
> 
> * Case insensitive namespaces.  This would be very cool for COM, and as far
> as I know would please the Alice people.  May open up more embedding
> opportunities that are lost if people feel strongly about this issue.

This is covered by 1 and 2.

> * Dynamic name lookups.  At the moment, dynamic attribute lookups are
> simple, but dynamic name lookups are hard.  If I execute code "print foo",
> foo _must_ pre-exist in the namespace.  There is no reasonable way I can
> some up with so that I can fetch "foo" as it is requested (raising the
> NameError if necessary).  This would also be very cool for some of the COM
> work - particularly Active Scripting.

This is something for 3.

I guess it wouldn't cause any significant slow-down and can be
imlemented with much less code than the "change all PyDict_GetItem
to PyObject_GetItem" thingie.

The real thing could then be done for 2.0 where PyDict_Check()
would presumably not rely on an adress but some kind of inheritance
scheme indicating that the object is in fact a dictionary.

Cheers,
-- 
Marc-Andre Lemburg                               Y2000: 245 days left
---------------------------------------------------------------------
          : Python Pages >>> http://starship.skyport.net/~lemburg/  :
           ---------------------------------------------------------



From guido@CNRI.Reston.VA.US  Fri Apr 30 16:17:20 1999
From: guido@CNRI.Reston.VA.US (Guido van Rossum)
Date: Fri, 30 Apr 1999 11:17:20 -0400
Subject: [Python-Dev] More flexible namespaces.
In-Reply-To: Your message of "Fri, 30 Apr 1999 09:49:42 +0200."
 <37296096.D0C9C2CC@appliedbiometrics.com>
References: <008d01be92b2$c56ef5d0$0801a8c0@bobcat> <199904300300.XAA00608@eric.cnri.reston.va.us>
 <37296096.D0C9C2CC@appliedbiometrics.com>
Message-ID: <199904301517.LAA01422@eric.cnri.reston.va.us>

> From: Christian Tismer <tismer@appliedbiometrics.com>

> I'd really like to look into that.
> Also I wouldn't worry too much about speed, since this is 
> such a cool feature. It might even be a speedup in some cases
> which otherwise would need more complex handling.
> 
> May I have a look?

Sure!

(I've forwarded Christian the files per separate mail.)

I'm also interested in your opinion on how well thought-out and robust
the patches are -- I've never found the time to do a good close
reading of them.

--Guido van Rossum (home page: http://www.python.org/~guido/)


From gmcm@hypernet.com  Fri Apr 30 17:32:30 1999
From: gmcm@hypernet.com (Gordon McMillan)
Date: Fri, 30 Apr 1999 11:32:30 -0500
Subject: [Python-Dev] More flexible namespaces.
In-Reply-To: <199904301517.LAA01422@eric.cnri.reston.va.us>
References: Your message of "Fri, 30 Apr 1999 09:49:42 +0200."             <37296096.D0C9C2CC@appliedbiometrics.com>
Message-ID: <1286632328-77246936@hypernet.com>

Guido wrote:

> > From: Christian Tismer <tismer@appliedbiometrics.com>
> 
> > I'd really like to look into that.
> > Also I wouldn't worry too much about speed, since this is 
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > such a cool feature. It might even be a speedup in some cases
> > which otherwise would need more complex handling.
> > 
> > May I have a look?
> 
> Sure!
> 
> (I've forwarded Christian the files per separate mail.)

I don't know who you sent that to, but it couldn't possibly have been 
Christian!

- Gordon


From tismer@appliedbiometrics.com  Fri Apr 30 16:57:09 1999
From: tismer@appliedbiometrics.com (Christian Tismer)
Date: Fri, 30 Apr 1999 17:57:09 +0200
Subject: [Python-Dev] More flexible namespaces.
References: <008d01be92b2$c56ef5d0$0801a8c0@bobcat> <199904300300.XAA00608@eric.cnri.reston.va.us>
 <37296096.D0C9C2CC@appliedbiometrics.com> <199904301517.LAA01422@eric.cnri.reston.va.us>
Message-ID: <3729D2D5.6844D6DA@appliedbiometrics.com>


Guido van Rossum wrote:
> 
> > From: Christian Tismer <tismer@appliedbiometrics.com>
> > May I have a look?
> 
> Sure!
> 
> (I've forwarded Christian the files per separate mail.)

Thanks a lot! 

> I'm also interested in your opinion on how well thought-out and robust
> the patches are -- I've never found the time to do a good close
> reading of them.

Yes, it is quite long and not so very easy to digest.
At first glance, most of the changes are replacements of
dict access with mapping access where we pay for the extra
indirection.
It depends on how often this feature will really replace
dicts. If dicts are more common, I'd like to figure out
how much code bloat extra special casing for dicts would give.

Puha - thanks - chris

-- 
Christian Tismer             :^)   <mailto:tismer@appliedbiometrics.com>
Applied Biometrics GmbH      :     Have a break! Take a ride on Python's
Kaiserin-Augusta-Allee 101   :    *Starship* http://starship.python.net
10553 Berlin                 :     PGP key -> http://wwwkeys.pgp.net
PGP Fingerprint       E182 71C7 1A9D 66E9 9D15  D3CC D4D7 93E2 1FAE F6DF
     we're tired of banana software - shipped green, ripens at home


From tismer@appliedbiometrics.com  Fri Apr 30 17:19:57 1999
From: tismer@appliedbiometrics.com (Christian Tismer)
Date: Fri, 30 Apr 1999 18:19:57 +0200
Subject: [Python-Dev] More flexible namespaces.
References: Your message of "Fri, 30 Apr 1999 09:49:42 +0200."             <37296096.D0C9C2CC@appliedbiometrics.com> <1286632328-77246936@hypernet.com>
Message-ID: <3729D82D.CE16884@appliedbiometrics.com>


Gordon McMillan wrote:
> 
> Guido wrote:
> 
> > > From: Christian Tismer <tismer@appliedbiometrics.com>
> >
> > > I'd really like to look into that.
> > > Also I wouldn't worry too much about speed, since this is
>     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > > such a cool feature. It might even be a speedup in some cases
> > > which otherwise would need more complex handling.
> > >
> > > May I have a look?
> >
> > Sure!
> >
> > (I've forwarded Christian the files per separate mail.)
> 
> I don't know who you sent that to, but it couldn't possibly have been
> Christian!

:-) :-) truely not if I had'n other things in mind.

I know that I will not get more than 30-40 percent by compiling
the interpreter away, so I will not even spend time at a
register machine right now. Will also not follow the ideas of
P2C any longer, doesn't pay off.
Instead, If I can manage to create something like static binding
snapshots, then I could resolve many of the lookups and internal
method indirections, for time critical applications.
For all the rest, Python is pretty much fast enough.

I've begun to write s special platform dependant version
which allows me to do all the things which can't go into the dist.
For instance, I just saved some 10 percent by dynamically
patching some of the ParseTuple and BuildObject calls out of the
core code (ahem). I hope Python will stay as clean as it is,
allowing me to try all kinds of tricks for one machine class.

ciao - chris.speedy

-- 
Christian Tismer             :^)   <mailto:tismer@appliedbiometrics.com>
Applied Biometrics GmbH      :     Have a break! Take a ride on Python's
Kaiserin-Augusta-Allee 101   :    *Starship* http://starship.python.net
10553 Berlin                 :     PGP key -> http://wwwkeys.pgp.net
PGP Fingerprint       E182 71C7 1A9D 66E9 9D15  D3CC D4D7 93E2 1FAE F6DF
     we're tired of banana software - shipped green, ripens at home


From akuchlin@cnri.reston.va.us  Fri Apr 30 17:33:34 1999
From: akuchlin@cnri.reston.va.us (Andrew M. Kuchling)
Date: Fri, 30 Apr 1999 12:33:34 -0400 (EDT)
Subject: [Python-Dev] More flexible namespaces.
In-Reply-To: <3729D82D.CE16884@appliedbiometrics.com>
References: <37296096.D0C9C2CC@appliedbiometrics.com>
 <1286632328-77246936@hypernet.com>
 <3729D82D.CE16884@appliedbiometrics.com>
Message-ID: <14121.55659.754846.708467@amarok.cnri.reston.va.us>

Christian Tismer writes:
>Instead, If I can manage to create something like static binding
>snapshots, then I could resolve many of the lookups and internal
>method indirections, for time critical applications.

	The usual assumption is that the lookups are what takes time.
Now, are we sure of that assumption?  I'd expect the lookup code to be
like:

1) Get hash of name
2) Retrieve object from dictionary
3) Do something with the object.

Now, since string objects cache their hash value, 1) should usually be
just "if (obj->cached_hash_value!=-1) return obj->cached_hash_value";
a comparision and a return.  Step 2) should be very fast, barring a
bad hash function.  So perhaps most of the time is spent in 3),
creating new local dicts, stack frames, and what not.  (Yes, I know
that doing this on every reference to an object is part of the
problem.)  I also wonder about the costs of all the Py_BuildValue and
Py_ParseTuple calls going on under the hood.  A performance
improvement project would definitely be a good idea for 1.6, and a
good sub-topic for python-dev.

	Incidentally, what's the verdict on python-dev archives:
public or not?

-- 
A.M. Kuchling			http://starship.python.net/crew/amk/
Despair says little, and is patient.
    -- From SANDMAN: "Season of Mists", episode 0



From tismer@appliedbiometrics.com  Fri Apr 30 17:55:55 1999
From: tismer@appliedbiometrics.com (Christian Tismer)
Date: Fri, 30 Apr 1999 18:55:55 +0200
Subject: [Python-Dev] More flexible namespaces.
References: <37296096.D0C9C2CC@appliedbiometrics.com>
 <1286632328-77246936@hypernet.com>
 <3729D82D.CE16884@appliedbiometrics.com> <14121.55659.754846.708467@amarok.cnri.reston.va.us>
Message-ID: <3729E09B.5F65E3CA@appliedbiometrics.com>


"Andrew M. Kuchling" wrote:
> 
> Christian Tismer writes:
> >Instead, If I can manage to create something like static binding
> >snapshots, then I could resolve many of the lookups and internal
> >method indirections, for time critical applications.
> 
>         The usual assumption is that the lookups are what takes time.
> Now, are we sure of that assumption?  I'd expect the lookup code to be
> like:
> 
> 1) Get hash of name
> 2) Retrieve object from dictionary
> 3) Do something with the object.
...
Right, but when you become more restrictive, you can do
lots, lots more. If I also allow to fix the type of an object,
I can go under the hood of the Python API, so you could
add some points 4) 5) 6) here.
But I shouldn't have talked before I can show something.
And at the time, I don't restrict myself to write clean
code, but try very machine specific things which I
don't believe should go into Python at all.

> I also wonder about the costs of all the Py_BuildValue and
> Py_ParseTuple calls going on under the hood.  A performance
> improvement project would definitely be a good idea for 1.6, and a
> good sub-topic for python-dev.

I wasn't sure, so I first wrote a module which does statistics
on that, and I found a lot of these calls. Some are even 
involved in ceval's code, where things like "(OOOO)" is parsed
all over again and again. Now I think this is ok in most cases.
But in some places these are very bad: If your builtin function
soes so very few work. 
Take len(): This uses ParseTuple, which calls a function to
find out its object, then calls a function to get the object,
then takes the len, and builds the result. But since everything
has a length, checking for no NULL pointer and grabbing the len
produces even shorter code. This applies to many places as well.
But right now, I don't change the core, but build hacky little
extension modules which squeak such things out at runtime.
No big deal yet, but maybe it could pay off to introduce
format strings which make them more suitableto be used
in macro substitutions.

sorry if I was too elaborate, this is so much fun :-)

ciao - chris

-- 
Christian Tismer             :^)   <mailto:tismer@appliedbiometrics.com>
Applied Biometrics GmbH      :     Have a break! Take a ride on Python's
Kaiserin-Augusta-Allee 101   :    *Starship* http://starship.python.net
10553 Berlin                 :     PGP key -> http://wwwkeys.pgp.net
PGP Fingerprint       E182 71C7 1A9D 66E9 9D15  D3CC D4D7 93E2 1FAE F6DF
     we're tired of banana software - shipped green, ripens at home


From skip at mojam.com  Wed Apr 21 15:17:32 1999
From: skip at mojam.com (skip at mojam.com)
Date: Wed, 21 Apr 1999 09:17:32 -0400
Subject: [Python-Dev] ZServer 1.0b1: spurious colon in HTTP response line
Message-ID: <199904211317.JAA26167@cm-29-94-14.nycap.rr.com>

(Also reported to the bug catcher.)

I'm trying to migrate from ZopeHTTPServer to ZServer 1.0b1.  I was seeing
the ZServer headers turning up in pages generated by the process.  When I
viewed the page source of the generated HTML I saw:

    HTTP/1.0: 200 OK
    Server: Zope/experimental ZServer/1.1b1
    Date: Wed, 21 Apr 1999 13:00:38 GMT
    X-Powered-By: Zope (www.zope.org), Python (www.python.org)
    Connection: close
    Content-Type: text/html
    Content-Length: 7802
    

    <!-- -*-html-helper -*- -->
    <HTML>
    <HEAD>
    <TITLE>Musi-Cal... Concert Schedules: Folk Music, Country Music, Rock Music &amp; more!</TITLE>
    ...

I run ZServer behind an Apache 1.3.3 running mod_proxy.  Apparently Apache
doesn't recognize the HTTP response when there is a colon following the
version number and adds a simple set of headers itself.  I guess web
browsers either ignore that line or are more lenient in their parsing of the
response.

The following simple patch corrects the problem:

diff -c2 HTTPResponse.py.~1~ HTTPResponse.py
*** HTTPResponse.py.~1~	Tue Apr 13 15:21:12 1999
--- HTTPResponse.py	Wed Apr 21 09:05:00 1999
***************
*** 146,150 ****
       
          # status header must come first.
!         append("HTTP/%s: %s" % (self._http_version, status))
          if headers.has_key('status'):
              del headers['status']
--- 146,150 ----
       
          # status header must come first.
!         append("HTTP/%s %s" % (self._http_version, status))
          if headers.has_key('status'):
              del headers['status']
***************


Skip Montanaro	| Mojam: "Uniting the World of Music" http://www.mojam.com/
skip at mojam.com  | Musi-Cal: http://www.musi-cal.com/
518-372-5583



From da at ski.org  Wed Apr 21 20:47:56 1999
From: da at ski.org (David Ascher)
Date: Wed, 21 Apr 1999 11:47:56 -0700 (Pacific Daylight Time)
Subject: [Python-Dev] Notice of intent: rich comparisons
Message-ID: <Pine.WNT.4.04.9904211142330.174-100000@rigoletto.ski.org>

Now that 1.5.2 is finalized, I'll be starting to prepare a patch for the
rich comparisons.  

Guido, how do you envision python-dev working?  Do you want to hand out a
TODO list for 1.6?

--david





From guido at CNRI.Reston.VA.US  Wed Apr 21 21:04:40 1999
From: guido at CNRI.Reston.VA.US (Guido van Rossum)
Date: Wed, 21 Apr 1999 15:04:40 -0400
Subject: [Python-Dev] Notice of intent: rich comparisons
In-Reply-To: Your message of "Wed, 21 Apr 1999 11:47:56 PDT."
             <Pine.WNT.4.04.9904211142330.174-100000@rigoletto.ski.org> 
References: <Pine.WNT.4.04.9904211142330.174-100000@rigoletto.ski.org> 
Message-ID: <199904211904.PAA14966@eric.cnri.reston.va.us>

> Now that 1.5.2 is finalized, I'll be starting to prepare a patch for the
> rich comparisons.  

Cool!

> Guido, how do you envision python-dev working?

I though we'd just crack Monty Python jokes while pretending to work :-)

> Do you want to hand out a TODO list for 1.6?

Well, I'm not saying that this is the definitive list, but certainly
there are a bunch of things that definitely need to be incorporated.
Here's an excerpt of a list that I keep for myself, in no particular
order, with brief annotations (I have a meeting in 15 minutes :):

Redesign thread/init APIs

	See the recent discussion in the thread-sig.  There should be
	some kind of micro-init that initializes essential components
	(including the thread lock!) but doesn't create an interpreter
	or a threadstate object.  There should also be a notion of a
	default interpreter.

Break up into VM, parser, import, mainloop, and other components?

	The porting efforts to seriously small machines (Win/CE,
	Pilot, etc.) all seem to need a Python VM that doesn't
	automatically pull in the parser and interactive main loop.
	There are other reasons as well to isolate various parts
	of the functionality (including all numeric data types except
	ints).

	This could include: restructuring of the parser so codeop.py
	can be simplified; making the interactive main loop a script.

String methods

	Barry has his patches ready.

Unicode

	What is the status of /F's latest attempts?

Rich comparisons

	This is Dave's plan.

Coercions

	Marc-Andre Lemburg has some good suggestions here:
	http://starship.python.net/~lemburg/coercion-0.6.zip

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.

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

Buffer object API extensions

	Marc-Andre Lemburg has a patch

Distutil

	Should we start integrating some of the results of the
	distutil SIG?  (What's the status?  I haven't been paying
	attention.)

Misc

	Jeremy Hylton's urllib2.py

	Greg Stein's new httplib.py (or Jeremy's?)

	Andrew Kuchling's new PCRE release?

	The IPv6 patches?

Gotta run!

--Guido van Rossum (home page: http://www.python.org/~guido/)



From gward at cnri.reston.va.us  Wed Apr 21 21:10:08 1999
From: gward at cnri.reston.va.us (Greg Ward)
Date: Wed, 21 Apr 1999 15:10:08 -0400
Subject: [Python-Dev] Notice of intent: rich comparisons
In-Reply-To: <199904211904.PAA14966@eric.cnri.reston.va.us>; from Guido van Rossum on Wed, Apr 21, 1999 at 03:04:40PM -0400
References: <Pine.WNT.4.04.9904211142330.174-100000@rigoletto.ski.org> <199904211904.PAA14966@eric.cnri.reston.va.us>
Message-ID: <19990421151008.D6167@cnri.reston.va.us>

On 21 April 1999, Guido van Rossum said:
> Distutil
> 
> 	Should we start integrating some of the results of the
> 	distutil SIG?  (What's the status?  I haven't been paying
> 	attention.)

It's in a state that other people can look at the code, but (apparently)
not yet good enough for floods of patches to come in.  Right now,
Distutils has *just* enough marbles to "build" and install itself on
Unix systems, and someone has contributed a patch so it works on NT.  No
support yet for compiling extensions, which of course is the important
thing.

        Greg
-- 
Greg Ward - software developer                    gward at cnri.reston.va.us
Corporation for National Research Initiatives    
1895 Preston White Drive                           voice: +1-703-620-8990
Reston, Virginia, USA  20191-5434                    fax: +1-703-620-0913



From da at ski.org  Wed Apr 21 21:19:42 1999
From: da at ski.org (David Ascher)
Date: Wed, 21 Apr 1999 12:19:42 -0700 (Pacific Daylight Time)
Subject: [Python-Dev] Notice of intent: rich comparisons
In-Reply-To: <199904211904.PAA14966@eric.cnri.reston.va.us>
Message-ID: <Pine.WNT.4.04.9904211207010.174-100000@rigoletto.ski.org>

On Wed, 21 Apr 1999, Guido van Rossum wrote:

> > Guido, how do you envision python-dev working?
> 
> I though we'd just crack Monty Python jokes while pretending to work :-)

That'd be better than what I've read on the perl5-porters list in the last
couple of days (which I'm reading because of the ad hoopla).  They seem to
spend their time arguing about whether Perl codes are programs or scripts.  
Viciously, too. =)

More seriously, some of the discussions they're having a worth keeping an
eye on, just as a form of legal industrial spying.

> Import revamp

There was an interesting bit from Greg, Jack, and MarkH on this topic
recently in the distutil-sig.  Maybe one of them can bring the rest of us
up to date on the effort.

--david






From fredrik at pythonware.com  Wed Apr 21 22:04:54 1999
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Wed, 21 Apr 1999 22:04:54 +0200
Subject: [Python-Dev] Notice of intent: rich comparisons
References: <Pine.WNT.4.04.9904211142330.174-100000@rigoletto.ski.org>  <199904211904.PAA14966@eric.cnri.reston.va.us>
Message-ID: <092701be8c32$3a4ad9f0$f29b12c2@pythonware.com>

Guido wrote:

> String methods
> 
> Barry has his patches ready.
> 
> Unicode
> 
> What is the status of /F's latest attempts?

most of the code is written and tested; the API still
needs some cleaning up. I also have a few patches
and other contributions in my inbox that I gotta
look into...

btw, the unicode module can be compiled for 8-bit
characters too.  we could merge it with the string
module (one place to fix bugs...)

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

something similar to greg's imputil.py should definitely
be in the core...

> 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 ansi2knr.c (available from http://www.cs.wisc.edu/~ghost/).
otoh, it only converts function headers, so I'm not sure it's
worth the effort...

</F>




From beazley at cs.uchicago.edu  Wed Apr 21 22:06:50 1999
From: beazley at cs.uchicago.edu (David Beazley)
Date: Wed, 21 Apr 1999 15:06:50 -0500 (CDT)
Subject: [Python-Dev] Notice of intent: rich comparisons
References: <Pine.WNT.4.04.9904211142330.174-100000@rigoletto.ski.org>
	<199904211904.PAA14966@eric.cnri.reston.va.us>
Message-ID: <199904212006.PAA17138@tartarus.cs.uchicago.edu>

Guido van Rossum writes:
> 
> 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).
> 

Maybe I'm just lucky, but I've written nothing but ANSI C for the last
8 years and have never had a problem compiling it on any machine.  I
don't see this as being a huge issue.

> 
> Misc
>

Depending on how deep I want to dig, I may have some patches to
ParseTuple() that would make life easier for some of us extension
writing fans.  As it is right now, my experimental version of Swig
is using it's own version of ParseTuple (for various reasons).
Also, out of curiousity, is anyone making heavy use of the CObject
type right now?  

Cheers,

Dave





From jim at digicool.com  Wed Apr 21 23:15:24 1999
From: jim at digicool.com (Jim Fulton)
Date: Wed, 21 Apr 1999 17:15:24 -0400
Subject: [Python-Dev] Notice of intent: rich comparisons
References: <Pine.WNT.4.04.9904211142330.174-100000@rigoletto.ski.org>
		<199904211904.PAA14966@eric.cnri.reston.va.us> <199904212006.PAA17138@tartarus.cs.uchicago.edu>
Message-ID: <371E3FEC.9D19607A@digicool.com>


David Beazley wrote:
> 
> Guido van Rossum writes:
> >
> > 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).
> >
> 
> Maybe I'm just lucky, but I've written nothing but ANSI C for the last
> 8 years and have never had a problem compiling it on any machine.  I
> don't see this as being a huge issue.

I've had the same experience with things like prototypes.
The recent introduction of indented preprocessor instructions
caused me significant pain on some platforms.  Fortunately, I 
haven't had to deal with those platforms recently, still, the elegence
of indented preporicessor instructions wasn't worth the pain it caused.

As far as choice of compilers goes, sometimes gcc isn't an option.
I've had cases where I *had* to use the native compiler in order to
link to third-party libraries.

I support moving to ANSI C, for example, wrt prototypes, but
lets still be somewhat sensative to portability and not abuse 
bad compilers without good reason.


> 
> >
> > Misc
> >
> 
> Depending on how deep I want to dig, I may have some patches to
> ParseTuple() that would make life easier for some of us extension
> writing fans.  As it is right now, my experimental version of Swig
> is using it's own version of ParseTuple (for various reasons).
> Also, out of curiousity, is anyone making heavy use of the CObject
> type right now?

Yes.

Jim

--
Jim Fulton           mailto:jim at digicool.com   Python Powered!        
Technical Director   (888) 344-4332            http://www.python.org  
Digital Creations    http://www.digicool.com   http://www.zope.org    

Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email
address may not be added to any commercial mail list with out my
permission.  Violation of my privacy with advertising or SPAM will
result in a suit for a MINIMUM of $500 damages/incident, $1500 for
repeats.



From jeremy at cnri.reston.va.us  Wed Apr 21 23:23:57 1999
From: jeremy at cnri.reston.va.us (Jeremy Hylton)
Date: Wed, 21 Apr 1999 17:23:57 -0400 (EDT)
Subject: [Python-Dev] Notice of intent: rich comparisons
In-Reply-To: <199904212006.PAA17138@tartarus.cs.uchicago.edu>
References: <Pine.WNT.4.04.9904211142330.174-100000@rigoletto.ski.org>
	<199904211904.PAA14966@eric.cnri.reston.va.us>
	<199904212006.PAA17138@tartarus.cs.uchicago.edu>
Message-ID: <14110.16787.893181.642806@bitdiddle.cnri.reston.va.us>

>>>>> "DB" == David Beazley <beazley at cs.uchicago.edu> writes:

  DB> various reasons).  Also, out of curiousity, is anyone making
  DB> heavy use of the CObject type right now?

I used it a little, but only in a modified Python backend for SWIG. 

Jeremy



From mal at lemburg.com  Wed Apr 21 23:46:46 1999
From: mal at lemburg.com (M.-A. Lemburg)
Date: Wed, 21 Apr 1999 23:46:46 +0200
Subject: [Python-Dev] Notice of intent: rich comparisons
References: <Pine.WNT.4.04.9904211142330.174-100000@rigoletto.ski.org> <199904211904.PAA14966@eric.cnri.reston.va.us>
Message-ID: <371E4746.22A84506@lemburg.com>

Guido van Rossum wrote:
> 
> Break up into VM, parser, import, mainloop, and other components?
> 
>         The porting efforts to seriously small machines (Win/CE,
>         Pilot, etc.) all seem to need a Python VM that doesn't
>         automatically pull in the parser and interactive main loop.
>         There are other reasons as well to isolate various parts
>         of the functionality (including all numeric data types except
>         ints).
> 
>         This could include: restructuring of the parser so codeop.py
>         can be simplified; making the interactive main loop a script.

There's some good work out there by Skip Montanaro to revamp the
VM into a combined register/stack machine. He calls it rattlesnake.
More infos can be found in the list archive (it's currently sleeping):

	http://www.egroups.com/folders/rattlesnake

I would like to see the VM/compiler pluggable so that experiments
like rattlesnake become easier to implement (extension modules vs.
patches to the core interpreter).

> Coercions
> 
>         Marc-Andre Lemburg has some good suggestions here:
>         http://starship.python.net/~lemburg/coercion-0.6.zip

I will continue to work on these patches now that 1.5.2 is out.

There is a (more or less) detailed explanation of the patch set
at:

	http://starship.skyport.net/~lemburg/CoercionProposal.html

Instead of using of using the PY_NEWSTYLENUMBER approach I'll
turn to the new type flags that were introduced in 1.5.2. The
Py_NotImplemented singleton return value will stay, because
performance tests have shown that this method does not cause
any significant hit where as the exception raise and catch
method does introduce a significant slow-down.

> Import revamp

Greg's imputil.py (it's in the distutils package) should provide
a good start.

> Buffer object API extensions

I'll put the complete patch up on starship later this week...
here are the basic prototypes:

    DL_IMPORT(int) PyObject_AsCharBuffer Py_PROTO((PyObject *obj,
                                                   const char **buffer,
                                                   int *buffer_len));

    /* Takes an arbitrary object which must support the (character,
       single segment) buffer interface and returns a pointer to a
       read-only memory location useable as character based input for
       subsequent processing.

       buffer and buffer_len are only set in case no error
       occurrs. Otherwise, -1 is returned and an exception set.

    */

    DL_IMPORT(int) PyObject_AsReadBuffer Py_PROTO((PyObject *obj,
                                                   const void **buffer,
                                                   int *buffer_len));

    /* Same as PyObject_AsCharBuffer() except that this API expects
       (readable, single segment) buffer interface and returns a
       pointer to a read-only memory location which can contain
       arbitrary data.

       buffer and buffer_len are only set in case no error
       occurrs. Otherwise, -1 is returned and an exception set.

    */

    DL_IMPORT(int) PyObject_AsWriteBuffer Py_PROTO((PyObject *obj,
                                                    void **buffer,
                                                    int *buffer_len));
    
    /* Takes an arbitrary object which must support the (writeable,
       single segment) buffer interface and returns a pointer to a
       writeable memory location in buffer of size buffer_len.

       buffer and buffer_len are only set in case no error
       occurrs. Otherwise, -1 is returned and an exception set.

    */

> Distutil
> 
>         Should we start integrating some of the results of the
>         distutil SIG?  (What's the status?  I haven't been paying
>         attention.)

With all the different modules and packages available for Python
starting to slowly introduce dependencies, I think the main
objective should be introducing a well organized installation
info system, e.g. a registry where modules and packages can
query and save version and dependency information. Someone on
the main list mentioned that JPython has something like this...

> Misc
> 
>         Jeremy Hylton's urllib2.py
> 
>         Greg Stein's new httplib.py (or Jeremy's?)
> 
>         Andrew Kuchling's new PCRE release?
> 
>         The IPv6 patches?

These are on my wish list, so I'll simply add them here:

? APIs to faciliate creation of extensions classes (using Python
  classes and C functions as methods)

The main open question here is where and how to store C data in
the instances. This could also provide a way to migrate to
all Python classes for some future version.

? Restructure the calling mechanism used in ceval.c to make
  it clearer, more flexible and faster (of course, :-). Also,
  inline calling of C functions/methods (this produces a noticable
  speedup).

I have a patch for the restructuring and an old one (against 1.5)
for the C function call inlining.

? A "fastpath" hook made available through the sys module.

This should hook into the module/package loader and should be
used whenever set to find a module (reverting to the standard
lookup method in case it can't find it). I have an old patch
that does this. It uses a simple Python function to redirect the
lookup to a precalculated dictionary of installed modules/packages.
This results in faster startup of the Python interpreter (by saving
a few hundred stat() calls).

-- 
Marc-Andre Lemburg                               Y2000: 254 days left
---------------------------------------------------------------------
          : Python Pages >>> http://starship.skyport.net/~lemburg/  :
           ---------------------------------------------------------




From mal at lemburg.com  Wed Apr 21 23:51:11 1999
From: mal at lemburg.com (M.-A. Lemburg)
Date: Wed, 21 Apr 1999 23:51:11 +0200
Subject: [Python-Dev] Notice of intent: rich comparisons
References: <Pine.WNT.4.04.9904211142330.174-100000@rigoletto.ski.org>
		<199904211904.PAA14966@eric.cnri.reston.va.us> <199904212006.PAA17138@tartarus.cs.uchicago.edu>
Message-ID: <371E484F.22046FE9@lemburg.com>

David Beazley wrote:
> 
> >
> > Misc
> >
> 
> Depending on how deep I want to dig, I may have some patches to
> ParseTuple() that would make life easier for some of us extension
> writing fans.  As it is right now, my experimental version of Swig
> is using it's own version of ParseTuple (for various reasons).
> Also, out of curiousity, is anyone making heavy use of the CObject
> type right now?

You mean the one in Objects/cobject.c ? Sure, all my type extensions
export their C API that way... and it works just great (no more
linker problems, nice error messages when extensions are not found,
etc.).

-- 
Marc-Andre Lemburg                               Y2000: 254 days left
---------------------------------------------------------------------
          : Python Pages >>> http://starship.skyport.net/~lemburg/  :
           ---------------------------------------------------------




From da at ski.org  Wed Apr 21 23:56:17 1999
From: da at ski.org (David Ascher)
Date: Wed, 21 Apr 1999 14:56:17 -0700 (Pacific Daylight Time)
Subject: [Python-Dev] Notice of intent: rich comparisons
In-Reply-To: <371E484F.22046FE9@lemburg.com>
Message-ID: <Pine.WNT.4.04.9904211453390.201-100000@rigoletto.ski.org>

David Beazley wrote:

> Also, out of curiousity, is anyone making heavy use of the CObject
> type right now?

NumPy does.

--da




From MHammond at skippinet.com.au  Thu Apr 22 01:45:19 1999
From: MHammond at skippinet.com.au (Mark Hammond)
Date: Thu, 22 Apr 1999 09:45:19 +1000
Subject: [Python-Dev] Notice of intent: rich comparisons
In-Reply-To: <092701be8c32$3a4ad9f0$f29b12c2@pythonware.com>
Message-ID: <004c01be8c51$043f27c0$0801a8c0@bobcat>

[Guido and /F]
> > Unicode
> >
> > What is the status of /F's latest attempts?
>
> most of the code is written and tested; the API still
> needs some cleaning up. I also have a few patches
> and other contributions in my inbox that I gotta
> look into...

Im one of those contributors :-)  I have made changes to the Win32
extensions that allows it to use /F's type instead of its own built-in
Unicode type.  Further, the Windows CE port of these extensions actually
enables this - so we have some code actively using it.

However, this still doesnt give me anything more than I had before.  We
need at least _some_ level of integration of this type into Python.  The
key areas to me are:

* PyArg_ParseTuple and Py_BuildValue - Seems OK we use the "u" format
character analogous to "s".  We havent thought of a "z" equivilent.  This
is fairly easy.

* Some way for these functions to auto-convert.  Eg, when the user passes
an 8bit string object, but the C side of the world wants a Unicode string.
This is harder, as an extra memory buffer for the conversion is needed.

This second problem is, to me, the next stumbling block.  When we sort
these out, I feel we would have the start of a good platform to start
experimenting.

Mark.




From fdrake at cnri.reston.va.us  Thu Apr 22 16:47:35 1999
From: fdrake at cnri.reston.va.us (Fred L. Drake)
Date: Thu, 22 Apr 1999 10:47:35 -0400 (EDT)
Subject: [Python-Dev] Notice of intent: rich comparisons
In-Reply-To: <16290078@toto.iv>
Message-ID: <14111.13959.211874.750734@weyr.cnri.reston.va.us>

David Beazley writes:
 > Maybe I'm just lucky, but I've written nothing but ANSI C for the last
 > 8 years and have never had a problem compiling it on any machine.  I
 > don't see this as being a huge issue.

  Wasn't SunOS 4.x the problem child here?  There are still a lot of
people using these systems, for reasons that aren't clear to me.  (Did 
support for some older hardware get dropped?  Sounds like the most
reasonable reason to use the old OS is legacy hardware.)


  -Fred

--
Fred L. Drake, Jr.	     <fdrake at acm.org>
Corporation for National Research Initiatives



From bwarsaw at cnri.reston.va.us  Thu Apr 22 17:37:46 1999
From: bwarsaw at cnri.reston.va.us (Barry A. Warsaw)
Date: Thu, 22 Apr 1999 11:37:46 -0400 (EDT)
Subject: [Python-Dev] Notice of intent: rich comparisons
References: <16290078@toto.iv>
	<14111.13959.211874.750734@weyr.cnri.reston.va.us>
Message-ID: <14111.16970.839894.147748@anthem.cnri.reston.va.us>

>>>>> "Fred" == Fred L Drake <fdrake at cnri.reston.va.us> writes:

    Fred>   Wasn't SunOS 4.x the problem child here?  There are still
    Fred> a lot of people using these systems, for reasons that aren't
    Fred> clear to me.  (Did support for some older hardware get
    Fred> dropped?  Sounds like the most reasonable reason to use the
    Fred> old OS is legacy hardware.)

There might be, but the bundled compiler in SunOS 4 was never intended 
to be used for anything more than recompiling the kernel.  Years ago,
I had conversations with Sun engineers who claimed that no bug in the
bundled compiler was ever fixed unless it directly impacted on kernel
rebuilds.  Even back then they recommended using something other than
the bundled crufty old K&R compiler for building all other stuff, and
this was when there was that huge hoopla over the unbundling of the
compiler.

SunOS 4 users can probably be mostly satisfied with gcc.

-Barry



From fdrake at cnri.reston.va.us  Thu Apr 22 17:42:57 1999
From: fdrake at cnri.reston.va.us (Fred L. Drake)
Date: Thu, 22 Apr 1999 11:42:57 -0400 (EDT)
Subject: [Python-Dev] Notice of intent: rich comparisons
In-Reply-To: <14111.16970.839894.147748@anthem.cnri.reston.va.us>
References: <16290078@toto.iv>
	<14111.13959.211874.750734@weyr.cnri.reston.va.us>
	<14111.16970.839894.147748@anthem.cnri.reston.va.us>
Message-ID: <14111.17281.999490.718527@weyr.cnri.reston.va.us>

Barry A. Warsaw writes:
 > There might be, but the bundled compiler in SunOS 4 was never intended 
 > to be used for anything more than recompiling the kernel.  Years ago,
...
 > SunOS 4 users can probably be mostly satisfied with gcc.

Barry,
  This is good enough for me.  I'd certainly rather avoid K&R C!


  -Fred

--
Fred L. Drake, Jr.	     <fdrake at acm.org>
Corporation for National Research Initiatives



From skip at mojam.com  Thu Apr 22 19:18:39 1999
From: skip at mojam.com (skip at mojam.com)
Date: Thu, 22 Apr 1999 13:18:39 -0400 (EDT)
Subject: [Python-Dev] Notice of intent: rich comparisons
In-Reply-To: <14111.17281.999490.718527@weyr.cnri.reston.va.us>
References: <16290078@toto.iv>
	<14111.13959.211874.750734@weyr.cnri.reston.va.us>
	<14111.16970.839894.147748@anthem.cnri.reston.va.us>
	<14111.17281.999490.718527@weyr.cnri.reston.va.us>
Message-ID: <14111.22873.161727.15206@cm-29-94-14.nycap.rr.com>

    Barry> SunOS 4 users can probably be mostly satisfied with gcc.

    Fred>  This is good enough for me.  I'd certainly rather avoid K&R C!

Besides, aren't there tools available that can strip most of the ANSI-ness
out of ANSI C?  (Un)Protoize?  For those (few?) people who are really still
stuck using a K&R compiler I would think those tools, perhaps supplemented
with some patch files maintained outside the main Python source tree, would
be sufficient.

Skip Montanaro	| Mojam: "Uniting the World of Music" http://www.mojam.com/
skip at mojam.com  | Musi-Cal: http://www.musi-cal.com/
518-372-5583



From bwarsaw at cnri.reston.va.us  Thu Apr 22 20:07:57 1999
From: bwarsaw at cnri.reston.va.us (Barry A. Warsaw)
Date: Thu, 22 Apr 1999 14:07:57 -0400 (EDT)
Subject: [Python-Dev] Notice of intent: rich comparisons
References: <16290078@toto.iv>
	<14111.13959.211874.750734@weyr.cnri.reston.va.us>
	<14111.16970.839894.147748@anthem.cnri.reston.va.us>
	<14111.17281.999490.718527@weyr.cnri.reston.va.us>
	<14111.22873.161727.15206@cm-29-94-14.nycap.rr.com>
Message-ID: <14111.25981.74738.355264@anthem.cnri.reston.va.us>

>>>>> "skip" ==   <skip at mojam.com> writes:

    skip> Besides, aren't there tools available that can strip most of
    skip> the ANSI-ness out of ANSI C?  (Un)Protoize?

I think so.  Seems I have unprotoize already; probably got it for free
with gcc, or some other GNU tool.

-B



From skip at mojam.com  Thu Apr 22 20:22:51 1999
From: skip at mojam.com (skip at mojam.com)
Date: Thu, 22 Apr 1999 14:22:51 -0400 (EDT)
Subject: [Python-Dev] Notice of intent: rich comparisons
In-Reply-To: <371E4746.22A84506@lemburg.com>
References: <Pine.WNT.4.04.9904211142330.174-100000@rigoletto.ski.org>
	<199904211904.PAA14966@eric.cnri.reston.va.us>
	<371E4746.22A84506@lemburg.com>
Message-ID: <14111.23085.737365.582406@cm-29-94-14.nycap.rr.com>

    mal> There's some good work out there by Skip Montanaro to revamp the VM
    mal> into a combined register/stack machine. He calls it rattlesnake.
    mal> More infos can be found in the list archive (it's currently
    mal> sleeping):

Thanks to Marc-Andre for mentioning this.  Rattlesnake is indeed sleeping at
the moment.  If anyone is interested in the idea I'd be happy to awaken it.

The main observation was that much of the virtual machine's activity is
pushing/popping objects to/from the stack.  By treating a chunk of storage
as a register file much of that churn can be avoided.

Skip Montanaro	| Mojam: "Uniting the World of Music" http://www.mojam.com/
skip at mojam.com  | Musi-Cal: http://www.musi-cal.com/
518-372-5583



From fredrik at pythonware.com  Fri Apr 23 09:48:14 1999
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Fri, 23 Apr 1999 09:48:14 +0200
Subject: [Python-Dev] Compiling ANSI C on K&R compilers
References: <16290078@toto.iv><14111.13959.211874.750734@weyr.cnri.reston.va.us><14111.16970.839894.147748@anthem.cnri.reston.va.us><14111.17281.999490.718527@weyr.cnri.reston.va.us> <14111.22873.161727.15206@cm-29-94-14.nycap.rr.com>
Message-ID: <00df01be8d5d$a82b2f70$f29b12c2@pythonware.com>

> Besides, aren't there tools available that can strip most of the ANSI-ness
> out of ANSI C?  (Un)Protoize?  For those (few?) people who are really still
> stuck using a K&R compiler I would think those tools, perhaps supplemented
> with some patch files maintained outside the main Python source tree, would
> be sufficient.

I mentioned ansi2knr.c in an earlier post.  It's a small utility,
and can be distributed with the Python core (it's GPL'd, but
since it isn't linked with Python, that's not a problem).

this is used by ghostscript and the ijg jpeg library, among
others:

ftp://ftp.cs.wisc.edu/ghost/ansi2knr.c
(or via http://www.cs.wisc.edu/~ghost/)

Cheers /F
fredrik at pythonware.com
http://www.pythonware.com




From gstein at lyra.org  Fri Apr 23 12:37:02 1999
From: gstein at lyra.org (Greg Stein)
Date: Fri, 23 Apr 1999 03:37:02 -0700
Subject: [Python-Dev] Notice of intent: rich comparisons
References: <Pine.WNT.4.04.9904211142330.174-100000@rigoletto.ski.org> <199904211904.PAA14966@eric.cnri.reston.va.us>
Message-ID: <37204D4E.2C02ABE2@lyra.org>

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/



From fdrake at cnri.reston.va.us  Fri Apr 23 15:28:12 1999
From: fdrake at cnri.reston.va.us (Fred L. Drake)
Date: Fri, 23 Apr 1999 09:28:12 -0400 (EDT)
Subject: [Python-Dev] Notice of intent: rich comparisons
In-Reply-To: <37204D4E.2C02ABE2@lyra.org>
References: <Pine.WNT.4.04.9904211142330.174-100000@rigoletto.ski.org>
	<199904211904.PAA14966@eric.cnri.reston.va.us>
	<37204D4E.2C02ABE2@lyra.org>
Message-ID: <14112.30060.552422.975547@weyr.cnri.reston.va.us>

Greg Stein writes:
 > 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)

  The Doc/ stuff is already in a separate distribution; this has been
in place for about a year (if I recall correctly).  I try to make doc
releases shortly after Python releases (I think the 1.5.2 doc release
is the longest I've waited past the Python release so far, and it may
end up being next week), and I have made interim releases as the
documentation has grown.
  I certainly think that doing something similar for the Demo/ and
Tools/ directories would be reasonable; they could share a single
distribution.


  -Fred

--
Fred L. Drake, Jr.	     <fdrake at acm.org>
Corporation for National Research Initiatives



From skip at mojam.com  Fri Apr 23 15:59:02 1999
From: skip at mojam.com (skip at mojam.com)
Date: Fri, 23 Apr 1999 09:59:02 -0400 (EDT)
Subject: [Python-Dev] Notice of intent: rich comparisons
In-Reply-To: <14112.30060.552422.975547@weyr.cnri.reston.va.us>
References: <Pine.WNT.4.04.9904211142330.174-100000@rigoletto.ski.org>
	<199904211904.PAA14966@eric.cnri.reston.va.us>
	<37204D4E.2C02ABE2@lyra.org>
	<14112.30060.552422.975547@weyr.cnri.reston.va.us>
Message-ID: <14112.31858.374462.469793@cm-29-94-14.nycap.rr.com>

    Fred> I certainly think that doing something similar for the Demo/ and
    Fred> Tools/ directories would be reasonable; they could share a single
    Fred> distribution.

We need to make sure none of the tools are needed in the install
process. h2py comes to mind.

Skip Montanaro	| Mojam: "Uniting the World of Music" http://www.mojam.com/
skip at mojam.com  | Musi-Cal: http://www.musi-cal.com/
518-372-5583



From jeremy at cnri.reston.va.us  Mon Apr 26 17:26:28 1999
From: jeremy at cnri.reston.va.us (Jeremy Hylton)
Date: Mon, 26 Apr 1999 11:26:28 -0400 (EDT)
Subject: [Python-Dev] Notice of intent: rich comparisons
In-Reply-To: <37204D4E.2C02ABE2@lyra.org>
References: <Pine.WNT.4.04.9904211142330.174-100000@rigoletto.ski.org>
	<199904211904.PAA14966@eric.cnri.reston.va.us>
	<37204D4E.2C02ABE2@lyra.org>
Message-ID: <14116.33341.371508.53071@bitdiddle.cnri.reston.va.us>

>>>>> "GS" == Greg Stein <gstein at lyra.org> writes:

  >> Greg Stein's new httplib.py (or Jeremy's?)

  GS> Mine is a drop-in replacement for the current
  GS> httplib.py. httplib.HTTP is compatible with the current version
  GS> and does HTTP/1.0.  httplib.HTTPConnection is similar to the
  GS> other (but (IMO) cleans up a few elements of the API); it does
  GS> HTTP/1.1, including persistent connections. This module follows
  GS> the design of the original httplib.py much more
  GS> closely. Jeremy's module uses a very different design approach
  GS> (no value judgement here; it's just different); also, it simply
  GS> copies over the old HTTP class, while mine derives the
  GS> compatible version from HTTPConnection. I'm not sure how much
  GS> testing Jeremy's has had, but I use my module for all
  GS> Python-based http work now. Some number of other people have
  GS> downloaded and used it, too.

  GS> I would recommend my new module, given the two options.

I think I agree.  I stopped working on my version quite some time ago, 
before I made enough progress to make it useful.  Thus, it makes a lot 
of sense to use Greg's working code.

I'd be curious to see how to use HTTPConnection to do persistent
connections and pipelined requests.  It wasn't entirely clear from the 
code what I would need to do to keep the connection open.  Do you just
re-use the HTTPConnection object -- call putrequest again after
getreply? 

I like the revised API that Greg's code uses.  The request method on
HTTPConnection objects cleans the API up in exactly the right way.  It 
has always seemed unnecessary to have many separate calls to add
headers and then a call to endheaders after putrequest.  Packaging
them all together in one method will simplify client code a lot.

  GS> I'll eventually have a davlib.py to add to the distribution, but
  GS> it needs more work. I'll contribute that later.

Cool!

Jeremy




From guido at CNRI.Reston.VA.US  Mon Apr 26 18:16:11 1999
From: guido at CNRI.Reston.VA.US (Guido van Rossum)
Date: Mon, 26 Apr 1999 12:16:11 -0400
Subject: [Python-Dev] Public or private python-dev archives?
Message-ID: <199904261616.MAA22036@eric.cnri.reston.va.us>

In a private mail, Greg Stein suggested that the python-dev archives
should be restricted to the members of the list.  I prefer to make
them public, but I won't want to impose this on others without
discussion.  So I've made the archives private for the time being
while we discuss this meta-issue.  (Also, the existence of the list
isn't announced by mailman on its listinfo page.)

Here's my argument for open archives.  I don't think that we have
anything to hide from the public -- I think of us as a technical forum
whose discussions may affect others (e.g. Python users) and I think
it's often useful for those others to be able to see what we've said.

I want to keep membership of the list closed as a gentle way to
enforce focus and quality of discussion.

Jeremy pointed out that there's no restiction on posting, and
mentioned that together with open archives this makes the list just as
open as an open-subscription list.  I don't see this equivalence --
certainly it makes a difference in practice, and the open posting is
simply a mechanism to allow members with multiple email addresses to
post from whereever they are.  If we regularly get spammed or find the 
list is targeted by angry Python users we might have to restrict
posting to members (and deal with the multiple address problem).

I hope the discussion about this issue will be short (otherwise it
would detract from the real goal of this list).  I'll follow the
desire of the majority of current members; once we have a decision I
propose to stick with it and simply present new members with the
facts.

--Guido van Rossum (home page: http://www.python.org/~guido/)



From gward at cnri.reston.va.us  Mon Apr 26 18:30:43 1999
From: gward at cnri.reston.va.us (Greg Ward)
Date: Mon, 26 Apr 1999 12:30:43 -0400
Subject: [Python-Dev] Public or private python-dev archives?
In-Reply-To: <199904261616.MAA22036@eric.cnri.reston.va.us>; from Guido van Rossum on Mon, Apr 26, 1999 at 12:16:11PM -0400
References: <199904261616.MAA22036@eric.cnri.reston.va.us>
Message-ID: <19990426123042.A2617@cnri.reston.va.us>

On 26 April 1999, Guido van Rossum said:
> In a private mail, Greg Stein suggested that the python-dev archives
> should be restricted to the members of the list.  I prefer to make
> them public, but I won't want to impose this on others without
> discussion.  So I've made the archives private for the time being
> while we discuss this meta-issue.  (Also, the existence of the list
> isn't announced by mailman on its listinfo page.)
> 
> Here's my argument for open archives.  I don't think that we have
> anything to hide from the public -- I think of us as a technical forum
> whose discussions may affect others (e.g. Python users) and I think
> it's often useful for those others to be able to see what we've said.

I favour as much openness as possible that's consistent with high
signal-to-noise.  Opening the archives doesn't affect SN ratio; for that
matter, neither does allowing anyone to *read* the list while keeping
posting privileges restricted.  And letting the world know that the list
exists -- even though posting privileges are restricted -- shouldn't
affect quality.

So I guess my position is: definitely open the archives and publicise
the list -- the benefit of an open archive is reduced if people can't
stumble across it like they can any sig.  And consider the possibility
of open subscription while keeping posting restricted.  Not sure how
easy that is with Mailman, but we can still consider the idea.

The open, friendly nature of the Python community is a huge strength.  I
tentatively agree that posting privileges should be restricted to keep
quality high, but the idea of a "secret cabal" discussing Python
development off in a dark corner away from the grubby masses seems very
counter to the spirit I've seen so far.

        Greg
-- 
Greg Ward - software developer                    gward at cnri.reston.va.us
Corporation for National Research Initiatives    
1895 Preston White Drive                           voice: +1-703-620-8990
Reston, Virginia, USA  20191-5434                    fax: +1-703-620-0913



From da at ski.org  Mon Apr 26 18:29:56 1999
From: da at ski.org (David Ascher)
Date: Mon, 26 Apr 1999 09:29:56 -0700 (Pacific Daylight Time)
Subject: [Python-Dev] Public or private python-dev archives?
In-Reply-To: <199904261616.MAA22036@eric.cnri.reston.va.us>
Message-ID: <Pine.WNT.4.04.9904260922170.273-100000@rigoletto.ski.org>

On Mon, 26 Apr 1999, Guido van Rossum wrote:

> In a private mail, Greg Stein suggested that the python-dev archives
> should be restricted to the members of the list.  I prefer to make
> them public, but I won't want to impose this on others without
> discussion.  So I've made the archives private for the time being
> while we discuss this meta-issue.  (Also, the existence of the list
> isn't announced by mailman on its listinfo page.)

If one has a public archive with restricted membership, then one needs to
have a process for people to petition membership, including policies on
deciding admission (which could be as vague as "up to GvR's whim").

FWIW, the perl5-porters list is open but the perl6-porters list is closed.

My suggestion is that we can start with an open policy on archives, and
the lax posting policy for the multiple email address business (which
should be incorporated in mailman++ =), with the explicitely stated caveat
that if it turns out that that policy doesn't work, we reserve the right
to tighten things up. I also suggest that we don't advertise the fact that
anyone can post.  [Except of course that we've just mentioned this in
archives which I'm arguing should be public =)]

--david





From bwarsaw at cnri.reston.va.us  Mon Apr 26 19:44:36 1999
From: bwarsaw at cnri.reston.va.us (Barry A. Warsaw)
Date: Mon, 26 Apr 1999 13:44:36 -0400 (EDT)
Subject: [Python-Dev] Public or private python-dev archives?
References: <199904261616.MAA22036@eric.cnri.reston.va.us>
	<19990426123042.A2617@cnri.reston.va.us>
Message-ID: <14116.42500.284907.569281@anthem.cnri.reston.va.us>

>>>>> "GW" == Greg Ward <gward at cnri.reston.va.us> writes:

    GW> And consider the possibility of open subscription while
    GW> keeping posting restricted.  Not sure how easy that is with
    GW> Mailman, but we can still consider the idea.

It could be done in a number of ways.  You could restrict postings to
members only, but as Guido has pointed out, a lot of people post from
more than one account and Mailman doesn't handle that very well yet.
Or you could moderate the list, but then someone has to approve
postings and that's more work than I think anybody wants to do.

I'm also for an open-as-possible policy, with the right to restrict
later if the s/n gets too low.  I sort of view Python-dev to be the
place that serious c.l.py proposals get fleshed out and implementation 
strategies discussed.  The (hopefully) high level of technical detail
on the list should self-select.

-Barry



From gmcm at hypernet.com  Mon Apr 26 20:56:52 1999
From: gmcm at hypernet.com (Gordon McMillan)
Date: Mon, 26 Apr 1999 13:56:52 -0500
Subject: [Python-Dev] Public or private python-dev archives?
In-Reply-To: <14116.42500.284907.569281@anthem.cnri.reston.va.us>
Message-ID: <1286969269-56980208@hypernet.com>

[Barry]
> The (hopefully) high level of
> technical detail on the list should self-select.

I thought the humor did that.

If the public-archive were only updated weekly, it would make it's 
use (or abuse) as glorified help list pretty tenuous.

No one has espoused Greg's reasoning. In the abscense of 
said arguments, I'm certainly inclined to vote for "as public as can 
be and still be focused".

-OTOH-then-I'll-never-know-what-goes-on-in-the-smoke-filled-room-ly 
y'rs

- Gordon



From da at ski.org  Mon Apr 26 21:12:54 1999
From: da at ski.org (David Ascher)
Date: Mon, 26 Apr 1999 12:12:54 -0700 (Pacific Daylight Time)
Subject: [Python-Dev] Why unbundle Tools and Demo?
Message-ID: <Pine.WNT.4.04.9904261203430.59-100000@rigoletto.ski.org>

Several people argue for unbundling Tools/ and Demo/ in 1.6.  I'd like to
argue to leave them in.  They're not especially big, and IMHO they are
quite valuable, *especially* to the novice user.  In fact, I'd like to
argue that Demo/ should be promoted to the same status as Tools/ (by which
I mean included in the Windows binary distribution). Unbundling Tools/
would mean unbundling IDLE, which IMHO would be a big strategic mistake.

However, I wouldn't be against a cleanup of said directories.  Some things
should probably be removed (anything which uses stdwin), some of the code
in classes is showing its age (notes about "being upgraded for Python 1.1"
=), etc.  That said, the tkinter/ directory is the best place to look for
simple Tkinter code, and should be included, IMHO.

--david











From guido at CNRI.Reston.VA.US  Mon Apr 26 21:20:26 1999
From: guido at CNRI.Reston.VA.US (Guido van Rossum)
Date: Mon, 26 Apr 1999 15:20:26 -0400
Subject: [Python-Dev] Why unbundle Tools and Demo?
In-Reply-To: Your message of "Mon, 26 Apr 1999 12:12:54 PDT."
             <Pine.WNT.4.04.9904261203430.59-100000@rigoletto.ski.org> 
References: <Pine.WNT.4.04.9904261203430.59-100000@rigoletto.ski.org> 
Message-ID: <199904261920.PAA22415@eric.cnri.reston.va.us>

> Several people argue for unbundling Tools/ and Demo/ in 1.6.  I'd like to
> argue to leave them in.  They're not especially big, and IMHO they are
> quite valuable, *especially* to the novice user.  In fact, I'd like to
> argue that Demo/ should be promoted to the same status as Tools/ (by which
> I mean included in the Windows binary distribution). Unbundling Tools/
> would mean unbundling IDLE, which IMHO would be a big strategic mistake.
> 
> However, I wouldn't be against a cleanup of said directories.  Some things
> should probably be removed (anything which uses stdwin), some of the code
> in classes is showing its age (notes about "being upgraded for Python 1.1"
> =), etc.  That said, the tkinter/ directory is the best place to look for
> simple Tkinter code, and should be included, IMHO.

Agreed.  One simple thing that would help me immensely would be for
someone to go through all the various Demo directories and make an
inventary of what is there and how useful it is, (1) to all Python
users, (2) to Windows users.  Then, perhaps someone could write a
simple document making these files (and Tools) more accessible...

--Guido van Rossum (home page: http://www.python.org/~guido/)



From da at ski.org  Mon Apr 26 21:20:40 1999
From: da at ski.org (David Ascher)
Date: Mon, 26 Apr 1999 12:20:40 -0700 (Pacific Daylight Time)
Subject: [Python-Dev] Why unbundle Tools and Demo?
In-Reply-To: <199904261920.PAA22415@eric.cnri.reston.va.us>
Message-ID: <Pine.WNT.4.04.9904261220200.59-100000@rigoletto.ski.org>

> someone to go through all the various Demo directories and make an
> inventary of what is there and how useful it is, (1) to all Python
> users, (2) to Windows users.  Then, perhaps someone could write a
> simple document making these files (and Tools) more accessible...

Ok.  I can do that.






From guido at CNRI.Reston.VA.US  Mon Apr 26 21:22:55 1999
From: guido at CNRI.Reston.VA.US (Guido van Rossum)
Date: Mon, 26 Apr 1999 15:22:55 -0400
Subject: [Python-Dev] Why unbundle Tools and Demo?
In-Reply-To: Your message of "Mon, 26 Apr 1999 12:20:40 PDT."
             <Pine.WNT.4.04.9904261220200.59-100000@rigoletto.ski.org> 
References: <Pine.WNT.4.04.9904261220200.59-100000@rigoletto.ski.org> 
Message-ID: <199904261922.PAA22447@eric.cnri.reston.va.us>

[me]
> > someone to go through all the various Demo directories and make an
> > inventary of what is there and how useful it is, (1) to all Python
> > users, (2) to Windows users.  Then, perhaps someone could write a
> > simple document making these files (and Tools) more accessible...

[Dave]
> Ok.  I can do that.

Great!  I didn't mean to volunteer you -- but I think you'd do a great 
job.

--Guido van Rossum (home page: http://www.python.org/~guido/)



From tim_one at email.msn.com  Tue Apr 27 06:25:19 1999
From: tim_one at email.msn.com (Tim Peters)
Date: Tue, 27 Apr 1999 00:25:19 -0400
Subject: [Python-Dev] Public or private python-dev archives?
In-Reply-To: <19990426123042.A2617@cnri.reston.va.us>
Message-ID: <000501be9065$f5e3db80$ab9e2299@tim>

[Greg Ward, arguing in favor of
    ...
    a "secret cabal" discussing Python development off in a dark corner
    away from the grubby masses
]

That's what I'd like too -- but somebody already let Gordon in <wink>.

voting-to-leave-it-public-until-there's-a-problem-ly y'rs  - tim





From da at ski.org  Tue Apr 27 21:23:55 1999
From: da at ski.org (David Ascher)
Date: Tue, 27 Apr 1999 12:23:55 -0700 (Pacific Daylight Time)
Subject: [Python-Dev] numpy
Message-ID: <Pine.WNT.4.04.9904271220520.64-100000@rigoletto.ski.org>

What are the thoughts on NumPy integration into the core?

--David




From MHammond at skippinet.com.au  Wed Apr 28 01:28:59 1999
From: MHammond at skippinet.com.au (Mark Hammond)
Date: Wed, 28 Apr 1999 09:28:59 +1000
Subject: [Python-Dev] numpy
In-Reply-To: <Pine.WNT.4.04.9904271220520.64-100000@rigoletto.ski.org>
Message-ID: <001c01be9105$bae7ccd0$0801a8c0@bobcat>

> What are the thoughts on NumPy integration into the core?

he he - and while we are at it :-)  mxDateTime would need to be a popular
choice for inclusion, and Guido has offered in-principle support for moving
some of the Win32 stuff into the core - particularly the Registry stuff and
the native Window Handle support...

How far do we go :-)

Personally, I would simply like to see the distutils SIG solve this problem
for us.  (sure).  Eg, the "build" or "install" process (depending on the
OS) could build a local HTML file with knowledge many "common" extensions -
a single click, and it is downloaded, configured and built.   Oh well, back
to reality...

[Which isnt to say I am opposed to NumPy and mxDateTime.  Definately keen
on the win32 stuff tho :-]

Mark.




From da at ski.org  Wed Apr 28 01:31:56 1999
From: da at ski.org (David Ascher)
Date: Tue, 27 Apr 1999 16:31:56 -0700 (Pacific Daylight Time)
Subject: [Python-Dev] numpy
In-Reply-To: <001c01be9105$bae7ccd0$0801a8c0@bobcat>
Message-ID: <Pine.WNT.4.04.9904271628320.64-100000@rigoletto.ski.org>

On Wed, 28 Apr 1999, Mark Hammond wrote:

> > What are the thoughts on NumPy integration into the core?
> 
> he he - and while we are at it :-)  mxDateTime would need to be a popular
> choice for inclusion, and Guido has offered in-principle support for moving
> some of the Win32 stuff into the core - particularly the Registry stuff and
> the native Window Handle support...

It may seem strange, but I'll argue for the win32 registry calls before
the NumPy stuff.  That could be because I've looked at NumPy code and not
the win32 code.  Not Jim's cleanest code. =)

Mark, can you describe 'native Window Handle' support?

--david





From MHammond at skippinet.com.au  Wed Apr 28 07:03:48 1999
From: MHammond at skippinet.com.au (Mark Hammond)
Date: Wed, 28 Apr 1999 15:03:48 +1000
Subject: [Python-Dev] numpy
In-Reply-To: <Pine.WNT.4.04.9904271628320.64-100000@rigoletto.ski.org>
Message-ID: <001e01be9134$809ca8f0$0801a8c0@bobcat>

> It may seem strange, but I'll argue for the win32 registry
> calls before
> the NumPy stuff.  That could be because I've looked at NumPy
> code and not
> the win32 code.  Not Jim's cleanest code. =)

he he - and I can even get out of the Win32 stuff - I wrote a string-only
first version, and Bill Tutt rehashed it into what it is today, handling
all the registry types.

OTOH, there could also be a case for moving "win32api" completely to "core
status" (whether that means truly core or simply a standard .pyd).  For
example, ntpath.py now has code that attempts to use
"win32api.GetFullPathName()".

The down-side is that win32api has nowhere near complete coverage, and is
really a mixed bag of bits and pieces.  Most later efforts where complete
API sets are given coverage have different names - eg, win32file has the
complete Win32 file API wrapped up - even if there are overlaps with
existing functions in win32api.

Im not sure what the answer is - my guess is a new core module with Win32
features deemed absolutely necessary for the core - stuff like the
registry, and a few assorted other functions, such as GetFullPathName, but
stopping well short of the full win32api set.

> Mark, can you describe 'native Window Handle' support?

Sure!  We have a very light-weight "handle" object, representing a Win32
handle.  It has no methods, and a single property for returning the
underlying win32 handle as an integer.  When the object destructs, it calls
"CloseHandle()".  Thats about it!

It has no methods, so is passed as an argument.  There has been no attempt
to implement things like "handle.Read()" to represent "ReadFile(handle,
...)".  There are 2 reasons for this:
1) Handles are fairly general purpose, and not restricted to IO operations.
A handle is also used to represent a Mutex/Semaphores and
threads/processes - certainly doesnt make sense to have a "Read()" method
for those handles.
2) IMO, this should be done at the .py level anyway.  The Win32 Handle
support is pure C++ at the moment.

A simple complication is that there are 3 types of handles in use at the
moment - those that call "CloseHandle", those that call "RegCloseHandle"
(registry handles) and a 3rd I cant recall.  This is currently implemented
using C++ inheritance.  But even if the current implementation is not
favoured, the object is so small that a rewrite would not be a problem.

And for those that can be bothered to read this far, some more background:
Some time ago, Greg and I decided to implement a "pywintypes" module.  This
defines what we considered "core types" for the Win32 world.  All our
extension modules (including win32api, COM; basically win32*.pyd) use this
module.  The objects it supports are: Unicode, Handles, Win32 Time, IIDs,
Overlapped IO objects, 3 NT security related objects and importantly a
standard Win32 exception and functions for filling it.

Moving the registry stuff is dependant on the core having the Exception,
Handle and Registry support (hence this discussion).  We have our own Time
object, but mxDateTime would be fine.  One day, we hope to remove this
pywintypes entirely, as the core will have it all :-)

Mark.




From gward at cnri.reston.va.us  Wed Apr 28 14:51:43 1999
From: gward at cnri.reston.va.us (Greg Ward)
Date: Wed, 28 Apr 1999 08:51:43 -0400
Subject: [Python-Dev] numpy
In-Reply-To: <001c01be9105$bae7ccd0$0801a8c0@bobcat>; from Mark Hammond on Wed, Apr 28, 1999 at 09:28:59AM +1000
References: <Pine.WNT.4.04.9904271220520.64-100000@rigoletto.ski.org> <001c01be9105$bae7ccd0$0801a8c0@bobcat>
Message-ID: <19990428085143.A5571@cnri.reston.va.us>

On 28 April 1999, Mark Hammond said:
> How far do we go :-)
> 
> Personally, I would simply like to see the distutils SIG solve this problem
> for us.  (sure).  Eg, the "build" or "install" process (depending on the
> OS) could build a local HTML file with knowledge many "common" extensions -
> a single click, and it is downloaded, configured and built.   Oh well, back
> to reality...

It's not impossible, it just takes a while.  I think it took the Perl
community about three years to go from "hey! let's have a standard build
mechanism for modules!" to the point where I can install (almost) any
module from CPAN with one shell command:

  perl -MCPAN -e 'install ("MIME::Base64");'

which is insanely cool.  (It took about two minutes to do the above just
now; that included trying two CPAN mirrors that aren't being cooperative
this morning, finding one that was working, downloading the current
module list from it, determining that there is a more recent version
available than the one installed here, downloading it, unpacking it,
running "Makefile.PL" to generate the Makefile, running "make" [which
compiles any extensions in the distribution, copies all the .pm files
around, and generates the documentation], "make test" [run the module's
self-test suite], and "make install" [install it in the "site-perl"
library directory].  Amount of user interaction required: typing the
above command line.)

It's *still* rough around the edges, though, especially when building a
new installation from scratch -- mainly because Perl doesn't ship with
ftp or http libraries, so the CPAN.pm module has to try downloading
stuff with lynx, ncftp, or plain ol' ftp until it has downloaded and
installed the libnet and libwww-perl distributions.  That's one problem
we won't have with Python, at least.  Oh yeah, and it all works *great*
under Unix... but the rest of the world lags behind.

Also, two major components of being able to do this -- the Perl Module
List and CPAN -- are still vapourware in Python-land.  But hey, if we
can get to the "we *have* a standard build mechanism for modules!"
point, then all the rest becomes a lot more feasible.

Pep talk over...

        Greg
-- 
Greg Ward - software developer                    gward at cnri.reston.va.us
Corporation for National Research Initiatives    
1895 Preston White Drive                           voice: +1-703-620-8990
Reston, Virginia, USA  20191-5434                    fax: +1-703-620-0913



From mal at lemburg.com  Wed Apr 28 09:44:25 1999
From: mal at lemburg.com (M.-A. Lemburg)
Date: Wed, 28 Apr 1999 09:44:25 +0200
Subject: [Python-Dev] numpy
References: <001c01be9105$bae7ccd0$0801a8c0@bobcat>
Message-ID: <3726BC59.35E3C9DB@lemburg.com>

Mark Hammond wrote:
> 
> > What are the thoughts on NumPy integration into the core?
> 
> he he - and while we are at it :-)  mxDateTime would need to be a popular
> choice for inclusion, and Guido has offered in-principle support for moving
> some of the Win32 stuff into the core - particularly the Registry stuff and
> the native Window Handle support...
> 
> How far do we go :-)
> 
> Personally, I would simply like to see the distutils SIG solve this problem
> for us.  (sure).  Eg, the "build" or "install" process (depending on the
> OS) could build a local HTML file with knowledge many "common" extensions -
> a single click, and it is downloaded, configured and built.   Oh well, back
> to reality...

You're talking about fast moving targets there... are you sure that
you want those in the standard distribution ?

Maybe we have two distributions: the standard one and a pro
edition with all the slick stuff included (together with a
proper setup script to get those references to external libs
and include files right).

Actually, this is something I've been wanting to do for nearly
a year now... just haven't found the time to really get things
the way I want them. It's a project called Python Power Tools
and includes many generic extensions (currently only ones that
don't rely on external libs).

If you're interested, have a look at an old version available at:

    http://starship.skyport.net/~lemburg/PowerTools-0.2.zip

It includes the extensions BTree, mxDateTime, mxTools, mxStack,
Trie, avl and kjbuckets. NumPy should probably also be included.
The current setup uses a recursive Makefile approach (not too
elegant, but works). A distutils setup would be much better.

-- 
Marc-Andre Lemburg                               Y2000: 247 days left
---------------------------------------------------------------------
          : Python Pages >>> http://starship.skyport.net/~lemburg/  :
           ---------------------------------------------------------





From jack at oratrix.nl  Wed Apr 28 15:48:21 1999
From: jack at oratrix.nl (Jack Jansen)
Date: Wed, 28 Apr 1999 15:48:21 +0200
Subject: [Python-Dev] numpy 
In-Reply-To: Message by "Mark Hammond" <MHammond@skippinet.com.au> ,
	     Wed, 28 Apr 1999 09:28:59 +1000 , <001c01be9105$bae7ccd0$0801a8c0@bobcat>
Message-ID: <19990428134821.E9A68300F57@snelboot.oratrix.nl>

> [...] Guido has offered in-principle support for moving
> some of the Win32 stuff into the core - particularly the Registry stuff and
> the native Window Handle support...

I think it would be nice to put all the stuff that is shared between modules 
(I think that's only PyWinTypes, but who am I to think I have a clue about the 
windows port:-) into the core.

I just did the same for MacPython, and it makes life a whole lot easier.
--
Jack Jansen             | ++++ stop the execution of Mumia Abu-Jamal ++++
Jack.Jansen at oratrix.com | ++++ if you agree copy these lines to your sig ++++
www.oratrix.nl/~jack    | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm 





From skip at mojam.com  Wed Apr 28 17:57:40 1999
From: skip at mojam.com (skip at mojam.com)
Date: Wed, 28 Apr 1999 11:57:40 -0400
Subject: [Python-Dev] LLNL C++ as base for Python 2?
Message-ID: <199904281557.LAA06491@cm-29-94-14.nycap.rr.com>

Have we been talking about Python 2 or Python 1.6?  If we're talking about
Python 2, has anyone given a serious look at the LLNL gang's C++/Python
stuff?  If I recall Paul Dubois' talk at the last conference, it sounded
like their work made it much easier to implement extension modules.

Skip Montanaro	| Mojam: "Uniting the World of Music" http://www.mojam.com/
skip at mojam.com  | Musi-Cal: http://www.musi-cal.com/
518-372-5583




From guido at CNRI.Reston.VA.US  Wed Apr 28 18:06:03 1999
From: guido at CNRI.Reston.VA.US (Guido van Rossum)
Date: Wed, 28 Apr 1999 12:06:03 -0400
Subject: [Python-Dev] LLNL C++ as base for Python 2?
In-Reply-To: Your message of "Wed, 28 Apr 1999 11:57:40 EDT."
             <199904281557.LAA06491@cm-29-94-14.nycap.rr.com> 
References: <199904281557.LAA06491@cm-29-94-14.nycap.rr.com> 
Message-ID: <199904281606.MAA27526@eric.cnri.reston.va.us>

> Have we been talking about Python 2 or Python 1.6?  If we're talking about
> Python 2, has anyone given a serious look at the LLNL gang's C++/Python
> stuff?  If I recall Paul Dubois' talk at the last conference, it sounded
> like their work made it much easier to implement extension modules.

I've mostly had 1.6 in mind.  See recent traffic in the C++ SIG
archives for the status of Paul's CXX.

--Guido van Rossum (home page: http://www.python.org/~guido/)



From da at ski.org  Wed Apr 28 19:24:00 1999
From: da at ski.org (David Ascher)
Date: Wed, 28 Apr 1999 10:24:00 -0700 (Pacific Daylight Time)
Subject: [Python-Dev] LLNL C++ as base for Python 2?
In-Reply-To: <199904281606.MAA27526@eric.cnri.reston.va.us>
Message-ID: <Pine.WNT.4.04.9904281021061.346-100000@rigoletto.ski.org>

On Wed, 28 Apr 1999, Guido van Rossum wrote:

> > Have we been talking about Python 2 or Python 1.6?  If we're talking about
> > Python 2, has anyone given a serious look at the LLNL gang's C++/Python
> > stuff?  If I recall Paul Dubois' talk at the last conference, it sounded
> > like their work made it much easier to implement extension modules.
> 
> I've mostly had 1.6 in mind.  See recent traffic in the C++ SIG
> archives for the status of Paul's CXX.

Recent traffic?  There's nothing in there that's substantive since... uh,
well, I got tired of looking back. =)

CXX is very cool, but it is still pushing the envelope of many C++
compilers.  From what I gather, recent egcs' do manage with it, and since
egcs is going to replace gcc, I expect that many platforms will be able to
"do" CXX relatively soon.

I vote to stay on the 1.6 track for now.




From MHammond at skippinet.com.au  Fri Apr 30 04:40:09 1999
From: MHammond at skippinet.com.au (Mark Hammond)
Date: Fri, 30 Apr 1999 12:40:09 +1000
Subject: [Python-Dev] More flexible namespaces.
Message-ID: <008d01be92b2$c56ef5d0$0801a8c0@bobcat>

Here is a bit of an idea that I first came up with some years ago.  Guido's
response at the time was "sounds reasonable as long as we dont slow the
normal case down".

To cut a long story short, I would like eval and exec to be capable of
working with arbitrary mapping objects rather than only dictionaries.  The
general idea is that I can provide a class with mapping semantics, and pass
this to exec/eval.

This would give us 2 seriously cool features (that I want <wink>), should
anyone decide to write code that enables them:

* Case insensitive namespaces.  This would be very cool for COM, and as far
as I know would please the Alice people.  May open up more embedding
opportunities that are lost if people feel strongly about this issue.

* Dynamic name lookups.  At the moment, dynamic attribute lookups are
simple, but dynamic name lookups are hard.  If I execute code "print foo",
foo _must_ pre-exist in the namespace.  There is no reasonable way I can
some up with so that I can fetch "foo" as it is requested (raising the
NameError if necessary).  This would also be very cool for some of the COM
work - particularly Active Scripting.

Of course, these would not be enabled by standard Python, but would allow
people to create flexible execution environments that suit their purpose.

Any comments on this?  Is it a dumb idea?  Anyone have a feel for how deep
these changes would cut?  Its not something I want to happen soon, but it
does seem a reasonable mechanism that can provide very flexible
solutions...

Mark.




From guido at CNRI.Reston.VA.US  Fri Apr 30 05:00:52 1999
From: guido at CNRI.Reston.VA.US (Guido van Rossum)
Date: Thu, 29 Apr 1999 23:00:52 -0400
Subject: [Python-Dev] More flexible namespaces.
In-Reply-To: Your message of "Fri, 30 Apr 1999 12:40:09 +1000."
             <008d01be92b2$c56ef5d0$0801a8c0@bobcat> 
References: <008d01be92b2$c56ef5d0$0801a8c0@bobcat> 
Message-ID: <199904300300.XAA00608@eric.cnri.reston.va.us>

> To cut a long story short, I would like eval and exec to be capable of
> working with arbitrary mapping objects rather than only dictionaries.  The
> general idea is that I can provide a class with mapping semantics, and pass
> this to exec/eval.

I agree that this would be seriously cool.  It will definitely be in
Python 2.0; it's already in JPython.

Quite a while ago, Ian Castleden sent me patches for 1.5.1 to do this.
It was a lot of code and I was indeed worried about slowing things
down too much (and also about checking that he got all the endcases
right).

Ian did benchmarks and found that the new code was consistently
slower, by 3-6%.  Perhaps for Python 1.6 this will be acceptable (the
"Python IS slow" thread notwithstanding :-); or perhaps someone can
have a look at it and squeeze some more time out of it?  I'll gladly
forward the patches.

--Guido van Rossum (home page: http://www.python.org/~guido/)



From da at ski.org  Fri Apr 30 05:21:04 1999
From: da at ski.org (David Ascher)
Date: Thu, 29 Apr 1999 20:21:04 -0700 (Pacific Daylight Time)
Subject: [Python-Dev] More flexible namespaces.
In-Reply-To: <199904300300.XAA00608@eric.cnri.reston.va.us>
Message-ID: <Pine.WNT.4.05.9904292018290.153-100000@david.ski.org>

> > To cut a long story short, I would like eval and exec to be capable of
> > working with arbitrary mapping objects rather than only dictionaries.  The
> > general idea is that I can provide a class with mapping semantics, and pass
> > this to exec/eval.
> 
> I agree that this would be seriously cool.  It will definitely be in
> Python 2.0; it's already in JPython.

Seriously cool is an understatement. 

--david




From MHammond at skippinet.com.au  Fri Apr 30 06:13:25 1999
From: MHammond at skippinet.com.au (Mark Hammond)
Date: Fri, 30 Apr 1999 14:13:25 +1000
Subject: [Python-Dev] More flexible namespaces.
In-Reply-To: <199904300300.XAA00608@eric.cnri.reston.va.us>
Message-ID: <009001be92bf$cb998f80$0801a8c0@bobcat>

> Ian did benchmarks and found that the new code was consistently
> slower, by 3-6%.  Perhaps for Python 1.6 this will be acceptable (the
> "Python IS slow" thread notwithstanding :-); or perhaps someone can

As long as we get someone working on a consistent 3-6% speedup in other
areas this wont be a problem :-)

I will attach it to my long list - but Im going to put all my efforts here
into Unicode first, and probably the threading stuff second :-)

Mark.




From tismer at appliedbiometrics.com  Fri Apr 30 09:49:42 1999
From: tismer at appliedbiometrics.com (Christian Tismer)
Date: Fri, 30 Apr 1999 09:49:42 +0200
Subject: [Python-Dev] More flexible namespaces.
References: <008d01be92b2$c56ef5d0$0801a8c0@bobcat> <199904300300.XAA00608@eric.cnri.reston.va.us>
Message-ID: <37296096.D0C9C2CC@appliedbiometrics.com>


Guido van Rossum wrote:
...
> Ian did benchmarks and found that the new code was consistently
> slower, by 3-6%.  Perhaps for Python 1.6 this will be acceptable (the
> "Python IS slow" thread notwithstanding :-); or perhaps someone can
> have a look at it and squeeze some more time out of it?  I'll gladly
> forward the patches.

I'd really like to look into that.
Also I wouldn't worry too much about speed, since this is 
such a cool feature. It might even be a speedup in some cases
which otherwise would need more complex handling.

May I have a look?

ciao - chris

-- 
Christian Tismer             :^)   <mailto:tismer at appliedbiometrics.com>
Applied Biometrics GmbH      :     Have a break! Take a ride on Python's
Kaiserin-Augusta-Allee 101   :    *Starship* http://starship.python.net
10553 Berlin                 :     PGP key -> http://wwwkeys.pgp.net
PGP Fingerprint       E182 71C7 1A9D 66E9 9D15  D3CC D4D7 93E2 1FAE F6DF
     we're tired of banana software - shipped green, ripens at home



From mal at lemburg.com  Fri Apr 30 10:22:46 1999
From: mal at lemburg.com (M.-A. Lemburg)
Date: Fri, 30 Apr 1999 10:22:46 +0200
Subject: [Python-Dev] More flexible namespaces.
References: <008d01be92b2$c56ef5d0$0801a8c0@bobcat>
Message-ID: <37296856.5875AAAF@lemburg.com>

Mark Hammond wrote:
> 
> Here is a bit of an idea that I first came up with some years ago.  Guido's
> response at the time was "sounds reasonable as long as we dont slow the
> normal case down".
> 
> To cut a long story short, I would like eval and exec to be capable of
> working with arbitrary mapping objects rather than only dictionaries.  The
> general idea is that I can provide a class with mapping semantics, and pass
> this to exec/eval.

This involves a whole lot of changes: not only in the Python core,
but also in extensions that rely on having real dictionaries available.

Since you put out to objectives, I'd like to propose a little
different approach...

1. Have eval/exec accept any mapping object as input

2. Make those two copy the content of the mapping object into real
   dictionaries

3. Provide a hook into the dictionary implementation that can be
   used to redirect KeyErrors and use that redirection to forward
   the request to the original mapping objects

> This would give us 2 seriously cool features (that I want <wink>), should
> anyone decide to write code that enables them:
> 
> * Case insensitive namespaces.  This would be very cool for COM, and as far
> as I know would please the Alice people.  May open up more embedding
> opportunities that are lost if people feel strongly about this issue.

This is covered by 1 and 2.

> * Dynamic name lookups.  At the moment, dynamic attribute lookups are
> simple, but dynamic name lookups are hard.  If I execute code "print foo",
> foo _must_ pre-exist in the namespace.  There is no reasonable way I can
> some up with so that I can fetch "foo" as it is requested (raising the
> NameError if necessary).  This would also be very cool for some of the COM
> work - particularly Active Scripting.

This is something for 3.

I guess it wouldn't cause any significant slow-down and can be
imlemented with much less code than the "change all PyDict_GetItem
to PyObject_GetItem" thingie.

The real thing could then be done for 2.0 where PyDict_Check()
would presumably not rely on an adress but some kind of inheritance
scheme indicating that the object is in fact a dictionary.

Cheers,
-- 
Marc-Andre Lemburg                               Y2000: 245 days left
---------------------------------------------------------------------
          : Python Pages >>> http://starship.skyport.net/~lemburg/  :
           ---------------------------------------------------------




From guido at CNRI.Reston.VA.US  Fri Apr 30 17:17:20 1999
From: guido at CNRI.Reston.VA.US (Guido van Rossum)
Date: Fri, 30 Apr 1999 11:17:20 -0400
Subject: [Python-Dev] More flexible namespaces.
In-Reply-To: Your message of "Fri, 30 Apr 1999 09:49:42 +0200."
             <37296096.D0C9C2CC@appliedbiometrics.com> 
References: <008d01be92b2$c56ef5d0$0801a8c0@bobcat> <199904300300.XAA00608@eric.cnri.reston.va.us>  
            <37296096.D0C9C2CC@appliedbiometrics.com> 
Message-ID: <199904301517.LAA01422@eric.cnri.reston.va.us>

> From: Christian Tismer <tismer at appliedbiometrics.com>

> I'd really like to look into that.
> Also I wouldn't worry too much about speed, since this is 
> such a cool feature. It might even be a speedup in some cases
> which otherwise would need more complex handling.
> 
> May I have a look?

Sure!

(I've forwarded Christian the files per separate mail.)

I'm also interested in your opinion on how well thought-out and robust
the patches are -- I've never found the time to do a good close
reading of them.

--Guido van Rossum (home page: http://www.python.org/~guido/)



From gmcm at hypernet.com  Fri Apr 30 18:32:30 1999
From: gmcm at hypernet.com (Gordon McMillan)
Date: Fri, 30 Apr 1999 11:32:30 -0500
Subject: [Python-Dev] More flexible namespaces.
In-Reply-To: <199904301517.LAA01422@eric.cnri.reston.va.us>
References: Your message of "Fri, 30 Apr 1999 09:49:42 +0200."             <37296096.D0C9C2CC@appliedbiometrics.com> 
Message-ID: <1286632328-77246936@hypernet.com>

Guido wrote:

> > From: Christian Tismer <tismer at appliedbiometrics.com>
> 
> > I'd really like to look into that.
> > Also I wouldn't worry too much about speed, since this is 
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > such a cool feature. It might even be a speedup in some cases
> > which otherwise would need more complex handling.
> > 
> > May I have a look?
> 
> Sure!
> 
> (I've forwarded Christian the files per separate mail.)

I don't know who you sent that to, but it couldn't possibly have been 
Christian!

- Gordon



From tismer at appliedbiometrics.com  Fri Apr 30 17:57:09 1999
From: tismer at appliedbiometrics.com (Christian Tismer)
Date: Fri, 30 Apr 1999 17:57:09 +0200
Subject: [Python-Dev] More flexible namespaces.
References: <008d01be92b2$c56ef5d0$0801a8c0@bobcat> <199904300300.XAA00608@eric.cnri.reston.va.us>  
	            <37296096.D0C9C2CC@appliedbiometrics.com> <199904301517.LAA01422@eric.cnri.reston.va.us>
Message-ID: <3729D2D5.6844D6DA@appliedbiometrics.com>


Guido van Rossum wrote:
> 
> > From: Christian Tismer <tismer at appliedbiometrics.com>
> > May I have a look?
> 
> Sure!
> 
> (I've forwarded Christian the files per separate mail.)

Thanks a lot! 

> I'm also interested in your opinion on how well thought-out and robust
> the patches are -- I've never found the time to do a good close
> reading of them.

Yes, it is quite long and not so very easy to digest.
At first glance, most of the changes are replacements of
dict access with mapping access where we pay for the extra
indirection.
It depends on how often this feature will really replace
dicts. If dicts are more common, I'd like to figure out
how much code bloat extra special casing for dicts would give.

Puha - thanks - chris

-- 
Christian Tismer             :^)   <mailto:tismer at appliedbiometrics.com>
Applied Biometrics GmbH      :     Have a break! Take a ride on Python's
Kaiserin-Augusta-Allee 101   :    *Starship* http://starship.python.net
10553 Berlin                 :     PGP key -> http://wwwkeys.pgp.net
PGP Fingerprint       E182 71C7 1A9D 66E9 9D15  D3CC D4D7 93E2 1FAE F6DF
     we're tired of banana software - shipped green, ripens at home



From tismer at appliedbiometrics.com  Fri Apr 30 18:19:57 1999
From: tismer at appliedbiometrics.com (Christian Tismer)
Date: Fri, 30 Apr 1999 18:19:57 +0200
Subject: [Python-Dev] More flexible namespaces.
References: Your message of "Fri, 30 Apr 1999 09:49:42 +0200."             <37296096.D0C9C2CC@appliedbiometrics.com> <1286632328-77246936@hypernet.com>
Message-ID: <3729D82D.CE16884@appliedbiometrics.com>


Gordon McMillan wrote:
> 
> Guido wrote:
> 
> > > From: Christian Tismer <tismer at appliedbiometrics.com>
> >
> > > I'd really like to look into that.
> > > Also I wouldn't worry too much about speed, since this is
>     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > > such a cool feature. It might even be a speedup in some cases
> > > which otherwise would need more complex handling.
> > >
> > > May I have a look?
> >
> > Sure!
> >
> > (I've forwarded Christian the files per separate mail.)
> 
> I don't know who you sent that to, but it couldn't possibly have been
> Christian!

:-) :-) truely not if I had'n other things in mind.

I know that I will not get more than 30-40 percent by compiling
the interpreter away, so I will not even spend time at a
register machine right now. Will also not follow the ideas of
P2C any longer, doesn't pay off.
Instead, If I can manage to create something like static binding
snapshots, then I could resolve many of the lookups and internal
method indirections, for time critical applications.
For all the rest, Python is pretty much fast enough.

I've begun to write s special platform dependant version
which allows me to do all the things which can't go into the dist.
For instance, I just saved some 10 percent by dynamically
patching some of the ParseTuple and BuildObject calls out of the
core code (ahem). I hope Python will stay as clean as it is,
allowing me to try all kinds of tricks for one machine class.

ciao - chris.speedy

-- 
Christian Tismer             :^)   <mailto:tismer at appliedbiometrics.com>
Applied Biometrics GmbH      :     Have a break! Take a ride on Python's
Kaiserin-Augusta-Allee 101   :    *Starship* http://starship.python.net
10553 Berlin                 :     PGP key -> http://wwwkeys.pgp.net
PGP Fingerprint       E182 71C7 1A9D 66E9 9D15  D3CC D4D7 93E2 1FAE F6DF
     we're tired of banana software - shipped green, ripens at home



From akuchlin at cnri.reston.va.us  Fri Apr 30 18:33:34 1999
From: akuchlin at cnri.reston.va.us (Andrew M. Kuchling)
Date: Fri, 30 Apr 1999 12:33:34 -0400 (EDT)
Subject: [Python-Dev] More flexible namespaces.
In-Reply-To: <3729D82D.CE16884@appliedbiometrics.com>
References: <37296096.D0C9C2CC@appliedbiometrics.com>
	<1286632328-77246936@hypernet.com>
	<3729D82D.CE16884@appliedbiometrics.com>
Message-ID: <14121.55659.754846.708467@amarok.cnri.reston.va.us>

Christian Tismer writes:
>Instead, If I can manage to create something like static binding
>snapshots, then I could resolve many of the lookups and internal
>method indirections, for time critical applications.

	The usual assumption is that the lookups are what takes time.
Now, are we sure of that assumption?  I'd expect the lookup code to be
like:

1) Get hash of name
2) Retrieve object from dictionary
3) Do something with the object.

Now, since string objects cache their hash value, 1) should usually be
just "if (obj->cached_hash_value!=-1) return obj->cached_hash_value";
a comparision and a return.  Step 2) should be very fast, barring a
bad hash function.  So perhaps most of the time is spent in 3),
creating new local dicts, stack frames, and what not.  (Yes, I know
that doing this on every reference to an object is part of the
problem.)  I also wonder about the costs of all the Py_BuildValue and
Py_ParseTuple calls going on under the hood.  A performance
improvement project would definitely be a good idea for 1.6, and a
good sub-topic for python-dev.

	Incidentally, what's the verdict on python-dev archives:
public or not?

-- 
A.M. Kuchling			http://starship.python.net/crew/amk/
Despair says little, and is patient.
    -- From SANDMAN: "Season of Mists", episode 0




From tismer at appliedbiometrics.com  Fri Apr 30 18:55:55 1999
From: tismer at appliedbiometrics.com (Christian Tismer)
Date: Fri, 30 Apr 1999 18:55:55 +0200
Subject: [Python-Dev] More flexible namespaces.
References: <37296096.D0C9C2CC@appliedbiometrics.com>
		<1286632328-77246936@hypernet.com>
		<3729D82D.CE16884@appliedbiometrics.com> <14121.55659.754846.708467@amarok.cnri.reston.va.us>
Message-ID: <3729E09B.5F65E3CA@appliedbiometrics.com>


"Andrew M. Kuchling" wrote:
> 
> Christian Tismer writes:
> >Instead, If I can manage to create something like static binding
> >snapshots, then I could resolve many of the lookups and internal
> >method indirections, for time critical applications.
> 
>         The usual assumption is that the lookups are what takes time.
> Now, are we sure of that assumption?  I'd expect the lookup code to be
> like:
> 
> 1) Get hash of name
> 2) Retrieve object from dictionary
> 3) Do something with the object.
...
Right, but when you become more restrictive, you can do
lots, lots more. If I also allow to fix the type of an object,
I can go under the hood of the Python API, so you could
add some points 4) 5) 6) here.
But I shouldn't have talked before I can show something.
And at the time, I don't restrict myself to write clean
code, but try very machine specific things which I
don't believe should go into Python at all.

> I also wonder about the costs of all the Py_BuildValue and
> Py_ParseTuple calls going on under the hood.  A performance
> improvement project would definitely be a good idea for 1.6, and a
> good sub-topic for python-dev.

I wasn't sure, so I first wrote a module which does statistics
on that, and I found a lot of these calls. Some are even 
involved in ceval's code, where things like "(OOOO)" is parsed
all over again and again. Now I think this is ok in most cases.
But in some places these are very bad: If your builtin function
soes so very few work. 
Take len(): This uses ParseTuple, which calls a function to
find out its object, then calls a function to get the object,
then takes the len, and builds the result. But since everything
has a length, checking for no NULL pointer and grabbing the len
produces even shorter code. This applies to many places as well.
But right now, I don't change the core, but build hacky little
extension modules which squeak such things out at runtime.
No big deal yet, but maybe it could pay off to introduce
format strings which make them more suitableto be used
in macro substitutions.

sorry if I was too elaborate, this is so much fun :-)

ciao - chris

-- 
Christian Tismer             :^)   <mailto:tismer at appliedbiometrics.com>
Applied Biometrics GmbH      :     Have a break! Take a ride on Python's
Kaiserin-Augusta-Allee 101   :    *Starship* http://starship.python.net
10553 Berlin                 :     PGP key -> http://wwwkeys.pgp.net
PGP Fingerprint       E182 71C7 1A9D 66E9 9D15  D3CC D4D7 93E2 1FAE F6DF
     we're tired of banana software - shipped green, ripens at home



From skip at mojam.com  Wed Apr 21 15:17:32 1999
From: skip at mojam.com (skip at mojam.com)
Date: Wed, 21 Apr 1999 09:17:32 -0400
Subject: [Python-Dev] ZServer 1.0b1: spurious colon in HTTP response line
Message-ID: <199904211317.JAA26167@cm-29-94-14.nycap.rr.com>

(Also reported to the bug catcher.)

I'm trying to migrate from ZopeHTTPServer to ZServer 1.0b1.  I was seeing
the ZServer headers turning up in pages generated by the process.  When I
viewed the page source of the generated HTML I saw:

    HTTP/1.0: 200 OK
    Server: Zope/experimental ZServer/1.1b1
    Date: Wed, 21 Apr 1999 13:00:38 GMT
    X-Powered-By: Zope (www.zope.org), Python (www.python.org)
    Connection: close
    Content-Type: text/html
    Content-Length: 7802
    

    <!-- -*-html-helper -*- -->
    <HTML>
    <HEAD>
    <TITLE>Musi-Cal... Concert Schedules: Folk Music, Country Music, Rock Music &amp; more!</TITLE>
    ...

I run ZServer behind an Apache 1.3.3 running mod_proxy.  Apparently Apache
doesn't recognize the HTTP response when there is a colon following the
version number and adds a simple set of headers itself.  I guess web
browsers either ignore that line or are more lenient in their parsing of the
response.

The following simple patch corrects the problem:

diff -c2 HTTPResponse.py.~1~ HTTPResponse.py
*** HTTPResponse.py.~1~	Tue Apr 13 15:21:12 1999
--- HTTPResponse.py	Wed Apr 21 09:05:00 1999
***************
*** 146,150 ****
       
          # status header must come first.
!         append("HTTP/%s: %s" % (self._http_version, status))
          if headers.has_key('status'):
              del headers['status']
--- 146,150 ----
       
          # status header must come first.
!         append("HTTP/%s %s" % (self._http_version, status))
          if headers.has_key('status'):
              del headers['status']
***************


Skip Montanaro	| Mojam: "Uniting the World of Music" http://www.mojam.com/
skip at mojam.com  | Musi-Cal: http://www.musi-cal.com/
518-372-5583



From da at ski.org  Wed Apr 21 20:47:56 1999
From: da at ski.org (David Ascher)
Date: Wed, 21 Apr 1999 11:47:56 -0700 (Pacific Daylight Time)
Subject: [Python-Dev] Notice of intent: rich comparisons
Message-ID: <Pine.WNT.4.04.9904211142330.174-100000@rigoletto.ski.org>

Now that 1.5.2 is finalized, I'll be starting to prepare a patch for the
rich comparisons.  

Guido, how do you envision python-dev working?  Do you want to hand out a
TODO list for 1.6?

--david





From guido at CNRI.Reston.VA.US  Wed Apr 21 21:04:40 1999
From: guido at CNRI.Reston.VA.US (Guido van Rossum)
Date: Wed, 21 Apr 1999 15:04:40 -0400
Subject: [Python-Dev] Notice of intent: rich comparisons
In-Reply-To: Your message of "Wed, 21 Apr 1999 11:47:56 PDT."
             <Pine.WNT.4.04.9904211142330.174-100000@rigoletto.ski.org> 
References: <Pine.WNT.4.04.9904211142330.174-100000@rigoletto.ski.org> 
Message-ID: <199904211904.PAA14966@eric.cnri.reston.va.us>

> Now that 1.5.2 is finalized, I'll be starting to prepare a patch for the
> rich comparisons.  

Cool!

> Guido, how do you envision python-dev working?

I though we'd just crack Monty Python jokes while pretending to work :-)

> Do you want to hand out a TODO list for 1.6?

Well, I'm not saying that this is the definitive list, but certainly
there are a bunch of things that definitely need to be incorporated.
Here's an excerpt of a list that I keep for myself, in no particular
order, with brief annotations (I have a meeting in 15 minutes :):

Redesign thread/init APIs

	See the recent discussion in the thread-sig.  There should be
	some kind of micro-init that initializes essential components
	(including the thread lock!) but doesn't create an interpreter
	or a threadstate object.  There should also be a notion of a
	default interpreter.

Break up into VM, parser, import, mainloop, and other components?

	The porting efforts to seriously small machines (Win/CE,
	Pilot, etc.) all seem to need a Python VM that doesn't
	automatically pull in the parser and interactive main loop.
	There are other reasons as well to isolate various parts
	of the functionality (including all numeric data types except
	ints).

	This could include: restructuring of the parser so codeop.py
	can be simplified; making the interactive main loop a script.

String methods

	Barry has his patches ready.

Unicode

	What is the status of /F's latest attempts?

Rich comparisons

	This is Dave's plan.

Coercions

	Marc-Andre Lemburg has some good suggestions here:
	http://starship.python.net/~lemburg/coercion-0.6.zip

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.

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

Buffer object API extensions

	Marc-Andre Lemburg has a patch

Distutil

	Should we start integrating some of the results of the
	distutil SIG?  (What's the status?  I haven't been paying
	attention.)

Misc

	Jeremy Hylton's urllib2.py

	Greg Stein's new httplib.py (or Jeremy's?)

	Andrew Kuchling's new PCRE release?

	The IPv6 patches?

Gotta run!

--Guido van Rossum (home page: http://www.python.org/~guido/)



From gward at cnri.reston.va.us  Wed Apr 21 21:10:08 1999
From: gward at cnri.reston.va.us (Greg Ward)
Date: Wed, 21 Apr 1999 15:10:08 -0400
Subject: [Python-Dev] Notice of intent: rich comparisons
In-Reply-To: <199904211904.PAA14966@eric.cnri.reston.va.us>; from Guido van Rossum on Wed, Apr 21, 1999 at 03:04:40PM -0400
References: <Pine.WNT.4.04.9904211142330.174-100000@rigoletto.ski.org> <199904211904.PAA14966@eric.cnri.reston.va.us>
Message-ID: <19990421151008.D6167@cnri.reston.va.us>

On 21 April 1999, Guido van Rossum said:
> Distutil
> 
> 	Should we start integrating some of the results of the
> 	distutil SIG?  (What's the status?  I haven't been paying
> 	attention.)

It's in a state that other people can look at the code, but (apparently)
not yet good enough for floods of patches to come in.  Right now,
Distutils has *just* enough marbles to "build" and install itself on
Unix systems, and someone has contributed a patch so it works on NT.  No
support yet for compiling extensions, which of course is the important
thing.

        Greg
-- 
Greg Ward - software developer                    gward at cnri.reston.va.us
Corporation for National Research Initiatives    
1895 Preston White Drive                           voice: +1-703-620-8990
Reston, Virginia, USA  20191-5434                    fax: +1-703-620-0913



From da at ski.org  Wed Apr 21 21:19:42 1999
From: da at ski.org (David Ascher)
Date: Wed, 21 Apr 1999 12:19:42 -0700 (Pacific Daylight Time)
Subject: [Python-Dev] Notice of intent: rich comparisons
In-Reply-To: <199904211904.PAA14966@eric.cnri.reston.va.us>
Message-ID: <Pine.WNT.4.04.9904211207010.174-100000@rigoletto.ski.org>

On Wed, 21 Apr 1999, Guido van Rossum wrote:

> > Guido, how do you envision python-dev working?
> 
> I though we'd just crack Monty Python jokes while pretending to work :-)

That'd be better than what I've read on the perl5-porters list in the last
couple of days (which I'm reading because of the ad hoopla).  They seem to
spend their time arguing about whether Perl codes are programs or scripts.  
Viciously, too. =)

More seriously, some of the discussions they're having a worth keeping an
eye on, just as a form of legal industrial spying.

> Import revamp

There was an interesting bit from Greg, Jack, and MarkH on this topic
recently in the distutil-sig.  Maybe one of them can bring the rest of us
up to date on the effort.

--david






From fredrik at pythonware.com  Wed Apr 21 22:04:54 1999
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Wed, 21 Apr 1999 22:04:54 +0200
Subject: [Python-Dev] Notice of intent: rich comparisons
References: <Pine.WNT.4.04.9904211142330.174-100000@rigoletto.ski.org>  <199904211904.PAA14966@eric.cnri.reston.va.us>
Message-ID: <092701be8c32$3a4ad9f0$f29b12c2@pythonware.com>

Guido wrote:

> String methods
> 
> Barry has his patches ready.
> 
> Unicode
> 
> What is the status of /F's latest attempts?

most of the code is written and tested; the API still
needs some cleaning up. I also have a few patches
and other contributions in my inbox that I gotta
look into...

btw, the unicode module can be compiled for 8-bit
characters too.  we could merge it with the string
module (one place to fix bugs...)

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

something similar to greg's imputil.py should definitely
be in the core...

> 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 ansi2knr.c (available from http://www.cs.wisc.edu/~ghost/).
otoh, it only converts function headers, so I'm not sure it's
worth the effort...

</F>




From beazley at cs.uchicago.edu  Wed Apr 21 22:06:50 1999
From: beazley at cs.uchicago.edu (David Beazley)
Date: Wed, 21 Apr 1999 15:06:50 -0500 (CDT)
Subject: [Python-Dev] Notice of intent: rich comparisons
References: <Pine.WNT.4.04.9904211142330.174-100000@rigoletto.ski.org>
	<199904211904.PAA14966@eric.cnri.reston.va.us>
Message-ID: <199904212006.PAA17138@tartarus.cs.uchicago.edu>

Guido van Rossum writes:
> 
> 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).
> 

Maybe I'm just lucky, but I've written nothing but ANSI C for the last
8 years and have never had a problem compiling it on any machine.  I
don't see this as being a huge issue.

> 
> Misc
>

Depending on how deep I want to dig, I may have some patches to
ParseTuple() that would make life easier for some of us extension
writing fans.  As it is right now, my experimental version of Swig
is using it's own version of ParseTuple (for various reasons).
Also, out of curiousity, is anyone making heavy use of the CObject
type right now?  

Cheers,

Dave





From jim at digicool.com  Wed Apr 21 23:15:24 1999
From: jim at digicool.com (Jim Fulton)
Date: Wed, 21 Apr 1999 17:15:24 -0400
Subject: [Python-Dev] Notice of intent: rich comparisons
References: <Pine.WNT.4.04.9904211142330.174-100000@rigoletto.ski.org>
		<199904211904.PAA14966@eric.cnri.reston.va.us> <199904212006.PAA17138@tartarus.cs.uchicago.edu>
Message-ID: <371E3FEC.9D19607A@digicool.com>


David Beazley wrote:
> 
> Guido van Rossum writes:
> >
> > 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).
> >
> 
> Maybe I'm just lucky, but I've written nothing but ANSI C for the last
> 8 years and have never had a problem compiling it on any machine.  I
> don't see this as being a huge issue.

I've had the same experience with things like prototypes.
The recent introduction of indented preprocessor instructions
caused me significant pain on some platforms.  Fortunately, I 
haven't had to deal with those platforms recently, still, the elegence
of indented preporicessor instructions wasn't worth the pain it caused.

As far as choice of compilers goes, sometimes gcc isn't an option.
I've had cases where I *had* to use the native compiler in order to
link to third-party libraries.

I support moving to ANSI C, for example, wrt prototypes, but
lets still be somewhat sensative to portability and not abuse 
bad compilers without good reason.


> 
> >
> > Misc
> >
> 
> Depending on how deep I want to dig, I may have some patches to
> ParseTuple() that would make life easier for some of us extension
> writing fans.  As it is right now, my experimental version of Swig
> is using it's own version of ParseTuple (for various reasons).
> Also, out of curiousity, is anyone making heavy use of the CObject
> type right now?

Yes.

Jim

--
Jim Fulton           mailto:jim at digicool.com   Python Powered!        
Technical Director   (888) 344-4332            http://www.python.org  
Digital Creations    http://www.digicool.com   http://www.zope.org    

Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email
address may not be added to any commercial mail list with out my
permission.  Violation of my privacy with advertising or SPAM will
result in a suit for a MINIMUM of $500 damages/incident, $1500 for
repeats.



From jeremy at cnri.reston.va.us  Wed Apr 21 23:23:57 1999
From: jeremy at cnri.reston.va.us (Jeremy Hylton)
Date: Wed, 21 Apr 1999 17:23:57 -0400 (EDT)
Subject: [Python-Dev] Notice of intent: rich comparisons
In-Reply-To: <199904212006.PAA17138@tartarus.cs.uchicago.edu>
References: <Pine.WNT.4.04.9904211142330.174-100000@rigoletto.ski.org>
	<199904211904.PAA14966@eric.cnri.reston.va.us>
	<199904212006.PAA17138@tartarus.cs.uchicago.edu>
Message-ID: <14110.16787.893181.642806@bitdiddle.cnri.reston.va.us>

>>>>> "DB" == David Beazley <beazley at cs.uchicago.edu> writes:

  DB> various reasons).  Also, out of curiousity, is anyone making
  DB> heavy use of the CObject type right now?

I used it a little, but only in a modified Python backend for SWIG. 

Jeremy



From mal at lemburg.com  Wed Apr 21 23:46:46 1999
From: mal at lemburg.com (M.-A. Lemburg)
Date: Wed, 21 Apr 1999 23:46:46 +0200
Subject: [Python-Dev] Notice of intent: rich comparisons
References: <Pine.WNT.4.04.9904211142330.174-100000@rigoletto.ski.org> <199904211904.PAA14966@eric.cnri.reston.va.us>
Message-ID: <371E4746.22A84506@lemburg.com>

Guido van Rossum wrote:
> 
> Break up into VM, parser, import, mainloop, and other components?
> 
>         The porting efforts to seriously small machines (Win/CE,
>         Pilot, etc.) all seem to need a Python VM that doesn't
>         automatically pull in the parser and interactive main loop.
>         There are other reasons as well to isolate various parts
>         of the functionality (including all numeric data types except
>         ints).
> 
>         This could include: restructuring of the parser so codeop.py
>         can be simplified; making the interactive main loop a script.

There's some good work out there by Skip Montanaro to revamp the
VM into a combined register/stack machine. He calls it rattlesnake.
More infos can be found in the list archive (it's currently sleeping):

	http://www.egroups.com/folders/rattlesnake

I would like to see the VM/compiler pluggable so that experiments
like rattlesnake become easier to implement (extension modules vs.
patches to the core interpreter).

> Coercions
> 
>         Marc-Andre Lemburg has some good suggestions here:
>         http://starship.python.net/~lemburg/coercion-0.6.zip

I will continue to work on these patches now that 1.5.2 is out.

There is a (more or less) detailed explanation of the patch set
at:

	http://starship.skyport.net/~lemburg/CoercionProposal.html

Instead of using of using the PY_NEWSTYLENUMBER approach I'll
turn to the new type flags that were introduced in 1.5.2. The
Py_NotImplemented singleton return value will stay, because
performance tests have shown that this method does not cause
any significant hit where as the exception raise and catch
method does introduce a significant slow-down.

> Import revamp

Greg's imputil.py (it's in the distutils package) should provide
a good start.

> Buffer object API extensions

I'll put the complete patch up on starship later this week...
here are the basic prototypes:

    DL_IMPORT(int) PyObject_AsCharBuffer Py_PROTO((PyObject *obj,
                                                   const char **buffer,
                                                   int *buffer_len));

    /* Takes an arbitrary object which must support the (character,
       single segment) buffer interface and returns a pointer to a
       read-only memory location useable as character based input for
       subsequent processing.

       buffer and buffer_len are only set in case no error
       occurrs. Otherwise, -1 is returned and an exception set.

    */

    DL_IMPORT(int) PyObject_AsReadBuffer Py_PROTO((PyObject *obj,
                                                   const void **buffer,
                                                   int *buffer_len));

    /* Same as PyObject_AsCharBuffer() except that this API expects
       (readable, single segment) buffer interface and returns a
       pointer to a read-only memory location which can contain
       arbitrary data.

       buffer and buffer_len are only set in case no error
       occurrs. Otherwise, -1 is returned and an exception set.

    */

    DL_IMPORT(int) PyObject_AsWriteBuffer Py_PROTO((PyObject *obj,
                                                    void **buffer,
                                                    int *buffer_len));
    
    /* Takes an arbitrary object which must support the (writeable,
       single segment) buffer interface and returns a pointer to a
       writeable memory location in buffer of size buffer_len.

       buffer and buffer_len are only set in case no error
       occurrs. Otherwise, -1 is returned and an exception set.

    */

> Distutil
> 
>         Should we start integrating some of the results of the
>         distutil SIG?  (What's the status?  I haven't been paying
>         attention.)

With all the different modules and packages available for Python
starting to slowly introduce dependencies, I think the main
objective should be introducing a well organized installation
info system, e.g. a registry where modules and packages can
query and save version and dependency information. Someone on
the main list mentioned that JPython has something like this...

> Misc
> 
>         Jeremy Hylton's urllib2.py
> 
>         Greg Stein's new httplib.py (or Jeremy's?)
> 
>         Andrew Kuchling's new PCRE release?
> 
>         The IPv6 patches?

These are on my wish list, so I'll simply add them here:

? APIs to faciliate creation of extensions classes (using Python
  classes and C functions as methods)

The main open question here is where and how to store C data in
the instances. This could also provide a way to migrate to
all Python classes for some future version.

? Restructure the calling mechanism used in ceval.c to make
  it clearer, more flexible and faster (of course, :-). Also,
  inline calling of C functions/methods (this produces a noticable
  speedup).

I have a patch for the restructuring and an old one (against 1.5)
for the C function call inlining.

? A "fastpath" hook made available through the sys module.

This should hook into the module/package loader and should be
used whenever set to find a module (reverting to the standard
lookup method in case it can't find it). I have an old patch
that does this. It uses a simple Python function to redirect the
lookup to a precalculated dictionary of installed modules/packages.
This results in faster startup of the Python interpreter (by saving
a few hundred stat() calls).

-- 
Marc-Andre Lemburg                               Y2000: 254 days left
---------------------------------------------------------------------
          : Python Pages >>> http://starship.skyport.net/~lemburg/  :
           ---------------------------------------------------------




From mal at lemburg.com  Wed Apr 21 23:51:11 1999
From: mal at lemburg.com (M.-A. Lemburg)
Date: Wed, 21 Apr 1999 23:51:11 +0200
Subject: [Python-Dev] Notice of intent: rich comparisons
References: <Pine.WNT.4.04.9904211142330.174-100000@rigoletto.ski.org>
		<199904211904.PAA14966@eric.cnri.reston.va.us> <199904212006.PAA17138@tartarus.cs.uchicago.edu>
Message-ID: <371E484F.22046FE9@lemburg.com>

David Beazley wrote:
> 
> >
> > Misc
> >
> 
> Depending on how deep I want to dig, I may have some patches to
> ParseTuple() that would make life easier for some of us extension
> writing fans.  As it is right now, my experimental version of Swig
> is using it's own version of ParseTuple (for various reasons).
> Also, out of curiousity, is anyone making heavy use of the CObject
> type right now?

You mean the one in Objects/cobject.c ? Sure, all my type extensions
export their C API that way... and it works just great (no more
linker problems, nice error messages when extensions are not found,
etc.).

-- 
Marc-Andre Lemburg                               Y2000: 254 days left
---------------------------------------------------------------------
          : Python Pages >>> http://starship.skyport.net/~lemburg/  :
           ---------------------------------------------------------




From da at ski.org  Wed Apr 21 23:56:17 1999
From: da at ski.org (David Ascher)
Date: Wed, 21 Apr 1999 14:56:17 -0700 (Pacific Daylight Time)
Subject: [Python-Dev] Notice of intent: rich comparisons
In-Reply-To: <371E484F.22046FE9@lemburg.com>
Message-ID: <Pine.WNT.4.04.9904211453390.201-100000@rigoletto.ski.org>

David Beazley wrote:

> Also, out of curiousity, is anyone making heavy use of the CObject
> type right now?

NumPy does.

--da




From MHammond at skippinet.com.au  Thu Apr 22 01:45:19 1999
From: MHammond at skippinet.com.au (Mark Hammond)
Date: Thu, 22 Apr 1999 09:45:19 +1000
Subject: [Python-Dev] Notice of intent: rich comparisons
In-Reply-To: <092701be8c32$3a4ad9f0$f29b12c2@pythonware.com>
Message-ID: <004c01be8c51$043f27c0$0801a8c0@bobcat>

[Guido and /F]
> > Unicode
> >
> > What is the status of /F's latest attempts?
>
> most of the code is written and tested; the API still
> needs some cleaning up. I also have a few patches
> and other contributions in my inbox that I gotta
> look into...

Im one of those contributors :-)  I have made changes to the Win32
extensions that allows it to use /F's type instead of its own built-in
Unicode type.  Further, the Windows CE port of these extensions actually
enables this - so we have some code actively using it.

However, this still doesnt give me anything more than I had before.  We
need at least _some_ level of integration of this type into Python.  The
key areas to me are:

* PyArg_ParseTuple and Py_BuildValue - Seems OK we use the "u" format
character analogous to "s".  We havent thought of a "z" equivilent.  This
is fairly easy.

* Some way for these functions to auto-convert.  Eg, when the user passes
an 8bit string object, but the C side of the world wants a Unicode string.
This is harder, as an extra memory buffer for the conversion is needed.

This second problem is, to me, the next stumbling block.  When we sort
these out, I feel we would have the start of a good platform to start
experimenting.

Mark.




From fdrake at cnri.reston.va.us  Thu Apr 22 16:47:35 1999
From: fdrake at cnri.reston.va.us (Fred L. Drake)
Date: Thu, 22 Apr 1999 10:47:35 -0400 (EDT)
Subject: [Python-Dev] Notice of intent: rich comparisons
In-Reply-To: <16290078@toto.iv>
Message-ID: <14111.13959.211874.750734@weyr.cnri.reston.va.us>

David Beazley writes:
 > Maybe I'm just lucky, but I've written nothing but ANSI C for the last
 > 8 years and have never had a problem compiling it on any machine.  I
 > don't see this as being a huge issue.

  Wasn't SunOS 4.x the problem child here?  There are still a lot of
people using these systems, for reasons that aren't clear to me.  (Did 
support for some older hardware get dropped?  Sounds like the most
reasonable reason to use the old OS is legacy hardware.)


  -Fred

--
Fred L. Drake, Jr.	     <fdrake at acm.org>
Corporation for National Research Initiatives



From bwarsaw at cnri.reston.va.us  Thu Apr 22 17:37:46 1999
From: bwarsaw at cnri.reston.va.us (Barry A. Warsaw)
Date: Thu, 22 Apr 1999 11:37:46 -0400 (EDT)
Subject: [Python-Dev] Notice of intent: rich comparisons
References: <16290078@toto.iv>
	<14111.13959.211874.750734@weyr.cnri.reston.va.us>
Message-ID: <14111.16970.839894.147748@anthem.cnri.reston.va.us>

>>>>> "Fred" == Fred L Drake <fdrake at cnri.reston.va.us> writes:

    Fred>   Wasn't SunOS 4.x the problem child here?  There are still
    Fred> a lot of people using these systems, for reasons that aren't
    Fred> clear to me.  (Did support for some older hardware get
    Fred> dropped?  Sounds like the most reasonable reason to use the
    Fred> old OS is legacy hardware.)

There might be, but the bundled compiler in SunOS 4 was never intended 
to be used for anything more than recompiling the kernel.  Years ago,
I had conversations with Sun engineers who claimed that no bug in the
bundled compiler was ever fixed unless it directly impacted on kernel
rebuilds.  Even back then they recommended using something other than
the bundled crufty old K&R compiler for building all other stuff, and
this was when there was that huge hoopla over the unbundling of the
compiler.

SunOS 4 users can probably be mostly satisfied with gcc.

-Barry



From fdrake at cnri.reston.va.us  Thu Apr 22 17:42:57 1999
From: fdrake at cnri.reston.va.us (Fred L. Drake)
Date: Thu, 22 Apr 1999 11:42:57 -0400 (EDT)
Subject: [Python-Dev] Notice of intent: rich comparisons
In-Reply-To: <14111.16970.839894.147748@anthem.cnri.reston.va.us>
References: <16290078@toto.iv>
	<14111.13959.211874.750734@weyr.cnri.reston.va.us>
	<14111.16970.839894.147748@anthem.cnri.reston.va.us>
Message-ID: <14111.17281.999490.718527@weyr.cnri.reston.va.us>

Barry A. Warsaw writes:
 > There might be, but the bundled compiler in SunOS 4 was never intended 
 > to be used for anything more than recompiling the kernel.  Years ago,
...
 > SunOS 4 users can probably be mostly satisfied with gcc.

Barry,
  This is good enough for me.  I'd certainly rather avoid K&R C!


  -Fred

--
Fred L. Drake, Jr.	     <fdrake at acm.org>
Corporation for National Research Initiatives



From skip at mojam.com  Thu Apr 22 19:18:39 1999
From: skip at mojam.com (skip at mojam.com)
Date: Thu, 22 Apr 1999 13:18:39 -0400 (EDT)
Subject: [Python-Dev] Notice of intent: rich comparisons
In-Reply-To: <14111.17281.999490.718527@weyr.cnri.reston.va.us>
References: <16290078@toto.iv>
	<14111.13959.211874.750734@weyr.cnri.reston.va.us>
	<14111.16970.839894.147748@anthem.cnri.reston.va.us>
	<14111.17281.999490.718527@weyr.cnri.reston.va.us>
Message-ID: <14111.22873.161727.15206@cm-29-94-14.nycap.rr.com>

    Barry> SunOS 4 users can probably be mostly satisfied with gcc.

    Fred>  This is good enough for me.  I'd certainly rather avoid K&R C!

Besides, aren't there tools available that can strip most of the ANSI-ness
out of ANSI C?  (Un)Protoize?  For those (few?) people who are really still
stuck using a K&R compiler I would think those tools, perhaps supplemented
with some patch files maintained outside the main Python source tree, would
be sufficient.

Skip Montanaro	| Mojam: "Uniting the World of Music" http://www.mojam.com/
skip at mojam.com  | Musi-Cal: http://www.musi-cal.com/
518-372-5583



From bwarsaw at cnri.reston.va.us  Thu Apr 22 20:07:57 1999
From: bwarsaw at cnri.reston.va.us (Barry A. Warsaw)
Date: Thu, 22 Apr 1999 14:07:57 -0400 (EDT)
Subject: [Python-Dev] Notice of intent: rich comparisons
References: <16290078@toto.iv>
	<14111.13959.211874.750734@weyr.cnri.reston.va.us>
	<14111.16970.839894.147748@anthem.cnri.reston.va.us>
	<14111.17281.999490.718527@weyr.cnri.reston.va.us>
	<14111.22873.161727.15206@cm-29-94-14.nycap.rr.com>
Message-ID: <14111.25981.74738.355264@anthem.cnri.reston.va.us>

>>>>> "skip" ==   <skip at mojam.com> writes:

    skip> Besides, aren't there tools available that can strip most of
    skip> the ANSI-ness out of ANSI C?  (Un)Protoize?

I think so.  Seems I have unprotoize already; probably got it for free
with gcc, or some other GNU tool.

-B



From skip at mojam.com  Thu Apr 22 20:22:51 1999
From: skip at mojam.com (skip at mojam.com)
Date: Thu, 22 Apr 1999 14:22:51 -0400 (EDT)
Subject: [Python-Dev] Notice of intent: rich comparisons
In-Reply-To: <371E4746.22A84506@lemburg.com>
References: <Pine.WNT.4.04.9904211142330.174-100000@rigoletto.ski.org>
	<199904211904.PAA14966@eric.cnri.reston.va.us>
	<371E4746.22A84506@lemburg.com>
Message-ID: <14111.23085.737365.582406@cm-29-94-14.nycap.rr.com>

    mal> There's some good work out there by Skip Montanaro to revamp the VM
    mal> into a combined register/stack machine. He calls it rattlesnake.
    mal> More infos can be found in the list archive (it's currently
    mal> sleeping):

Thanks to Marc-Andre for mentioning this.  Rattlesnake is indeed sleeping at
the moment.  If anyone is interested in the idea I'd be happy to awaken it.

The main observation was that much of the virtual machine's activity is
pushing/popping objects to/from the stack.  By treating a chunk of storage
as a register file much of that churn can be avoided.

Skip Montanaro	| Mojam: "Uniting the World of Music" http://www.mojam.com/
skip at mojam.com  | Musi-Cal: http://www.musi-cal.com/
518-372-5583



From fredrik at pythonware.com  Fri Apr 23 09:48:14 1999
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Fri, 23 Apr 1999 09:48:14 +0200
Subject: [Python-Dev] Compiling ANSI C on K&R compilers
References: <16290078@toto.iv><14111.13959.211874.750734@weyr.cnri.reston.va.us><14111.16970.839894.147748@anthem.cnri.reston.va.us><14111.17281.999490.718527@weyr.cnri.reston.va.us> <14111.22873.161727.15206@cm-29-94-14.nycap.rr.com>
Message-ID: <00df01be8d5d$a82b2f70$f29b12c2@pythonware.com>

> Besides, aren't there tools available that can strip most of the ANSI-ness
> out of ANSI C?  (Un)Protoize?  For those (few?) people who are really still
> stuck using a K&R compiler I would think those tools, perhaps supplemented
> with some patch files maintained outside the main Python source tree, would
> be sufficient.

I mentioned ansi2knr.c in an earlier post.  It's a small utility,
and can be distributed with the Python core (it's GPL'd, but
since it isn't linked with Python, that's not a problem).

this is used by ghostscript and the ijg jpeg library, among
others:

ftp://ftp.cs.wisc.edu/ghost/ansi2knr.c
(or via http://www.cs.wisc.edu/~ghost/)

Cheers /F
fredrik at pythonware.com
http://www.pythonware.com




From gstein at lyra.org  Fri Apr 23 12:37:02 1999
From: gstein at lyra.org (Greg Stein)
Date: Fri, 23 Apr 1999 03:37:02 -0700
Subject: [Python-Dev] Notice of intent: rich comparisons
References: <Pine.WNT.4.04.9904211142330.174-100000@rigoletto.ski.org> <199904211904.PAA14966@eric.cnri.reston.va.us>
Message-ID: <37204D4E.2C02ABE2@lyra.org>

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/



From fdrake at cnri.reston.va.us  Fri Apr 23 15:28:12 1999
From: fdrake at cnri.reston.va.us (Fred L. Drake)
Date: Fri, 23 Apr 1999 09:28:12 -0400 (EDT)
Subject: [Python-Dev] Notice of intent: rich comparisons
In-Reply-To: <37204D4E.2C02ABE2@lyra.org>
References: <Pine.WNT.4.04.9904211142330.174-100000@rigoletto.ski.org>
	<199904211904.PAA14966@eric.cnri.reston.va.us>
	<37204D4E.2C02ABE2@lyra.org>
Message-ID: <14112.30060.552422.975547@weyr.cnri.reston.va.us>

Greg Stein writes:
 > 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)

  The Doc/ stuff is already in a separate distribution; this has been
in place for about a year (if I recall correctly).  I try to make doc
releases shortly after Python releases (I think the 1.5.2 doc release
is the longest I've waited past the Python release so far, and it may
end up being next week), and I have made interim releases as the
documentation has grown.
  I certainly think that doing something similar for the Demo/ and
Tools/ directories would be reasonable; they could share a single
distribution.


  -Fred

--
Fred L. Drake, Jr.	     <fdrake at acm.org>
Corporation for National Research Initiatives



From skip at mojam.com  Fri Apr 23 15:59:02 1999
From: skip at mojam.com (skip at mojam.com)
Date: Fri, 23 Apr 1999 09:59:02 -0400 (EDT)
Subject: [Python-Dev] Notice of intent: rich comparisons
In-Reply-To: <14112.30060.552422.975547@weyr.cnri.reston.va.us>
References: <Pine.WNT.4.04.9904211142330.174-100000@rigoletto.ski.org>
	<199904211904.PAA14966@eric.cnri.reston.va.us>
	<37204D4E.2C02ABE2@lyra.org>
	<14112.30060.552422.975547@weyr.cnri.reston.va.us>
Message-ID: <14112.31858.374462.469793@cm-29-94-14.nycap.rr.com>

    Fred> I certainly think that doing something similar for the Demo/ and
    Fred> Tools/ directories would be reasonable; they could share a single
    Fred> distribution.

We need to make sure none of the tools are needed in the install
process. h2py comes to mind.

Skip Montanaro	| Mojam: "Uniting the World of Music" http://www.mojam.com/
skip at mojam.com  | Musi-Cal: http://www.musi-cal.com/
518-372-5583



From jeremy at cnri.reston.va.us  Mon Apr 26 17:26:28 1999
From: jeremy at cnri.reston.va.us (Jeremy Hylton)
Date: Mon, 26 Apr 1999 11:26:28 -0400 (EDT)
Subject: [Python-Dev] Notice of intent: rich comparisons
In-Reply-To: <37204D4E.2C02ABE2@lyra.org>
References: <Pine.WNT.4.04.9904211142330.174-100000@rigoletto.ski.org>
	<199904211904.PAA14966@eric.cnri.reston.va.us>
	<37204D4E.2C02ABE2@lyra.org>
Message-ID: <14116.33341.371508.53071@bitdiddle.cnri.reston.va.us>

>>>>> "GS" == Greg Stein <gstein at lyra.org> writes:

  >> Greg Stein's new httplib.py (or Jeremy's?)

  GS> Mine is a drop-in replacement for the current
  GS> httplib.py. httplib.HTTP is compatible with the current version
  GS> and does HTTP/1.0.  httplib.HTTPConnection is similar to the
  GS> other (but (IMO) cleans up a few elements of the API); it does
  GS> HTTP/1.1, including persistent connections. This module follows
  GS> the design of the original httplib.py much more
  GS> closely. Jeremy's module uses a very different design approach
  GS> (no value judgement here; it's just different); also, it simply
  GS> copies over the old HTTP class, while mine derives the
  GS> compatible version from HTTPConnection. I'm not sure how much
  GS> testing Jeremy's has had, but I use my module for all
  GS> Python-based http work now. Some number of other people have
  GS> downloaded and used it, too.

  GS> I would recommend my new module, given the two options.

I think I agree.  I stopped working on my version quite some time ago, 
before I made enough progress to make it useful.  Thus, it makes a lot 
of sense to use Greg's working code.

I'd be curious to see how to use HTTPConnection to do persistent
connections and pipelined requests.  It wasn't entirely clear from the 
code what I would need to do to keep the connection open.  Do you just
re-use the HTTPConnection object -- call putrequest again after
getreply? 

I like the revised API that Greg's code uses.  The request method on
HTTPConnection objects cleans the API up in exactly the right way.  It 
has always seemed unnecessary to have many separate calls to add
headers and then a call to endheaders after putrequest.  Packaging
them all together in one method will simplify client code a lot.

  GS> I'll eventually have a davlib.py to add to the distribution, but
  GS> it needs more work. I'll contribute that later.

Cool!

Jeremy




From guido at CNRI.Reston.VA.US  Mon Apr 26 18:16:11 1999
From: guido at CNRI.Reston.VA.US (Guido van Rossum)
Date: Mon, 26 Apr 1999 12:16:11 -0400
Subject: [Python-Dev] Public or private python-dev archives?
Message-ID: <199904261616.MAA22036@eric.cnri.reston.va.us>

In a private mail, Greg Stein suggested that the python-dev archives
should be restricted to the members of the list.  I prefer to make
them public, but I won't want to impose this on others without
discussion.  So I've made the archives private for the time being
while we discuss this meta-issue.  (Also, the existence of the list
isn't announced by mailman on its listinfo page.)

Here's my argument for open archives.  I don't think that we have
anything to hide from the public -- I think of us as a technical forum
whose discussions may affect others (e.g. Python users) and I think
it's often useful for those others to be able to see what we've said.

I want to keep membership of the list closed as a gentle way to
enforce focus and quality of discussion.

Jeremy pointed out that there's no restiction on posting, and
mentioned that together with open archives this makes the list just as
open as an open-subscription list.  I don't see this equivalence --
certainly it makes a difference in practice, and the open posting is
simply a mechanism to allow members with multiple email addresses to
post from whereever they are.  If we regularly get spammed or find the 
list is targeted by angry Python users we might have to restrict
posting to members (and deal with the multiple address problem).

I hope the discussion about this issue will be short (otherwise it
would detract from the real goal of this list).  I'll follow the
desire of the majority of current members; once we have a decision I
propose to stick with it and simply present new members with the
facts.

--Guido van Rossum (home page: http://www.python.org/~guido/)



From gward at cnri.reston.va.us  Mon Apr 26 18:30:43 1999
From: gward at cnri.reston.va.us (Greg Ward)
Date: Mon, 26 Apr 1999 12:30:43 -0400
Subject: [Python-Dev] Public or private python-dev archives?
In-Reply-To: <199904261616.MAA22036@eric.cnri.reston.va.us>; from Guido van Rossum on Mon, Apr 26, 1999 at 12:16:11PM -0400
References: <199904261616.MAA22036@eric.cnri.reston.va.us>
Message-ID: <19990426123042.A2617@cnri.reston.va.us>

On 26 April 1999, Guido van Rossum said:
> In a private mail, Greg Stein suggested that the python-dev archives
> should be restricted to the members of the list.  I prefer to make
> them public, but I won't want to impose this on others without
> discussion.  So I've made the archives private for the time being
> while we discuss this meta-issue.  (Also, the existence of the list
> isn't announced by mailman on its listinfo page.)
> 
> Here's my argument for open archives.  I don't think that we have
> anything to hide from the public -- I think of us as a technical forum
> whose discussions may affect others (e.g. Python users) and I think
> it's often useful for those others to be able to see what we've said.

I favour as much openness as possible that's consistent with high
signal-to-noise.  Opening the archives doesn't affect SN ratio; for that
matter, neither does allowing anyone to *read* the list while keeping
posting privileges restricted.  And letting the world know that the list
exists -- even though posting privileges are restricted -- shouldn't
affect quality.

So I guess my position is: definitely open the archives and publicise
the list -- the benefit of an open archive is reduced if people can't
stumble across it like they can any sig.  And consider the possibility
of open subscription while keeping posting restricted.  Not sure how
easy that is with Mailman, but we can still consider the idea.

The open, friendly nature of the Python community is a huge strength.  I
tentatively agree that posting privileges should be restricted to keep
quality high, but the idea of a "secret cabal" discussing Python
development off in a dark corner away from the grubby masses seems very
counter to the spirit I've seen so far.

        Greg
-- 
Greg Ward - software developer                    gward at cnri.reston.va.us
Corporation for National Research Initiatives    
1895 Preston White Drive                           voice: +1-703-620-8990
Reston, Virginia, USA  20191-5434                    fax: +1-703-620-0913



From da at ski.org  Mon Apr 26 18:29:56 1999
From: da at ski.org (David Ascher)
Date: Mon, 26 Apr 1999 09:29:56 -0700 (Pacific Daylight Time)
Subject: [Python-Dev] Public or private python-dev archives?
In-Reply-To: <199904261616.MAA22036@eric.cnri.reston.va.us>
Message-ID: <Pine.WNT.4.04.9904260922170.273-100000@rigoletto.ski.org>

On Mon, 26 Apr 1999, Guido van Rossum wrote:

> In a private mail, Greg Stein suggested that the python-dev archives
> should be restricted to the members of the list.  I prefer to make
> them public, but I won't want to impose this on others without
> discussion.  So I've made the archives private for the time being
> while we discuss this meta-issue.  (Also, the existence of the list
> isn't announced by mailman on its listinfo page.)

If one has a public archive with restricted membership, then one needs to
have a process for people to petition membership, including policies on
deciding admission (which could be as vague as "up to GvR's whim").

FWIW, the perl5-porters list is open but the perl6-porters list is closed.

My suggestion is that we can start with an open policy on archives, and
the lax posting policy for the multiple email address business (which
should be incorporated in mailman++ =), with the explicitely stated caveat
that if it turns out that that policy doesn't work, we reserve the right
to tighten things up. I also suggest that we don't advertise the fact that
anyone can post.  [Except of course that we've just mentioned this in
archives which I'm arguing should be public =)]

--david





From bwarsaw at cnri.reston.va.us  Mon Apr 26 19:44:36 1999
From: bwarsaw at cnri.reston.va.us (Barry A. Warsaw)
Date: Mon, 26 Apr 1999 13:44:36 -0400 (EDT)
Subject: [Python-Dev] Public or private python-dev archives?
References: <199904261616.MAA22036@eric.cnri.reston.va.us>
	<19990426123042.A2617@cnri.reston.va.us>
Message-ID: <14116.42500.284907.569281@anthem.cnri.reston.va.us>

>>>>> "GW" == Greg Ward <gward at cnri.reston.va.us> writes:

    GW> And consider the possibility of open subscription while
    GW> keeping posting restricted.  Not sure how easy that is with
    GW> Mailman, but we can still consider the idea.

It could be done in a number of ways.  You could restrict postings to
members only, but as Guido has pointed out, a lot of people post from
more than one account and Mailman doesn't handle that very well yet.
Or you could moderate the list, but then someone has to approve
postings and that's more work than I think anybody wants to do.

I'm also for an open-as-possible policy, with the right to restrict
later if the s/n gets too low.  I sort of view Python-dev to be the
place that serious c.l.py proposals get fleshed out and implementation 
strategies discussed.  The (hopefully) high level of technical detail
on the list should self-select.

-Barry



From gmcm at hypernet.com  Mon Apr 26 20:56:52 1999
From: gmcm at hypernet.com (Gordon McMillan)
Date: Mon, 26 Apr 1999 13:56:52 -0500
Subject: [Python-Dev] Public or private python-dev archives?
In-Reply-To: <14116.42500.284907.569281@anthem.cnri.reston.va.us>
Message-ID: <1286969269-56980208@hypernet.com>

[Barry]
> The (hopefully) high level of
> technical detail on the list should self-select.

I thought the humor did that.

If the public-archive were only updated weekly, it would make it's 
use (or abuse) as glorified help list pretty tenuous.

No one has espoused Greg's reasoning. In the abscense of 
said arguments, I'm certainly inclined to vote for "as public as can 
be and still be focused".

-OTOH-then-I'll-never-know-what-goes-on-in-the-smoke-filled-room-ly 
y'rs

- Gordon



From da at ski.org  Mon Apr 26 21:12:54 1999
From: da at ski.org (David Ascher)
Date: Mon, 26 Apr 1999 12:12:54 -0700 (Pacific Daylight Time)
Subject: [Python-Dev] Why unbundle Tools and Demo?
Message-ID: <Pine.WNT.4.04.9904261203430.59-100000@rigoletto.ski.org>

Several people argue for unbundling Tools/ and Demo/ in 1.6.  I'd like to
argue to leave them in.  They're not especially big, and IMHO they are
quite valuable, *especially* to the novice user.  In fact, I'd like to
argue that Demo/ should be promoted to the same status as Tools/ (by which
I mean included in the Windows binary distribution). Unbundling Tools/
would mean unbundling IDLE, which IMHO would be a big strategic mistake.

However, I wouldn't be against a cleanup of said directories.  Some things
should probably be removed (anything which uses stdwin), some of the code
in classes is showing its age (notes about "being upgraded for Python 1.1"
=), etc.  That said, the tkinter/ directory is the best place to look for
simple Tkinter code, and should be included, IMHO.

--david











From guido at CNRI.Reston.VA.US  Mon Apr 26 21:20:26 1999
From: guido at CNRI.Reston.VA.US (Guido van Rossum)
Date: Mon, 26 Apr 1999 15:20:26 -0400
Subject: [Python-Dev] Why unbundle Tools and Demo?
In-Reply-To: Your message of "Mon, 26 Apr 1999 12:12:54 PDT."
             <Pine.WNT.4.04.9904261203430.59-100000@rigoletto.ski.org> 
References: <Pine.WNT.4.04.9904261203430.59-100000@rigoletto.ski.org> 
Message-ID: <199904261920.PAA22415@eric.cnri.reston.va.us>

> Several people argue for unbundling Tools/ and Demo/ in 1.6.  I'd like to
> argue to leave them in.  They're not especially big, and IMHO they are
> quite valuable, *especially* to the novice user.  In fact, I'd like to
> argue that Demo/ should be promoted to the same status as Tools/ (by which
> I mean included in the Windows binary distribution). Unbundling Tools/
> would mean unbundling IDLE, which IMHO would be a big strategic mistake.
> 
> However, I wouldn't be against a cleanup of said directories.  Some things
> should probably be removed (anything which uses stdwin), some of the code
> in classes is showing its age (notes about "being upgraded for Python 1.1"
> =), etc.  That said, the tkinter/ directory is the best place to look for
> simple Tkinter code, and should be included, IMHO.

Agreed.  One simple thing that would help me immensely would be for
someone to go through all the various Demo directories and make an
inventary of what is there and how useful it is, (1) to all Python
users, (2) to Windows users.  Then, perhaps someone could write a
simple document making these files (and Tools) more accessible...

--Guido van Rossum (home page: http://www.python.org/~guido/)



From da at ski.org  Mon Apr 26 21:20:40 1999
From: da at ski.org (David Ascher)
Date: Mon, 26 Apr 1999 12:20:40 -0700 (Pacific Daylight Time)
Subject: [Python-Dev] Why unbundle Tools and Demo?
In-Reply-To: <199904261920.PAA22415@eric.cnri.reston.va.us>
Message-ID: <Pine.WNT.4.04.9904261220200.59-100000@rigoletto.ski.org>

> someone to go through all the various Demo directories and make an
> inventary of what is there and how useful it is, (1) to all Python
> users, (2) to Windows users.  Then, perhaps someone could write a
> simple document making these files (and Tools) more accessible...

Ok.  I can do that.






From guido at CNRI.Reston.VA.US  Mon Apr 26 21:22:55 1999
From: guido at CNRI.Reston.VA.US (Guido van Rossum)
Date: Mon, 26 Apr 1999 15:22:55 -0400
Subject: [Python-Dev] Why unbundle Tools and Demo?
In-Reply-To: Your message of "Mon, 26 Apr 1999 12:20:40 PDT."
             <Pine.WNT.4.04.9904261220200.59-100000@rigoletto.ski.org> 
References: <Pine.WNT.4.04.9904261220200.59-100000@rigoletto.ski.org> 
Message-ID: <199904261922.PAA22447@eric.cnri.reston.va.us>

[me]
> > someone to go through all the various Demo directories and make an
> > inventary of what is there and how useful it is, (1) to all Python
> > users, (2) to Windows users.  Then, perhaps someone could write a
> > simple document making these files (and Tools) more accessible...

[Dave]
> Ok.  I can do that.

Great!  I didn't mean to volunteer you -- but I think you'd do a great 
job.

--Guido van Rossum (home page: http://www.python.org/~guido/)



From tim_one at email.msn.com  Tue Apr 27 06:25:19 1999
From: tim_one at email.msn.com (Tim Peters)
Date: Tue, 27 Apr 1999 00:25:19 -0400
Subject: [Python-Dev] Public or private python-dev archives?
In-Reply-To: <19990426123042.A2617@cnri.reston.va.us>
Message-ID: <000501be9065$f5e3db80$ab9e2299@tim>

[Greg Ward, arguing in favor of
    ...
    a "secret cabal" discussing Python development off in a dark corner
    away from the grubby masses
]

That's what I'd like too -- but somebody already let Gordon in <wink>.

voting-to-leave-it-public-until-there's-a-problem-ly y'rs  - tim





From da at ski.org  Tue Apr 27 21:23:55 1999
From: da at ski.org (David Ascher)
Date: Tue, 27 Apr 1999 12:23:55 -0700 (Pacific Daylight Time)
Subject: [Python-Dev] numpy
Message-ID: <Pine.WNT.4.04.9904271220520.64-100000@rigoletto.ski.org>

What are the thoughts on NumPy integration into the core?

--David




From MHammond at skippinet.com.au  Wed Apr 28 01:28:59 1999
From: MHammond at skippinet.com.au (Mark Hammond)
Date: Wed, 28 Apr 1999 09:28:59 +1000
Subject: [Python-Dev] numpy
In-Reply-To: <Pine.WNT.4.04.9904271220520.64-100000@rigoletto.ski.org>
Message-ID: <001c01be9105$bae7ccd0$0801a8c0@bobcat>

> What are the thoughts on NumPy integration into the core?

he he - and while we are at it :-)  mxDateTime would need to be a popular
choice for inclusion, and Guido has offered in-principle support for moving
some of the Win32 stuff into the core - particularly the Registry stuff and
the native Window Handle support...

How far do we go :-)

Personally, I would simply like to see the distutils SIG solve this problem
for us.  (sure).  Eg, the "build" or "install" process (depending on the
OS) could build a local HTML file with knowledge many "common" extensions -
a single click, and it is downloaded, configured and built.   Oh well, back
to reality...

[Which isnt to say I am opposed to NumPy and mxDateTime.  Definately keen
on the win32 stuff tho :-]

Mark.




From da at ski.org  Wed Apr 28 01:31:56 1999
From: da at ski.org (David Ascher)
Date: Tue, 27 Apr 1999 16:31:56 -0700 (Pacific Daylight Time)
Subject: [Python-Dev] numpy
In-Reply-To: <001c01be9105$bae7ccd0$0801a8c0@bobcat>
Message-ID: <Pine.WNT.4.04.9904271628320.64-100000@rigoletto.ski.org>

On Wed, 28 Apr 1999, Mark Hammond wrote:

> > What are the thoughts on NumPy integration into the core?
> 
> he he - and while we are at it :-)  mxDateTime would need to be a popular
> choice for inclusion, and Guido has offered in-principle support for moving
> some of the Win32 stuff into the core - particularly the Registry stuff and
> the native Window Handle support...

It may seem strange, but I'll argue for the win32 registry calls before
the NumPy stuff.  That could be because I've looked at NumPy code and not
the win32 code.  Not Jim's cleanest code. =)

Mark, can you describe 'native Window Handle' support?

--david





From MHammond at skippinet.com.au  Wed Apr 28 07:03:48 1999
From: MHammond at skippinet.com.au (Mark Hammond)
Date: Wed, 28 Apr 1999 15:03:48 +1000
Subject: [Python-Dev] numpy
In-Reply-To: <Pine.WNT.4.04.9904271628320.64-100000@rigoletto.ski.org>
Message-ID: <001e01be9134$809ca8f0$0801a8c0@bobcat>

> It may seem strange, but I'll argue for the win32 registry
> calls before
> the NumPy stuff.  That could be because I've looked at NumPy
> code and not
> the win32 code.  Not Jim's cleanest code. =)

he he - and I can even get out of the Win32 stuff - I wrote a string-only
first version, and Bill Tutt rehashed it into what it is today, handling
all the registry types.

OTOH, there could also be a case for moving "win32api" completely to "core
status" (whether that means truly core or simply a standard .pyd).  For
example, ntpath.py now has code that attempts to use
"win32api.GetFullPathName()".

The down-side is that win32api has nowhere near complete coverage, and is
really a mixed bag of bits and pieces.  Most later efforts where complete
API sets are given coverage have different names - eg, win32file has the
complete Win32 file API wrapped up - even if there are overlaps with
existing functions in win32api.

Im not sure what the answer is - my guess is a new core module with Win32
features deemed absolutely necessary for the core - stuff like the
registry, and a few assorted other functions, such as GetFullPathName, but
stopping well short of the full win32api set.

> Mark, can you describe 'native Window Handle' support?

Sure!  We have a very light-weight "handle" object, representing a Win32
handle.  It has no methods, and a single property for returning the
underlying win32 handle as an integer.  When the object destructs, it calls
"CloseHandle()".  Thats about it!

It has no methods, so is passed as an argument.  There has been no attempt
to implement things like "handle.Read()" to represent "ReadFile(handle,
...)".  There are 2 reasons for this:
1) Handles are fairly general purpose, and not restricted to IO operations.
A handle is also used to represent a Mutex/Semaphores and
threads/processes - certainly doesnt make sense to have a "Read()" method
for those handles.
2) IMO, this should be done at the .py level anyway.  The Win32 Handle
support is pure C++ at the moment.

A simple complication is that there are 3 types of handles in use at the
moment - those that call "CloseHandle", those that call "RegCloseHandle"
(registry handles) and a 3rd I cant recall.  This is currently implemented
using C++ inheritance.  But even if the current implementation is not
favoured, the object is so small that a rewrite would not be a problem.

And for those that can be bothered to read this far, some more background:
Some time ago, Greg and I decided to implement a "pywintypes" module.  This
defines what we considered "core types" for the Win32 world.  All our
extension modules (including win32api, COM; basically win32*.pyd) use this
module.  The objects it supports are: Unicode, Handles, Win32 Time, IIDs,
Overlapped IO objects, 3 NT security related objects and importantly a
standard Win32 exception and functions for filling it.

Moving the registry stuff is dependant on the core having the Exception,
Handle and Registry support (hence this discussion).  We have our own Time
object, but mxDateTime would be fine.  One day, we hope to remove this
pywintypes entirely, as the core will have it all :-)

Mark.




From gward at cnri.reston.va.us  Wed Apr 28 14:51:43 1999
From: gward at cnri.reston.va.us (Greg Ward)
Date: Wed, 28 Apr 1999 08:51:43 -0400
Subject: [Python-Dev] numpy
In-Reply-To: <001c01be9105$bae7ccd0$0801a8c0@bobcat>; from Mark Hammond on Wed, Apr 28, 1999 at 09:28:59AM +1000
References: <Pine.WNT.4.04.9904271220520.64-100000@rigoletto.ski.org> <001c01be9105$bae7ccd0$0801a8c0@bobcat>
Message-ID: <19990428085143.A5571@cnri.reston.va.us>

On 28 April 1999, Mark Hammond said:
> How far do we go :-)
> 
> Personally, I would simply like to see the distutils SIG solve this problem
> for us.  (sure).  Eg, the "build" or "install" process (depending on the
> OS) could build a local HTML file with knowledge many "common" extensions -
> a single click, and it is downloaded, configured and built.   Oh well, back
> to reality...

It's not impossible, it just takes a while.  I think it took the Perl
community about three years to go from "hey! let's have a standard build
mechanism for modules!" to the point where I can install (almost) any
module from CPAN with one shell command:

  perl -MCPAN -e 'install ("MIME::Base64");'

which is insanely cool.  (It took about two minutes to do the above just
now; that included trying two CPAN mirrors that aren't being cooperative
this morning, finding one that was working, downloading the current
module list from it, determining that there is a more recent version
available than the one installed here, downloading it, unpacking it,
running "Makefile.PL" to generate the Makefile, running "make" [which
compiles any extensions in the distribution, copies all the .pm files
around, and generates the documentation], "make test" [run the module's
self-test suite], and "make install" [install it in the "site-perl"
library directory].  Amount of user interaction required: typing the
above command line.)

It's *still* rough around the edges, though, especially when building a
new installation from scratch -- mainly because Perl doesn't ship with
ftp or http libraries, so the CPAN.pm module has to try downloading
stuff with lynx, ncftp, or plain ol' ftp until it has downloaded and
installed the libnet and libwww-perl distributions.  That's one problem
we won't have with Python, at least.  Oh yeah, and it all works *great*
under Unix... but the rest of the world lags behind.

Also, two major components of being able to do this -- the Perl Module
List and CPAN -- are still vapourware in Python-land.  But hey, if we
can get to the "we *have* a standard build mechanism for modules!"
point, then all the rest becomes a lot more feasible.

Pep talk over...

        Greg
-- 
Greg Ward - software developer                    gward at cnri.reston.va.us
Corporation for National Research Initiatives    
1895 Preston White Drive                           voice: +1-703-620-8990
Reston, Virginia, USA  20191-5434                    fax: +1-703-620-0913



From mal at lemburg.com  Wed Apr 28 09:44:25 1999
From: mal at lemburg.com (M.-A. Lemburg)
Date: Wed, 28 Apr 1999 09:44:25 +0200
Subject: [Python-Dev] numpy
References: <001c01be9105$bae7ccd0$0801a8c0@bobcat>
Message-ID: <3726BC59.35E3C9DB@lemburg.com>

Mark Hammond wrote:
> 
> > What are the thoughts on NumPy integration into the core?
> 
> he he - and while we are at it :-)  mxDateTime would need to be a popular
> choice for inclusion, and Guido has offered in-principle support for moving
> some of the Win32 stuff into the core - particularly the Registry stuff and
> the native Window Handle support...
> 
> How far do we go :-)
> 
> Personally, I would simply like to see the distutils SIG solve this problem
> for us.  (sure).  Eg, the "build" or "install" process (depending on the
> OS) could build a local HTML file with knowledge many "common" extensions -
> a single click, and it is downloaded, configured and built.   Oh well, back
> to reality...

You're talking about fast moving targets there... are you sure that
you want those in the standard distribution ?

Maybe we have two distributions: the standard one and a pro
edition with all the slick stuff included (together with a
proper setup script to get those references to external libs
and include files right).

Actually, this is something I've been wanting to do for nearly
a year now... just haven't found the time to really get things
the way I want them. It's a project called Python Power Tools
and includes many generic extensions (currently only ones that
don't rely on external libs).

If you're interested, have a look at an old version available at:

    http://starship.skyport.net/~lemburg/PowerTools-0.2.zip

It includes the extensions BTree, mxDateTime, mxTools, mxStack,
Trie, avl and kjbuckets. NumPy should probably also be included.
The current setup uses a recursive Makefile approach (not too
elegant, but works). A distutils setup would be much better.

-- 
Marc-Andre Lemburg                               Y2000: 247 days left
---------------------------------------------------------------------
          : Python Pages >>> http://starship.skyport.net/~lemburg/  :
           ---------------------------------------------------------





From jack at oratrix.nl  Wed Apr 28 15:48:21 1999
From: jack at oratrix.nl (Jack Jansen)
Date: Wed, 28 Apr 1999 15:48:21 +0200
Subject: [Python-Dev] numpy 
In-Reply-To: Message by "Mark Hammond" <MHammond@skippinet.com.au> ,
	     Wed, 28 Apr 1999 09:28:59 +1000 , <001c01be9105$bae7ccd0$0801a8c0@bobcat>
Message-ID: <19990428134821.E9A68300F57@snelboot.oratrix.nl>

> [...] Guido has offered in-principle support for moving
> some of the Win32 stuff into the core - particularly the Registry stuff and
> the native Window Handle support...

I think it would be nice to put all the stuff that is shared between modules 
(I think that's only PyWinTypes, but who am I to think I have a clue about the 
windows port:-) into the core.

I just did the same for MacPython, and it makes life a whole lot easier.
--
Jack Jansen             | ++++ stop the execution of Mumia Abu-Jamal ++++
Jack.Jansen at oratrix.com | ++++ if you agree copy these lines to your sig ++++
www.oratrix.nl/~jack    | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm 





From skip at mojam.com  Wed Apr 28 17:57:40 1999
From: skip at mojam.com (skip at mojam.com)
Date: Wed, 28 Apr 1999 11:57:40 -0400
Subject: [Python-Dev] LLNL C++ as base for Python 2?
Message-ID: <199904281557.LAA06491@cm-29-94-14.nycap.rr.com>

Have we been talking about Python 2 or Python 1.6?  If we're talking about
Python 2, has anyone given a serious look at the LLNL gang's C++/Python
stuff?  If I recall Paul Dubois' talk at the last conference, it sounded
like their work made it much easier to implement extension modules.

Skip Montanaro	| Mojam: "Uniting the World of Music" http://www.mojam.com/
skip at mojam.com  | Musi-Cal: http://www.musi-cal.com/
518-372-5583




From guido at CNRI.Reston.VA.US  Wed Apr 28 18:06:03 1999
From: guido at CNRI.Reston.VA.US (Guido van Rossum)
Date: Wed, 28 Apr 1999 12:06:03 -0400
Subject: [Python-Dev] LLNL C++ as base for Python 2?
In-Reply-To: Your message of "Wed, 28 Apr 1999 11:57:40 EDT."
             <199904281557.LAA06491@cm-29-94-14.nycap.rr.com> 
References: <199904281557.LAA06491@cm-29-94-14.nycap.rr.com> 
Message-ID: <199904281606.MAA27526@eric.cnri.reston.va.us>

> Have we been talking about Python 2 or Python 1.6?  If we're talking about
> Python 2, has anyone given a serious look at the LLNL gang's C++/Python
> stuff?  If I recall Paul Dubois' talk at the last conference, it sounded
> like their work made it much easier to implement extension modules.

I've mostly had 1.6 in mind.  See recent traffic in the C++ SIG
archives for the status of Paul's CXX.

--Guido van Rossum (home page: http://www.python.org/~guido/)



From da at ski.org  Wed Apr 28 19:24:00 1999
From: da at ski.org (David Ascher)
Date: Wed, 28 Apr 1999 10:24:00 -0700 (Pacific Daylight Time)
Subject: [Python-Dev] LLNL C++ as base for Python 2?
In-Reply-To: <199904281606.MAA27526@eric.cnri.reston.va.us>
Message-ID: <Pine.WNT.4.04.9904281021061.346-100000@rigoletto.ski.org>

On Wed, 28 Apr 1999, Guido van Rossum wrote:

> > Have we been talking about Python 2 or Python 1.6?  If we're talking about
> > Python 2, has anyone given a serious look at the LLNL gang's C++/Python
> > stuff?  If I recall Paul Dubois' talk at the last conference, it sounded
> > like their work made it much easier to implement extension modules.
> 
> I've mostly had 1.6 in mind.  See recent traffic in the C++ SIG
> archives for the status of Paul's CXX.

Recent traffic?  There's nothing in there that's substantive since... uh,
well, I got tired of looking back. =)

CXX is very cool, but it is still pushing the envelope of many C++
compilers.  From what I gather, recent egcs' do manage with it, and since
egcs is going to replace gcc, I expect that many platforms will be able to
"do" CXX relatively soon.

I vote to stay on the 1.6 track for now.




From MHammond at skippinet.com.au  Fri Apr 30 04:40:09 1999
From: MHammond at skippinet.com.au (Mark Hammond)
Date: Fri, 30 Apr 1999 12:40:09 +1000
Subject: [Python-Dev] More flexible namespaces.
Message-ID: <008d01be92b2$c56ef5d0$0801a8c0@bobcat>

Here is a bit of an idea that I first came up with some years ago.  Guido's
response at the time was "sounds reasonable as long as we dont slow the
normal case down".

To cut a long story short, I would like eval and exec to be capable of
working with arbitrary mapping objects rather than only dictionaries.  The
general idea is that I can provide a class with mapping semantics, and pass
this to exec/eval.

This would give us 2 seriously cool features (that I want <wink>), should
anyone decide to write code that enables them:

* Case insensitive namespaces.  This would be very cool for COM, and as far
as I know would please the Alice people.  May open up more embedding
opportunities that are lost if people feel strongly about this issue.

* Dynamic name lookups.  At the moment, dynamic attribute lookups are
simple, but dynamic name lookups are hard.  If I execute code "print foo",
foo _must_ pre-exist in the namespace.  There is no reasonable way I can
some up with so that I can fetch "foo" as it is requested (raising the
NameError if necessary).  This would also be very cool for some of the COM
work - particularly Active Scripting.

Of course, these would not be enabled by standard Python, but would allow
people to create flexible execution environments that suit their purpose.

Any comments on this?  Is it a dumb idea?  Anyone have a feel for how deep
these changes would cut?  Its not something I want to happen soon, but it
does seem a reasonable mechanism that can provide very flexible
solutions...

Mark.




From guido at CNRI.Reston.VA.US  Fri Apr 30 05:00:52 1999
From: guido at CNRI.Reston.VA.US (Guido van Rossum)
Date: Thu, 29 Apr 1999 23:00:52 -0400
Subject: [Python-Dev] More flexible namespaces.
In-Reply-To: Your message of "Fri, 30 Apr 1999 12:40:09 +1000."
             <008d01be92b2$c56ef5d0$0801a8c0@bobcat> 
References: <008d01be92b2$c56ef5d0$0801a8c0@bobcat> 
Message-ID: <199904300300.XAA00608@eric.cnri.reston.va.us>

> To cut a long story short, I would like eval and exec to be capable of
> working with arbitrary mapping objects rather than only dictionaries.  The
> general idea is that I can provide a class with mapping semantics, and pass
> this to exec/eval.

I agree that this would be seriously cool.  It will definitely be in
Python 2.0; it's already in JPython.

Quite a while ago, Ian Castleden sent me patches for 1.5.1 to do this.
It was a lot of code and I was indeed worried about slowing things
down too much (and also about checking that he got all the endcases
right).

Ian did benchmarks and found that the new code was consistently
slower, by 3-6%.  Perhaps for Python 1.6 this will be acceptable (the
"Python IS slow" thread notwithstanding :-); or perhaps someone can
have a look at it and squeeze some more time out of it?  I'll gladly
forward the patches.

--Guido van Rossum (home page: http://www.python.org/~guido/)



From da at ski.org  Fri Apr 30 05:21:04 1999
From: da at ski.org (David Ascher)
Date: Thu, 29 Apr 1999 20:21:04 -0700 (Pacific Daylight Time)
Subject: [Python-Dev] More flexible namespaces.
In-Reply-To: <199904300300.XAA00608@eric.cnri.reston.va.us>
Message-ID: <Pine.WNT.4.05.9904292018290.153-100000@david.ski.org>

> > To cut a long story short, I would like eval and exec to be capable of
> > working with arbitrary mapping objects rather than only dictionaries.  The
> > general idea is that I can provide a class with mapping semantics, and pass
> > this to exec/eval.
> 
> I agree that this would be seriously cool.  It will definitely be in
> Python 2.0; it's already in JPython.

Seriously cool is an understatement. 

--david




From MHammond at skippinet.com.au  Fri Apr 30 06:13:25 1999
From: MHammond at skippinet.com.au (Mark Hammond)
Date: Fri, 30 Apr 1999 14:13:25 +1000
Subject: [Python-Dev] More flexible namespaces.
In-Reply-To: <199904300300.XAA00608@eric.cnri.reston.va.us>
Message-ID: <009001be92bf$cb998f80$0801a8c0@bobcat>

> Ian did benchmarks and found that the new code was consistently
> slower, by 3-6%.  Perhaps for Python 1.6 this will be acceptable (the
> "Python IS slow" thread notwithstanding :-); or perhaps someone can

As long as we get someone working on a consistent 3-6% speedup in other
areas this wont be a problem :-)

I will attach it to my long list - but Im going to put all my efforts here
into Unicode first, and probably the threading stuff second :-)

Mark.




From tismer at appliedbiometrics.com  Fri Apr 30 09:49:42 1999
From: tismer at appliedbiometrics.com (Christian Tismer)
Date: Fri, 30 Apr 1999 09:49:42 +0200
Subject: [Python-Dev] More flexible namespaces.
References: <008d01be92b2$c56ef5d0$0801a8c0@bobcat> <199904300300.XAA00608@eric.cnri.reston.va.us>
Message-ID: <37296096.D0C9C2CC@appliedbiometrics.com>


Guido van Rossum wrote:
...
> Ian did benchmarks and found that the new code was consistently
> slower, by 3-6%.  Perhaps for Python 1.6 this will be acceptable (the
> "Python IS slow" thread notwithstanding :-); or perhaps someone can
> have a look at it and squeeze some more time out of it?  I'll gladly
> forward the patches.

I'd really like to look into that.
Also I wouldn't worry too much about speed, since this is 
such a cool feature. It might even be a speedup in some cases
which otherwise would need more complex handling.

May I have a look?

ciao - chris

-- 
Christian Tismer             :^)   <mailto:tismer at appliedbiometrics.com>
Applied Biometrics GmbH      :     Have a break! Take a ride on Python's
Kaiserin-Augusta-Allee 101   :    *Starship* http://starship.python.net
10553 Berlin                 :     PGP key -> http://wwwkeys.pgp.net
PGP Fingerprint       E182 71C7 1A9D 66E9 9D15  D3CC D4D7 93E2 1FAE F6DF
     we're tired of banana software - shipped green, ripens at home



From mal at lemburg.com  Fri Apr 30 10:22:46 1999
From: mal at lemburg.com (M.-A. Lemburg)
Date: Fri, 30 Apr 1999 10:22:46 +0200
Subject: [Python-Dev] More flexible namespaces.
References: <008d01be92b2$c56ef5d0$0801a8c0@bobcat>
Message-ID: <37296856.5875AAAF@lemburg.com>

Mark Hammond wrote:
> 
> Here is a bit of an idea that I first came up with some years ago.  Guido's
> response at the time was "sounds reasonable as long as we dont slow the
> normal case down".
> 
> To cut a long story short, I would like eval and exec to be capable of
> working with arbitrary mapping objects rather than only dictionaries.  The
> general idea is that I can provide a class with mapping semantics, and pass
> this to exec/eval.

This involves a whole lot of changes: not only in the Python core,
but also in extensions that rely on having real dictionaries available.

Since you put out to objectives, I'd like to propose a little
different approach...

1. Have eval/exec accept any mapping object as input

2. Make those two copy the content of the mapping object into real
   dictionaries

3. Provide a hook into the dictionary implementation that can be
   used to redirect KeyErrors and use that redirection to forward
   the request to the original mapping objects

> This would give us 2 seriously cool features (that I want <wink>), should
> anyone decide to write code that enables them:
> 
> * Case insensitive namespaces.  This would be very cool for COM, and as far
> as I know would please the Alice people.  May open up more embedding
> opportunities that are lost if people feel strongly about this issue.

This is covered by 1 and 2.

> * Dynamic name lookups.  At the moment, dynamic attribute lookups are
> simple, but dynamic name lookups are hard.  If I execute code "print foo",
> foo _must_ pre-exist in the namespace.  There is no reasonable way I can
> some up with so that I can fetch "foo" as it is requested (raising the
> NameError if necessary).  This would also be very cool for some of the COM
> work - particularly Active Scripting.

This is something for 3.

I guess it wouldn't cause any significant slow-down and can be
imlemented with much less code than the "change all PyDict_GetItem
to PyObject_GetItem" thingie.

The real thing could then be done for 2.0 where PyDict_Check()
would presumably not rely on an adress but some kind of inheritance
scheme indicating that the object is in fact a dictionary.

Cheers,
-- 
Marc-Andre Lemburg                               Y2000: 245 days left
---------------------------------------------------------------------
          : Python Pages >>> http://starship.skyport.net/~lemburg/  :
           ---------------------------------------------------------




From guido at CNRI.Reston.VA.US  Fri Apr 30 17:17:20 1999
From: guido at CNRI.Reston.VA.US (Guido van Rossum)
Date: Fri, 30 Apr 1999 11:17:20 -0400
Subject: [Python-Dev] More flexible namespaces.
In-Reply-To: Your message of "Fri, 30 Apr 1999 09:49:42 +0200."
             <37296096.D0C9C2CC@appliedbiometrics.com> 
References: <008d01be92b2$c56ef5d0$0801a8c0@bobcat> <199904300300.XAA00608@eric.cnri.reston.va.us>  
            <37296096.D0C9C2CC@appliedbiometrics.com> 
Message-ID: <199904301517.LAA01422@eric.cnri.reston.va.us>

> From: Christian Tismer <tismer at appliedbiometrics.com>

> I'd really like to look into that.
> Also I wouldn't worry too much about speed, since this is 
> such a cool feature. It might even be a speedup in some cases
> which otherwise would need more complex handling.
> 
> May I have a look?

Sure!

(I've forwarded Christian the files per separate mail.)

I'm also interested in your opinion on how well thought-out and robust
the patches are -- I've never found the time to do a good close
reading of them.

--Guido van Rossum (home page: http://www.python.org/~guido/)



From gmcm at hypernet.com  Fri Apr 30 18:32:30 1999
From: gmcm at hypernet.com (Gordon McMillan)
Date: Fri, 30 Apr 1999 11:32:30 -0500
Subject: [Python-Dev] More flexible namespaces.
In-Reply-To: <199904301517.LAA01422@eric.cnri.reston.va.us>
References: Your message of "Fri, 30 Apr 1999 09:49:42 +0200."             <37296096.D0C9C2CC@appliedbiometrics.com> 
Message-ID: <1286632328-77246936@hypernet.com>

Guido wrote:

> > From: Christian Tismer <tismer at appliedbiometrics.com>
> 
> > I'd really like to look into that.
> > Also I wouldn't worry too much about speed, since this is 
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > such a cool feature. It might even be a speedup in some cases
> > which otherwise would need more complex handling.
> > 
> > May I have a look?
> 
> Sure!
> 
> (I've forwarded Christian the files per separate mail.)

I don't know who you sent that to, but it couldn't possibly have been 
Christian!

- Gordon



From tismer at appliedbiometrics.com  Fri Apr 30 17:57:09 1999
From: tismer at appliedbiometrics.com (Christian Tismer)
Date: Fri, 30 Apr 1999 17:57:09 +0200
Subject: [Python-Dev] More flexible namespaces.
References: <008d01be92b2$c56ef5d0$0801a8c0@bobcat> <199904300300.XAA00608@eric.cnri.reston.va.us>  
	            <37296096.D0C9C2CC@appliedbiometrics.com> <199904301517.LAA01422@eric.cnri.reston.va.us>
Message-ID: <3729D2D5.6844D6DA@appliedbiometrics.com>


Guido van Rossum wrote:
> 
> > From: Christian Tismer <tismer at appliedbiometrics.com>
> > May I have a look?
> 
> Sure!
> 
> (I've forwarded Christian the files per separate mail.)

Thanks a lot! 

> I'm also interested in your opinion on how well thought-out and robust
> the patches are -- I've never found the time to do a good close
> reading of them.

Yes, it is quite long and not so very easy to digest.
At first glance, most of the changes are replacements of
dict access with mapping access where we pay for the extra
indirection.
It depends on how often this feature will really replace
dicts. If dicts are more common, I'd like to figure out
how much code bloat extra special casing for dicts would give.

Puha - thanks - chris

-- 
Christian Tismer             :^)   <mailto:tismer at appliedbiometrics.com>
Applied Biometrics GmbH      :     Have a break! Take a ride on Python's
Kaiserin-Augusta-Allee 101   :    *Starship* http://starship.python.net
10553 Berlin                 :     PGP key -> http://wwwkeys.pgp.net
PGP Fingerprint       E182 71C7 1A9D 66E9 9D15  D3CC D4D7 93E2 1FAE F6DF
     we're tired of banana software - shipped green, ripens at home



From tismer at appliedbiometrics.com  Fri Apr 30 18:19:57 1999
From: tismer at appliedbiometrics.com (Christian Tismer)
Date: Fri, 30 Apr 1999 18:19:57 +0200
Subject: [Python-Dev] More flexible namespaces.
References: Your message of "Fri, 30 Apr 1999 09:49:42 +0200."             <37296096.D0C9C2CC@appliedbiometrics.com> <1286632328-77246936@hypernet.com>
Message-ID: <3729D82D.CE16884@appliedbiometrics.com>


Gordon McMillan wrote:
> 
> Guido wrote:
> 
> > > From: Christian Tismer <tismer at appliedbiometrics.com>
> >
> > > I'd really like to look into that.
> > > Also I wouldn't worry too much about speed, since this is
>     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > > such a cool feature. It might even be a speedup in some cases
> > > which otherwise would need more complex handling.
> > >
> > > May I have a look?
> >
> > Sure!
> >
> > (I've forwarded Christian the files per separate mail.)
> 
> I don't know who you sent that to, but it couldn't possibly have been
> Christian!

:-) :-) truely not if I had'n other things in mind.

I know that I will not get more than 30-40 percent by compiling
the interpreter away, so I will not even spend time at a
register machine right now. Will also not follow the ideas of
P2C any longer, doesn't pay off.
Instead, If I can manage to create something like static binding
snapshots, then I could resolve many of the lookups and internal
method indirections, for time critical applications.
For all the rest, Python is pretty much fast enough.

I've begun to write s special platform dependant version
which allows me to do all the things which can't go into the dist.
For instance, I just saved some 10 percent by dynamically
patching some of the ParseTuple and BuildObject calls out of the
core code (ahem). I hope Python will stay as clean as it is,
allowing me to try all kinds of tricks for one machine class.

ciao - chris.speedy

-- 
Christian Tismer             :^)   <mailto:tismer at appliedbiometrics.com>
Applied Biometrics GmbH      :     Have a break! Take a ride on Python's
Kaiserin-Augusta-Allee 101   :    *Starship* http://starship.python.net
10553 Berlin                 :     PGP key -> http://wwwkeys.pgp.net
PGP Fingerprint       E182 71C7 1A9D 66E9 9D15  D3CC D4D7 93E2 1FAE F6DF
     we're tired of banana software - shipped green, ripens at home



From akuchlin at cnri.reston.va.us  Fri Apr 30 18:33:34 1999
From: akuchlin at cnri.reston.va.us (Andrew M. Kuchling)
Date: Fri, 30 Apr 1999 12:33:34 -0400 (EDT)
Subject: [Python-Dev] More flexible namespaces.
In-Reply-To: <3729D82D.CE16884@appliedbiometrics.com>
References: <37296096.D0C9C2CC@appliedbiometrics.com>
	<1286632328-77246936@hypernet.com>
	<3729D82D.CE16884@appliedbiometrics.com>
Message-ID: <14121.55659.754846.708467@amarok.cnri.reston.va.us>

Christian Tismer writes:
>Instead, If I can manage to create something like static binding
>snapshots, then I could resolve many of the lookups and internal
>method indirections, for time critical applications.

	The usual assumption is that the lookups are what takes time.
Now, are we sure of that assumption?  I'd expect the lookup code to be
like:

1) Get hash of name
2) Retrieve object from dictionary
3) Do something with the object.

Now, since string objects cache their hash value, 1) should usually be
just "if (obj->cached_hash_value!=-1) return obj->cached_hash_value";
a comparision and a return.  Step 2) should be very fast, barring a
bad hash function.  So perhaps most of the time is spent in 3),
creating new local dicts, stack frames, and what not.  (Yes, I know
that doing this on every reference to an object is part of the
problem.)  I also wonder about the costs of all the Py_BuildValue and
Py_ParseTuple calls going on under the hood.  A performance
improvement project would definitely be a good idea for 1.6, and a
good sub-topic for python-dev.

	Incidentally, what's the verdict on python-dev archives:
public or not?

-- 
A.M. Kuchling			http://starship.python.net/crew/amk/
Despair says little, and is patient.
    -- From SANDMAN: "Season of Mists", episode 0




From tismer at appliedbiometrics.com  Fri Apr 30 18:55:55 1999
From: tismer at appliedbiometrics.com (Christian Tismer)
Date: Fri, 30 Apr 1999 18:55:55 +0200
Subject: [Python-Dev] More flexible namespaces.
References: <37296096.D0C9C2CC@appliedbiometrics.com>
		<1286632328-77246936@hypernet.com>
		<3729D82D.CE16884@appliedbiometrics.com> <14121.55659.754846.708467@amarok.cnri.reston.va.us>
Message-ID: <3729E09B.5F65E3CA@appliedbiometrics.com>


"Andrew M. Kuchling" wrote:
> 
> Christian Tismer writes:
> >Instead, If I can manage to create something like static binding
> >snapshots, then I could resolve many of the lookups and internal
> >method indirections, for time critical applications.
> 
>         The usual assumption is that the lookups are what takes time.
> Now, are we sure of that assumption?  I'd expect the lookup code to be
> like:
> 
> 1) Get hash of name
> 2) Retrieve object from dictionary
> 3) Do something with the object.
...
Right, but when you become more restrictive, you can do
lots, lots more. If I also allow to fix the type of an object,
I can go under the hood of the Python API, so you could
add some points 4) 5) 6) here.
But I shouldn't have talked before I can show something.
And at the time, I don't restrict myself to write clean
code, but try very machine specific things which I
don't believe should go into Python at all.

> I also wonder about the costs of all the Py_BuildValue and
> Py_ParseTuple calls going on under the hood.  A performance
> improvement project would definitely be a good idea for 1.6, and a
> good sub-topic for python-dev.

I wasn't sure, so I first wrote a module which does statistics
on that, and I found a lot of these calls. Some are even 
involved in ceval's code, where things like "(OOOO)" is parsed
all over again and again. Now I think this is ok in most cases.
But in some places these are very bad: If your builtin function
soes so very few work. 
Take len(): This uses ParseTuple, which calls a function to
find out its object, then calls a function to get the object,
then takes the len, and builds the result. But since everything
has a length, checking for no NULL pointer and grabbing the len
produces even shorter code. This applies to many places as well.
But right now, I don't change the core, but build hacky little
extension modules which squeak such things out at runtime.
No big deal yet, but maybe it could pay off to introduce
format strings which make them more suitableto be used
in macro substitutions.

sorry if I was too elaborate, this is so much fun :-)

ciao - chris

-- 
Christian Tismer             :^)   <mailto:tismer at appliedbiometrics.com>
Applied Biometrics GmbH      :     Have a break! Take a ride on Python's
Kaiserin-Augusta-Allee 101   :    *Starship* http://starship.python.net
10553 Berlin                 :     PGP key -> http://wwwkeys.pgp.net
PGP Fingerprint       E182 71C7 1A9D 66E9 9D15  D3CC D4D7 93E2 1FAE F6DF
     we're tired of banana software - shipped green, ripens at home



From skip at mojam.com  Wed Apr 21 15:17:32 1999
From: skip at mojam.com (skip at mojam.com)
Date: Wed, 21 Apr 1999 09:17:32 -0400
Subject: [Python-Dev] ZServer 1.0b1: spurious colon in HTTP response line
Message-ID: <199904211317.JAA26167@cm-29-94-14.nycap.rr.com>

(Also reported to the bug catcher.)

I'm trying to migrate from ZopeHTTPServer to ZServer 1.0b1.  I was seeing
the ZServer headers turning up in pages generated by the process.  When I
viewed the page source of the generated HTML I saw:

    HTTP/1.0: 200 OK
    Server: Zope/experimental ZServer/1.1b1
    Date: Wed, 21 Apr 1999 13:00:38 GMT
    X-Powered-By: Zope (www.zope.org), Python (www.python.org)
    Connection: close
    Content-Type: text/html
    Content-Length: 7802
    

    <!-- -*-html-helper -*- -->
    <HTML>
    <HEAD>
    <TITLE>Musi-Cal... Concert Schedules: Folk Music, Country Music, Rock Music &amp; more!</TITLE>
    ...

I run ZServer behind an Apache 1.3.3 running mod_proxy.  Apparently Apache
doesn't recognize the HTTP response when there is a colon following the
version number and adds a simple set of headers itself.  I guess web
browsers either ignore that line or are more lenient in their parsing of the
response.

The following simple patch corrects the problem:

diff -c2 HTTPResponse.py.~1~ HTTPResponse.py
*** HTTPResponse.py.~1~	Tue Apr 13 15:21:12 1999
--- HTTPResponse.py	Wed Apr 21 09:05:00 1999
***************
*** 146,150 ****
       
          # status header must come first.
!         append("HTTP/%s: %s" % (self._http_version, status))
          if headers.has_key('status'):
              del headers['status']
--- 146,150 ----
       
          # status header must come first.
!         append("HTTP/%s %s" % (self._http_version, status))
          if headers.has_key('status'):
              del headers['status']
***************


Skip Montanaro	| Mojam: "Uniting the World of Music" http://www.mojam.com/
skip at mojam.com  | Musi-Cal: http://www.musi-cal.com/
518-372-5583



From da at ski.org  Wed Apr 21 20:47:56 1999
From: da at ski.org (David Ascher)
Date: Wed, 21 Apr 1999 11:47:56 -0700 (Pacific Daylight Time)
Subject: [Python-Dev] Notice of intent: rich comparisons
Message-ID: <Pine.WNT.4.04.9904211142330.174-100000@rigoletto.ski.org>

Now that 1.5.2 is finalized, I'll be starting to prepare a patch for the
rich comparisons.  

Guido, how do you envision python-dev working?  Do you want to hand out a
TODO list for 1.6?

--david





From guido at CNRI.Reston.VA.US  Wed Apr 21 21:04:40 1999
From: guido at CNRI.Reston.VA.US (Guido van Rossum)
Date: Wed, 21 Apr 1999 15:04:40 -0400
Subject: [Python-Dev] Notice of intent: rich comparisons
In-Reply-To: Your message of "Wed, 21 Apr 1999 11:47:56 PDT."
             <Pine.WNT.4.04.9904211142330.174-100000@rigoletto.ski.org> 
References: <Pine.WNT.4.04.9904211142330.174-100000@rigoletto.ski.org> 
Message-ID: <199904211904.PAA14966@eric.cnri.reston.va.us>

> Now that 1.5.2 is finalized, I'll be starting to prepare a patch for the
> rich comparisons.  

Cool!

> Guido, how do you envision python-dev working?

I though we'd just crack Monty Python jokes while pretending to work :-)

> Do you want to hand out a TODO list for 1.6?

Well, I'm not saying that this is the definitive list, but certainly
there are a bunch of things that definitely need to be incorporated.
Here's an excerpt of a list that I keep for myself, in no particular
order, with brief annotations (I have a meeting in 15 minutes :):

Redesign thread/init APIs

	See the recent discussion in the thread-sig.  There should be
	some kind of micro-init that initializes essential components
	(including the thread lock!) but doesn't create an interpreter
	or a threadstate object.  There should also be a notion of a
	default interpreter.

Break up into VM, parser, import, mainloop, and other components?

	The porting efforts to seriously small machines (Win/CE,
	Pilot, etc.) all seem to need a Python VM that doesn't
	automatically pull in the parser and interactive main loop.
	There are other reasons as well to isolate various parts
	of the functionality (including all numeric data types except
	ints).

	This could include: restructuring of the parser so codeop.py
	can be simplified; making the interactive main loop a script.

String methods

	Barry has his patches ready.

Unicode

	What is the status of /F's latest attempts?

Rich comparisons

	This is Dave's plan.

Coercions

	Marc-Andre Lemburg has some good suggestions here:
	http://starship.python.net/~lemburg/coercion-0.6.zip

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.

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

Buffer object API extensions

	Marc-Andre Lemburg has a patch

Distutil

	Should we start integrating some of the results of the
	distutil SIG?  (What's the status?  I haven't been paying
	attention.)

Misc

	Jeremy Hylton's urllib2.py

	Greg Stein's new httplib.py (or Jeremy's?)

	Andrew Kuchling's new PCRE release?

	The IPv6 patches?

Gotta run!

--Guido van Rossum (home page: http://www.python.org/~guido/)



From gward at cnri.reston.va.us  Wed Apr 21 21:10:08 1999
From: gward at cnri.reston.va.us (Greg Ward)
Date: Wed, 21 Apr 1999 15:10:08 -0400
Subject: [Python-Dev] Notice of intent: rich comparisons
In-Reply-To: <199904211904.PAA14966@eric.cnri.reston.va.us>; from Guido van Rossum on Wed, Apr 21, 1999 at 03:04:40PM -0400
References: <Pine.WNT.4.04.9904211142330.174-100000@rigoletto.ski.org> <199904211904.PAA14966@eric.cnri.reston.va.us>
Message-ID: <19990421151008.D6167@cnri.reston.va.us>

On 21 April 1999, Guido van Rossum said:
> Distutil
> 
> 	Should we start integrating some of the results of the
> 	distutil SIG?  (What's the status?  I haven't been paying
> 	attention.)

It's in a state that other people can look at the code, but (apparently)
not yet good enough for floods of patches to come in.  Right now,
Distutils has *just* enough marbles to "build" and install itself on
Unix systems, and someone has contributed a patch so it works on NT.  No
support yet for compiling extensions, which of course is the important
thing.

        Greg
-- 
Greg Ward - software developer                    gward at cnri.reston.va.us
Corporation for National Research Initiatives    
1895 Preston White Drive                           voice: +1-703-620-8990
Reston, Virginia, USA  20191-5434                    fax: +1-703-620-0913



From da at ski.org  Wed Apr 21 21:19:42 1999
From: da at ski.org (David Ascher)
Date: Wed, 21 Apr 1999 12:19:42 -0700 (Pacific Daylight Time)
Subject: [Python-Dev] Notice of intent: rich comparisons
In-Reply-To: <199904211904.PAA14966@eric.cnri.reston.va.us>
Message-ID: <Pine.WNT.4.04.9904211207010.174-100000@rigoletto.ski.org>

On Wed, 21 Apr 1999, Guido van Rossum wrote:

> > Guido, how do you envision python-dev working?
> 
> I though we'd just crack Monty Python jokes while pretending to work :-)

That'd be better than what I've read on the perl5-porters list in the last
couple of days (which I'm reading because of the ad hoopla).  They seem to
spend their time arguing about whether Perl codes are programs or scripts.  
Viciously, too. =)

More seriously, some of the discussions they're having a worth keeping an
eye on, just as a form of legal industrial spying.

> Import revamp

There was an interesting bit from Greg, Jack, and MarkH on this topic
recently in the distutil-sig.  Maybe one of them can bring the rest of us
up to date on the effort.

--david






From fredrik at pythonware.com  Wed Apr 21 22:04:54 1999
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Wed, 21 Apr 1999 22:04:54 +0200
Subject: [Python-Dev] Notice of intent: rich comparisons
References: <Pine.WNT.4.04.9904211142330.174-100000@rigoletto.ski.org>  <199904211904.PAA14966@eric.cnri.reston.va.us>
Message-ID: <092701be8c32$3a4ad9f0$f29b12c2@pythonware.com>

Guido wrote:

> String methods
> 
> Barry has his patches ready.
> 
> Unicode
> 
> What is the status of /F's latest attempts?

most of the code is written and tested; the API still
needs some cleaning up. I also have a few patches
and other contributions in my inbox that I gotta
look into...

btw, the unicode module can be compiled for 8-bit
characters too.  we could merge it with the string
module (one place to fix bugs...)

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

something similar to greg's imputil.py should definitely
be in the core...

> 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 ansi2knr.c (available from http://www.cs.wisc.edu/~ghost/).
otoh, it only converts function headers, so I'm not sure it's
worth the effort...

</F>




From beazley at cs.uchicago.edu  Wed Apr 21 22:06:50 1999
From: beazley at cs.uchicago.edu (David Beazley)
Date: Wed, 21 Apr 1999 15:06:50 -0500 (CDT)
Subject: [Python-Dev] Notice of intent: rich comparisons
References: <Pine.WNT.4.04.9904211142330.174-100000@rigoletto.ski.org>
	<199904211904.PAA14966@eric.cnri.reston.va.us>
Message-ID: <199904212006.PAA17138@tartarus.cs.uchicago.edu>

Guido van Rossum writes:
> 
> 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).
> 

Maybe I'm just lucky, but I've written nothing but ANSI C for the last
8 years and have never had a problem compiling it on any machine.  I
don't see this as being a huge issue.

> 
> Misc
>

Depending on how deep I want to dig, I may have some patches to
ParseTuple() that would make life easier for some of us extension
writing fans.  As it is right now, my experimental version of Swig
is using it's own version of ParseTuple (for various reasons).
Also, out of curiousity, is anyone making heavy use of the CObject
type right now?  

Cheers,

Dave





From jim at digicool.com  Wed Apr 21 23:15:24 1999
From: jim at digicool.com (Jim Fulton)
Date: Wed, 21 Apr 1999 17:15:24 -0400
Subject: [Python-Dev] Notice of intent: rich comparisons
References: <Pine.WNT.4.04.9904211142330.174-100000@rigoletto.ski.org>
		<199904211904.PAA14966@eric.cnri.reston.va.us> <199904212006.PAA17138@tartarus.cs.uchicago.edu>
Message-ID: <371E3FEC.9D19607A@digicool.com>


David Beazley wrote:
> 
> Guido van Rossum writes:
> >
> > 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).
> >
> 
> Maybe I'm just lucky, but I've written nothing but ANSI C for the last
> 8 years and have never had a problem compiling it on any machine.  I
> don't see this as being a huge issue.

I've had the same experience with things like prototypes.
The recent introduction of indented preprocessor instructions
caused me significant pain on some platforms.  Fortunately, I 
haven't had to deal with those platforms recently, still, the elegence
of indented preporicessor instructions wasn't worth the pain it caused.

As far as choice of compilers goes, sometimes gcc isn't an option.
I've had cases where I *had* to use the native compiler in order to
link to third-party libraries.

I support moving to ANSI C, for example, wrt prototypes, but
lets still be somewhat sensative to portability and not abuse 
bad compilers without good reason.


> 
> >
> > Misc
> >
> 
> Depending on how deep I want to dig, I may have some patches to
> ParseTuple() that would make life easier for some of us extension
> writing fans.  As it is right now, my experimental version of Swig
> is using it's own version of ParseTuple (for various reasons).
> Also, out of curiousity, is anyone making heavy use of the CObject
> type right now?

Yes.

Jim

--
Jim Fulton           mailto:jim at digicool.com   Python Powered!        
Technical Director   (888) 344-4332            http://www.python.org  
Digital Creations    http://www.digicool.com   http://www.zope.org    

Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email
address may not be added to any commercial mail list with out my
permission.  Violation of my privacy with advertising or SPAM will
result in a suit for a MINIMUM of $500 damages/incident, $1500 for
repeats.



From jeremy at cnri.reston.va.us  Wed Apr 21 23:23:57 1999
From: jeremy at cnri.reston.va.us (Jeremy Hylton)
Date: Wed, 21 Apr 1999 17:23:57 -0400 (EDT)
Subject: [Python-Dev] Notice of intent: rich comparisons
In-Reply-To: <199904212006.PAA17138@tartarus.cs.uchicago.edu>
References: <Pine.WNT.4.04.9904211142330.174-100000@rigoletto.ski.org>
	<199904211904.PAA14966@eric.cnri.reston.va.us>
	<199904212006.PAA17138@tartarus.cs.uchicago.edu>
Message-ID: <14110.16787.893181.642806@bitdiddle.cnri.reston.va.us>

>>>>> "DB" == David Beazley <beazley at cs.uchicago.edu> writes:

  DB> various reasons).  Also, out of curiousity, is anyone making
  DB> heavy use of the CObject type right now?

I used it a little, but only in a modified Python backend for SWIG. 

Jeremy



From mal at lemburg.com  Wed Apr 21 23:46:46 1999
From: mal at lemburg.com (M.-A. Lemburg)
Date: Wed, 21 Apr 1999 23:46:46 +0200
Subject: [Python-Dev] Notice of intent: rich comparisons
References: <Pine.WNT.4.04.9904211142330.174-100000@rigoletto.ski.org> <199904211904.PAA14966@eric.cnri.reston.va.us>
Message-ID: <371E4746.22A84506@lemburg.com>

Guido van Rossum wrote:
> 
> Break up into VM, parser, import, mainloop, and other components?
> 
>         The porting efforts to seriously small machines (Win/CE,
>         Pilot, etc.) all seem to need a Python VM that doesn't
>         automatically pull in the parser and interactive main loop.
>         There are other reasons as well to isolate various parts
>         of the functionality (including all numeric data types except
>         ints).
> 
>         This could include: restructuring of the parser so codeop.py
>         can be simplified; making the interactive main loop a script.

There's some good work out there by Skip Montanaro to revamp the
VM into a combined register/stack machine. He calls it rattlesnake.
More infos can be found in the list archive (it's currently sleeping):

	http://www.egroups.com/folders/rattlesnake

I would like to see the VM/compiler pluggable so that experiments
like rattlesnake become easier to implement (extension modules vs.
patches to the core interpreter).

> Coercions
> 
>         Marc-Andre Lemburg has some good suggestions here:
>         http://starship.python.net/~lemburg/coercion-0.6.zip

I will continue to work on these patches now that 1.5.2 is out.

There is a (more or less) detailed explanation of the patch set
at:

	http://starship.skyport.net/~lemburg/CoercionProposal.html

Instead of using of using the PY_NEWSTYLENUMBER approach I'll
turn to the new type flags that were introduced in 1.5.2. The
Py_NotImplemented singleton return value will stay, because
performance tests have shown that this method does not cause
any significant hit where as the exception raise and catch
method does introduce a significant slow-down.

> Import revamp

Greg's imputil.py (it's in the distutils package) should provide
a good start.

> Buffer object API extensions

I'll put the complete patch up on starship later this week...
here are the basic prototypes:

    DL_IMPORT(int) PyObject_AsCharBuffer Py_PROTO((PyObject *obj,
                                                   const char **buffer,
                                                   int *buffer_len));

    /* Takes an arbitrary object which must support the (character,
       single segment) buffer interface and returns a pointer to a
       read-only memory location useable as character based input for
       subsequent processing.

       buffer and buffer_len are only set in case no error
       occurrs. Otherwise, -1 is returned and an exception set.

    */

    DL_IMPORT(int) PyObject_AsReadBuffer Py_PROTO((PyObject *obj,
                                                   const void **buffer,
                                                   int *buffer_len));

    /* Same as PyObject_AsCharBuffer() except that this API expects
       (readable, single segment) buffer interface and returns a
       pointer to a read-only memory location which can contain
       arbitrary data.

       buffer and buffer_len are only set in case no error
       occurrs. Otherwise, -1 is returned and an exception set.

    */

    DL_IMPORT(int) PyObject_AsWriteBuffer Py_PROTO((PyObject *obj,
                                                    void **buffer,
                                                    int *buffer_len));
    
    /* Takes an arbitrary object which must support the (writeable,
       single segment) buffer interface and returns a pointer to a
       writeable memory location in buffer of size buffer_len.

       buffer and buffer_len are only set in case no error
       occurrs. Otherwise, -1 is returned and an exception set.

    */

> Distutil
> 
>         Should we start integrating some of the results of the
>         distutil SIG?  (What's the status?  I haven't been paying
>         attention.)

With all the different modules and packages available for Python
starting to slowly introduce dependencies, I think the main
objective should be introducing a well organized installation
info system, e.g. a registry where modules and packages can
query and save version and dependency information. Someone on
the main list mentioned that JPython has something like this...

> Misc
> 
>         Jeremy Hylton's urllib2.py
> 
>         Greg Stein's new httplib.py (or Jeremy's?)
> 
>         Andrew Kuchling's new PCRE release?
> 
>         The IPv6 patches?

These are on my wish list, so I'll simply add them here:

? APIs to faciliate creation of extensions classes (using Python
  classes and C functions as methods)

The main open question here is where and how to store C data in
the instances. This could also provide a way to migrate to
all Python classes for some future version.

? Restructure the calling mechanism used in ceval.c to make
  it clearer, more flexible and faster (of course, :-). Also,
  inline calling of C functions/methods (this produces a noticable
  speedup).

I have a patch for the restructuring and an old one (against 1.5)
for the C function call inlining.

? A "fastpath" hook made available through the sys module.

This should hook into the module/package loader and should be
used whenever set to find a module (reverting to the standard
lookup method in case it can't find it). I have an old patch
that does this. It uses a simple Python function to redirect the
lookup to a precalculated dictionary of installed modules/packages.
This results in faster startup of the Python interpreter (by saving
a few hundred stat() calls).

-- 
Marc-Andre Lemburg                               Y2000: 254 days left
---------------------------------------------------------------------
          : Python Pages >>> http://starship.skyport.net/~lemburg/  :
           ---------------------------------------------------------




From mal at lemburg.com  Wed Apr 21 23:51:11 1999
From: mal at lemburg.com (M.-A. Lemburg)
Date: Wed, 21 Apr 1999 23:51:11 +0200
Subject: [Python-Dev] Notice of intent: rich comparisons
References: <Pine.WNT.4.04.9904211142330.174-100000@rigoletto.ski.org>
		<199904211904.PAA14966@eric.cnri.reston.va.us> <199904212006.PAA17138@tartarus.cs.uchicago.edu>
Message-ID: <371E484F.22046FE9@lemburg.com>

David Beazley wrote:
> 
> >
> > Misc
> >
> 
> Depending on how deep I want to dig, I may have some patches to
> ParseTuple() that would make life easier for some of us extension
> writing fans.  As it is right now, my experimental version of Swig
> is using it's own version of ParseTuple (for various reasons).
> Also, out of curiousity, is anyone making heavy use of the CObject
> type right now?

You mean the one in Objects/cobject.c ? Sure, all my type extensions
export their C API that way... and it works just great (no more
linker problems, nice error messages when extensions are not found,
etc.).

-- 
Marc-Andre Lemburg                               Y2000: 254 days left
---------------------------------------------------------------------
          : Python Pages >>> http://starship.skyport.net/~lemburg/  :
           ---------------------------------------------------------




From da at ski.org  Wed Apr 21 23:56:17 1999
From: da at ski.org (David Ascher)
Date: Wed, 21 Apr 1999 14:56:17 -0700 (Pacific Daylight Time)
Subject: [Python-Dev] Notice of intent: rich comparisons
In-Reply-To: <371E484F.22046FE9@lemburg.com>
Message-ID: <Pine.WNT.4.04.9904211453390.201-100000@rigoletto.ski.org>

David Beazley wrote:

> Also, out of curiousity, is anyone making heavy use of the CObject
> type right now?

NumPy does.

--da




From MHammond at skippinet.com.au  Thu Apr 22 01:45:19 1999
From: MHammond at skippinet.com.au (Mark Hammond)
Date: Thu, 22 Apr 1999 09:45:19 +1000
Subject: [Python-Dev] Notice of intent: rich comparisons
In-Reply-To: <092701be8c32$3a4ad9f0$f29b12c2@pythonware.com>
Message-ID: <004c01be8c51$043f27c0$0801a8c0@bobcat>

[Guido and /F]
> > Unicode
> >
> > What is the status of /F's latest attempts?
>
> most of the code is written and tested; the API still
> needs some cleaning up. I also have a few patches
> and other contributions in my inbox that I gotta
> look into...

Im one of those contributors :-)  I have made changes to the Win32
extensions that allows it to use /F's type instead of its own built-in
Unicode type.  Further, the Windows CE port of these extensions actually
enables this - so we have some code actively using it.

However, this still doesnt give me anything more than I had before.  We
need at least _some_ level of integration of this type into Python.  The
key areas to me are:

* PyArg_ParseTuple and Py_BuildValue - Seems OK we use the "u" format
character analogous to "s".  We havent thought of a "z" equivilent.  This
is fairly easy.

* Some way for these functions to auto-convert.  Eg, when the user passes
an 8bit string object, but the C side of the world wants a Unicode string.
This is harder, as an extra memory buffer for the conversion is needed.

This second problem is, to me, the next stumbling block.  When we sort
these out, I feel we would have the start of a good platform to start
experimenting.

Mark.




From fdrake at cnri.reston.va.us  Thu Apr 22 16:47:35 1999
From: fdrake at cnri.reston.va.us (Fred L. Drake)
Date: Thu, 22 Apr 1999 10:47:35 -0400 (EDT)
Subject: [Python-Dev] Notice of intent: rich comparisons
In-Reply-To: <16290078@toto.iv>
Message-ID: <14111.13959.211874.750734@weyr.cnri.reston.va.us>

David Beazley writes:
 > Maybe I'm just lucky, but I've written nothing but ANSI C for the last
 > 8 years and have never had a problem compiling it on any machine.  I
 > don't see this as being a huge issue.

  Wasn't SunOS 4.x the problem child here?  There are still a lot of
people using these systems, for reasons that aren't clear to me.  (Did 
support for some older hardware get dropped?  Sounds like the most
reasonable reason to use the old OS is legacy hardware.)


  -Fred

--
Fred L. Drake, Jr.	     <fdrake at acm.org>
Corporation for National Research Initiatives



From bwarsaw at cnri.reston.va.us  Thu Apr 22 17:37:46 1999
From: bwarsaw at cnri.reston.va.us (Barry A. Warsaw)
Date: Thu, 22 Apr 1999 11:37:46 -0400 (EDT)
Subject: [Python-Dev] Notice of intent: rich comparisons
References: <16290078@toto.iv>
	<14111.13959.211874.750734@weyr.cnri.reston.va.us>
Message-ID: <14111.16970.839894.147748@anthem.cnri.reston.va.us>

>>>>> "Fred" == Fred L Drake <fdrake at cnri.reston.va.us> writes:

    Fred>   Wasn't SunOS 4.x the problem child here?  There are still
    Fred> a lot of people using these systems, for reasons that aren't
    Fred> clear to me.  (Did support for some older hardware get
    Fred> dropped?  Sounds like the most reasonable reason to use the
    Fred> old OS is legacy hardware.)

There might be, but the bundled compiler in SunOS 4 was never intended 
to be used for anything more than recompiling the kernel.  Years ago,
I had conversations with Sun engineers who claimed that no bug in the
bundled compiler was ever fixed unless it directly impacted on kernel
rebuilds.  Even back then they recommended using something other than
the bundled crufty old K&R compiler for building all other stuff, and
this was when there was that huge hoopla over the unbundling of the
compiler.

SunOS 4 users can probably be mostly satisfied with gcc.

-Barry



From fdrake at cnri.reston.va.us  Thu Apr 22 17:42:57 1999
From: fdrake at cnri.reston.va.us (Fred L. Drake)
Date: Thu, 22 Apr 1999 11:42:57 -0400 (EDT)
Subject: [Python-Dev] Notice of intent: rich comparisons
In-Reply-To: <14111.16970.839894.147748@anthem.cnri.reston.va.us>
References: <16290078@toto.iv>
	<14111.13959.211874.750734@weyr.cnri.reston.va.us>
	<14111.16970.839894.147748@anthem.cnri.reston.va.us>
Message-ID: <14111.17281.999490.718527@weyr.cnri.reston.va.us>

Barry A. Warsaw writes:
 > There might be, but the bundled compiler in SunOS 4 was never intended 
 > to be used for anything more than recompiling the kernel.  Years ago,
...
 > SunOS 4 users can probably be mostly satisfied with gcc.

Barry,
  This is good enough for me.  I'd certainly rather avoid K&R C!


  -Fred

--
Fred L. Drake, Jr.	     <fdrake at acm.org>
Corporation for National Research Initiatives



From skip at mojam.com  Thu Apr 22 19:18:39 1999
From: skip at mojam.com (skip at mojam.com)
Date: Thu, 22 Apr 1999 13:18:39 -0400 (EDT)
Subject: [Python-Dev] Notice of intent: rich comparisons
In-Reply-To: <14111.17281.999490.718527@weyr.cnri.reston.va.us>
References: <16290078@toto.iv>
	<14111.13959.211874.750734@weyr.cnri.reston.va.us>
	<14111.16970.839894.147748@anthem.cnri.reston.va.us>
	<14111.17281.999490.718527@weyr.cnri.reston.va.us>
Message-ID: <14111.22873.161727.15206@cm-29-94-14.nycap.rr.com>

    Barry> SunOS 4 users can probably be mostly satisfied with gcc.

    Fred>  This is good enough for me.  I'd certainly rather avoid K&R C!

Besides, aren't there tools available that can strip most of the ANSI-ness
out of ANSI C?  (Un)Protoize?  For those (few?) people who are really still
stuck using a K&R compiler I would think those tools, perhaps supplemented
with some patch files maintained outside the main Python source tree, would
be sufficient.

Skip Montanaro	| Mojam: "Uniting the World of Music" http://www.mojam.com/
skip at mojam.com  | Musi-Cal: http://www.musi-cal.com/
518-372-5583



From bwarsaw at cnri.reston.va.us  Thu Apr 22 20:07:57 1999
From: bwarsaw at cnri.reston.va.us (Barry A. Warsaw)
Date: Thu, 22 Apr 1999 14:07:57 -0400 (EDT)
Subject: [Python-Dev] Notice of intent: rich comparisons
References: <16290078@toto.iv>
	<14111.13959.211874.750734@weyr.cnri.reston.va.us>
	<14111.16970.839894.147748@anthem.cnri.reston.va.us>
	<14111.17281.999490.718527@weyr.cnri.reston.va.us>
	<14111.22873.161727.15206@cm-29-94-14.nycap.rr.com>
Message-ID: <14111.25981.74738.355264@anthem.cnri.reston.va.us>

>>>>> "skip" ==   <skip at mojam.com> writes:

    skip> Besides, aren't there tools available that can strip most of
    skip> the ANSI-ness out of ANSI C?  (Un)Protoize?

I think so.  Seems I have unprotoize already; probably got it for free
with gcc, or some other GNU tool.

-B



From skip at mojam.com  Thu Apr 22 20:22:51 1999
From: skip at mojam.com (skip at mojam.com)
Date: Thu, 22 Apr 1999 14:22:51 -0400 (EDT)
Subject: [Python-Dev] Notice of intent: rich comparisons
In-Reply-To: <371E4746.22A84506@lemburg.com>
References: <Pine.WNT.4.04.9904211142330.174-100000@rigoletto.ski.org>
	<199904211904.PAA14966@eric.cnri.reston.va.us>
	<371E4746.22A84506@lemburg.com>
Message-ID: <14111.23085.737365.582406@cm-29-94-14.nycap.rr.com>

    mal> There's some good work out there by Skip Montanaro to revamp the VM
    mal> into a combined register/stack machine. He calls it rattlesnake.
    mal> More infos can be found in the list archive (it's currently
    mal> sleeping):

Thanks to Marc-Andre for mentioning this.  Rattlesnake is indeed sleeping at
the moment.  If anyone is interested in the idea I'd be happy to awaken it.

The main observation was that much of the virtual machine's activity is
pushing/popping objects to/from the stack.  By treating a chunk of storage
as a register file much of that churn can be avoided.

Skip Montanaro	| Mojam: "Uniting the World of Music" http://www.mojam.com/
skip at mojam.com  | Musi-Cal: http://www.musi-cal.com/
518-372-5583



From fredrik at pythonware.com  Fri Apr 23 09:48:14 1999
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Fri, 23 Apr 1999 09:48:14 +0200
Subject: [Python-Dev] Compiling ANSI C on K&R compilers
References: <16290078@toto.iv><14111.13959.211874.750734@weyr.cnri.reston.va.us><14111.16970.839894.147748@anthem.cnri.reston.va.us><14111.17281.999490.718527@weyr.cnri.reston.va.us> <14111.22873.161727.15206@cm-29-94-14.nycap.rr.com>
Message-ID: <00df01be8d5d$a82b2f70$f29b12c2@pythonware.com>

> Besides, aren't there tools available that can strip most of the ANSI-ness
> out of ANSI C?  (Un)Protoize?  For those (few?) people who are really still
> stuck using a K&R compiler I would think those tools, perhaps supplemented
> with some patch files maintained outside the main Python source tree, would
> be sufficient.

I mentioned ansi2knr.c in an earlier post.  It's a small utility,
and can be distributed with the Python core (it's GPL'd, but
since it isn't linked with Python, that's not a problem).

this is used by ghostscript and the ijg jpeg library, among
others:

ftp://ftp.cs.wisc.edu/ghost/ansi2knr.c
(or via http://www.cs.wisc.edu/~ghost/)

Cheers /F
fredrik at pythonware.com
http://www.pythonware.com




From gstein at lyra.org  Fri Apr 23 12:37:02 1999
From: gstein at lyra.org (Greg Stein)
Date: Fri, 23 Apr 1999 03:37:02 -0700
Subject: [Python-Dev] Notice of intent: rich comparisons
References: <Pine.WNT.4.04.9904211142330.174-100000@rigoletto.ski.org> <199904211904.PAA14966@eric.cnri.reston.va.us>
Message-ID: <37204D4E.2C02ABE2@lyra.org>

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/



From fdrake at cnri.reston.va.us  Fri Apr 23 15:28:12 1999
From: fdrake at cnri.reston.va.us (Fred L. Drake)
Date: Fri, 23 Apr 1999 09:28:12 -0400 (EDT)
Subject: [Python-Dev] Notice of intent: rich comparisons
In-Reply-To: <37204D4E.2C02ABE2@lyra.org>
References: <Pine.WNT.4.04.9904211142330.174-100000@rigoletto.ski.org>
	<199904211904.PAA14966@eric.cnri.reston.va.us>
	<37204D4E.2C02ABE2@lyra.org>
Message-ID: <14112.30060.552422.975547@weyr.cnri.reston.va.us>

Greg Stein writes:
 > 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)

  The Doc/ stuff is already in a separate distribution; this has been
in place for about a year (if I recall correctly).  I try to make doc
releases shortly after Python releases (I think the 1.5.2 doc release
is the longest I've waited past the Python release so far, and it may
end up being next week), and I have made interim releases as the
documentation has grown.
  I certainly think that doing something similar for the Demo/ and
Tools/ directories would be reasonable; they could share a single
distribution.


  -Fred

--
Fred L. Drake, Jr.	     <fdrake at acm.org>
Corporation for National Research Initiatives



From skip at mojam.com  Fri Apr 23 15:59:02 1999
From: skip at mojam.com (skip at mojam.com)
Date: Fri, 23 Apr 1999 09:59:02 -0400 (EDT)
Subject: [Python-Dev] Notice of intent: rich comparisons
In-Reply-To: <14112.30060.552422.975547@weyr.cnri.reston.va.us>
References: <Pine.WNT.4.04.9904211142330.174-100000@rigoletto.ski.org>
	<199904211904.PAA14966@eric.cnri.reston.va.us>
	<37204D4E.2C02ABE2@lyra.org>
	<14112.30060.552422.975547@weyr.cnri.reston.va.us>
Message-ID: <14112.31858.374462.469793@cm-29-94-14.nycap.rr.com>

    Fred> I certainly think that doing something similar for the Demo/ and
    Fred> Tools/ directories would be reasonable; they could share a single
    Fred> distribution.

We need to make sure none of the tools are needed in the install
process. h2py comes to mind.

Skip Montanaro	| Mojam: "Uniting the World of Music" http://www.mojam.com/
skip at mojam.com  | Musi-Cal: http://www.musi-cal.com/
518-372-5583



From jeremy at cnri.reston.va.us  Mon Apr 26 17:26:28 1999
From: jeremy at cnri.reston.va.us (Jeremy Hylton)
Date: Mon, 26 Apr 1999 11:26:28 -0400 (EDT)
Subject: [Python-Dev] Notice of intent: rich comparisons
In-Reply-To: <37204D4E.2C02ABE2@lyra.org>
References: <Pine.WNT.4.04.9904211142330.174-100000@rigoletto.ski.org>
	<199904211904.PAA14966@eric.cnri.reston.va.us>
	<37204D4E.2C02ABE2@lyra.org>
Message-ID: <14116.33341.371508.53071@bitdiddle.cnri.reston.va.us>

>>>>> "GS" == Greg Stein <gstein at lyra.org> writes:

  >> Greg Stein's new httplib.py (or Jeremy's?)

  GS> Mine is a drop-in replacement for the current
  GS> httplib.py. httplib.HTTP is compatible with the current version
  GS> and does HTTP/1.0.  httplib.HTTPConnection is similar to the
  GS> other (but (IMO) cleans up a few elements of the API); it does
  GS> HTTP/1.1, including persistent connections. This module follows
  GS> the design of the original httplib.py much more
  GS> closely. Jeremy's module uses a very different design approach
  GS> (no value judgement here; it's just different); also, it simply
  GS> copies over the old HTTP class, while mine derives the
  GS> compatible version from HTTPConnection. I'm not sure how much
  GS> testing Jeremy's has had, but I use my module for all
  GS> Python-based http work now. Some number of other people have
  GS> downloaded and used it, too.

  GS> I would recommend my new module, given the two options.

I think I agree.  I stopped working on my version quite some time ago, 
before I made enough progress to make it useful.  Thus, it makes a lot 
of sense to use Greg's working code.

I'd be curious to see how to use HTTPConnection to do persistent
connections and pipelined requests.  It wasn't entirely clear from the 
code what I would need to do to keep the connection open.  Do you just
re-use the HTTPConnection object -- call putrequest again after
getreply? 

I like the revised API that Greg's code uses.  The request method on
HTTPConnection objects cleans the API up in exactly the right way.  It 
has always seemed unnecessary to have many separate calls to add
headers and then a call to endheaders after putrequest.  Packaging
them all together in one method will simplify client code a lot.

  GS> I'll eventually have a davlib.py to add to the distribution, but
  GS> it needs more work. I'll contribute that later.

Cool!

Jeremy




From guido at CNRI.Reston.VA.US  Mon Apr 26 18:16:11 1999
From: guido at CNRI.Reston.VA.US (Guido van Rossum)
Date: Mon, 26 Apr 1999 12:16:11 -0400
Subject: [Python-Dev] Public or private python-dev archives?
Message-ID: <199904261616.MAA22036@eric.cnri.reston.va.us>

In a private mail, Greg Stein suggested that the python-dev archives
should be restricted to the members of the list.  I prefer to make
them public, but I won't want to impose this on others without
discussion.  So I've made the archives private for the time being
while we discuss this meta-issue.  (Also, the existence of the list
isn't announced by mailman on its listinfo page.)

Here's my argument for open archives.  I don't think that we have
anything to hide from the public -- I think of us as a technical forum
whose discussions may affect others (e.g. Python users) and I think
it's often useful for those others to be able to see what we've said.

I want to keep membership of the list closed as a gentle way to
enforce focus and quality of discussion.

Jeremy pointed out that there's no restiction on posting, and
mentioned that together with open archives this makes the list just as
open as an open-subscription list.  I don't see this equivalence --
certainly it makes a difference in practice, and the open posting is
simply a mechanism to allow members with multiple email addresses to
post from whereever they are.  If we regularly get spammed or find the 
list is targeted by angry Python users we might have to restrict
posting to members (and deal with the multiple address problem).

I hope the discussion about this issue will be short (otherwise it
would detract from the real goal of this list).  I'll follow the
desire of the majority of current members; once we have a decision I
propose to stick with it and simply present new members with the
facts.

--Guido van Rossum (home page: http://www.python.org/~guido/)



From gward at cnri.reston.va.us  Mon Apr 26 18:30:43 1999
From: gward at cnri.reston.va.us (Greg Ward)
Date: Mon, 26 Apr 1999 12:30:43 -0400
Subject: [Python-Dev] Public or private python-dev archives?
In-Reply-To: <199904261616.MAA22036@eric.cnri.reston.va.us>; from Guido van Rossum on Mon, Apr 26, 1999 at 12:16:11PM -0400
References: <199904261616.MAA22036@eric.cnri.reston.va.us>
Message-ID: <19990426123042.A2617@cnri.reston.va.us>

On 26 April 1999, Guido van Rossum said:
> In a private mail, Greg Stein suggested that the python-dev archives
> should be restricted to the members of the list.  I prefer to make
> them public, but I won't want to impose this on others without
> discussion.  So I've made the archives private for the time being
> while we discuss this meta-issue.  (Also, the existence of the list
> isn't announced by mailman on its listinfo page.)
> 
> Here's my argument for open archives.  I don't think that we have
> anything to hide from the public -- I think of us as a technical forum
> whose discussions may affect others (e.g. Python users) and I think
> it's often useful for those others to be able to see what we've said.

I favour as much openness as possible that's consistent with high
signal-to-noise.  Opening the archives doesn't affect SN ratio; for that
matter, neither does allowing anyone to *read* the list while keeping
posting privileges restricted.  And letting the world know that the list
exists -- even though posting privileges are restricted -- shouldn't
affect quality.

So I guess my position is: definitely open the archives and publicise
the list -- the benefit of an open archive is reduced if people can't
stumble across it like they can any sig.  And consider the possibility
of open subscription while keeping posting restricted.  Not sure how
easy that is with Mailman, but we can still consider the idea.

The open, friendly nature of the Python community is a huge strength.  I
tentatively agree that posting privileges should be restricted to keep
quality high, but the idea of a "secret cabal" discussing Python
development off in a dark corner away from the grubby masses seems very
counter to the spirit I've seen so far.

        Greg
-- 
Greg Ward - software developer                    gward at cnri.reston.va.us
Corporation for National Research Initiatives    
1895 Preston White Drive                           voice: +1-703-620-8990
Reston, Virginia, USA  20191-5434                    fax: +1-703-620-0913



From da at ski.org  Mon Apr 26 18:29:56 1999
From: da at ski.org (David Ascher)
Date: Mon, 26 Apr 1999 09:29:56 -0700 (Pacific Daylight Time)
Subject: [Python-Dev] Public or private python-dev archives?
In-Reply-To: <199904261616.MAA22036@eric.cnri.reston.va.us>
Message-ID: <Pine.WNT.4.04.9904260922170.273-100000@rigoletto.ski.org>

On Mon, 26 Apr 1999, Guido van Rossum wrote:

> In a private mail, Greg Stein suggested that the python-dev archives
> should be restricted to the members of the list.  I prefer to make
> them public, but I won't want to impose this on others without
> discussion.  So I've made the archives private for the time being
> while we discuss this meta-issue.  (Also, the existence of the list
> isn't announced by mailman on its listinfo page.)

If one has a public archive with restricted membership, then one needs to
have a process for people to petition membership, including policies on
deciding admission (which could be as vague as "up to GvR's whim").

FWIW, the perl5-porters list is open but the perl6-porters list is closed.

My suggestion is that we can start with an open policy on archives, and
the lax posting policy for the multiple email address business (which
should be incorporated in mailman++ =), with the explicitely stated caveat
that if it turns out that that policy doesn't work, we reserve the right
to tighten things up. I also suggest that we don't advertise the fact that
anyone can post.  [Except of course that we've just mentioned this in
archives which I'm arguing should be public =)]

--david





From bwarsaw at cnri.reston.va.us  Mon Apr 26 19:44:36 1999
From: bwarsaw at cnri.reston.va.us (Barry A. Warsaw)
Date: Mon, 26 Apr 1999 13:44:36 -0400 (EDT)
Subject: [Python-Dev] Public or private python-dev archives?
References: <199904261616.MAA22036@eric.cnri.reston.va.us>
	<19990426123042.A2617@cnri.reston.va.us>
Message-ID: <14116.42500.284907.569281@anthem.cnri.reston.va.us>

>>>>> "GW" == Greg Ward <gward at cnri.reston.va.us> writes:

    GW> And consider the possibility of open subscription while
    GW> keeping posting restricted.  Not sure how easy that is with
    GW> Mailman, but we can still consider the idea.

It could be done in a number of ways.  You could restrict postings to
members only, but as Guido has pointed out, a lot of people post from
more than one account and Mailman doesn't handle that very well yet.
Or you could moderate the list, but then someone has to approve
postings and that's more work than I think anybody wants to do.

I'm also for an open-as-possible policy, with the right to restrict
later if the s/n gets too low.  I sort of view Python-dev to be the
place that serious c.l.py proposals get fleshed out and implementation 
strategies discussed.  The (hopefully) high level of technical detail
on the list should self-select.

-Barry



From gmcm at hypernet.com  Mon Apr 26 20:56:52 1999
From: gmcm at hypernet.com (Gordon McMillan)
Date: Mon, 26 Apr 1999 13:56:52 -0500
Subject: [Python-Dev] Public or private python-dev archives?
In-Reply-To: <14116.42500.284907.569281@anthem.cnri.reston.va.us>
Message-ID: <1286969269-56980208@hypernet.com>

[Barry]
> The (hopefully) high level of
> technical detail on the list should self-select.

I thought the humor did that.

If the public-archive were only updated weekly, it would make it's 
use (or abuse) as glorified help list pretty tenuous.

No one has espoused Greg's reasoning. In the abscense of 
said arguments, I'm certainly inclined to vote for "as public as can 
be and still be focused".

-OTOH-then-I'll-never-know-what-goes-on-in-the-smoke-filled-room-ly 
y'rs

- Gordon



From da at ski.org  Mon Apr 26 21:12:54 1999
From: da at ski.org (David Ascher)
Date: Mon, 26 Apr 1999 12:12:54 -0700 (Pacific Daylight Time)
Subject: [Python-Dev] Why unbundle Tools and Demo?
Message-ID: <Pine.WNT.4.04.9904261203430.59-100000@rigoletto.ski.org>

Several people argue for unbundling Tools/ and Demo/ in 1.6.  I'd like to
argue to leave them in.  They're not especially big, and IMHO they are
quite valuable, *especially* to the novice user.  In fact, I'd like to
argue that Demo/ should be promoted to the same status as Tools/ (by which
I mean included in the Windows binary distribution). Unbundling Tools/
would mean unbundling IDLE, which IMHO would be a big strategic mistake.

However, I wouldn't be against a cleanup of said directories.  Some things
should probably be removed (anything which uses stdwin), some of the code
in classes is showing its age (notes about "being upgraded for Python 1.1"
=), etc.  That said, the tkinter/ directory is the best place to look for
simple Tkinter code, and should be included, IMHO.

--david











From guido at CNRI.Reston.VA.US  Mon Apr 26 21:20:26 1999
From: guido at CNRI.Reston.VA.US (Guido van Rossum)
Date: Mon, 26 Apr 1999 15:20:26 -0400
Subject: [Python-Dev] Why unbundle Tools and Demo?
In-Reply-To: Your message of "Mon, 26 Apr 1999 12:12:54 PDT."
             <Pine.WNT.4.04.9904261203430.59-100000@rigoletto.ski.org> 
References: <Pine.WNT.4.04.9904261203430.59-100000@rigoletto.ski.org> 
Message-ID: <199904261920.PAA22415@eric.cnri.reston.va.us>

> Several people argue for unbundling Tools/ and Demo/ in 1.6.  I'd like to
> argue to leave them in.  They're not especially big, and IMHO they are
> quite valuable, *especially* to the novice user.  In fact, I'd like to
> argue that Demo/ should be promoted to the same status as Tools/ (by which
> I mean included in the Windows binary distribution). Unbundling Tools/
> would mean unbundling IDLE, which IMHO would be a big strategic mistake.
> 
> However, I wouldn't be against a cleanup of said directories.  Some things
> should probably be removed (anything which uses stdwin), some of the code
> in classes is showing its age (notes about "being upgraded for Python 1.1"
> =), etc.  That said, the tkinter/ directory is the best place to look for
> simple Tkinter code, and should be included, IMHO.

Agreed.  One simple thing that would help me immensely would be for
someone to go through all the various Demo directories and make an
inventary of what is there and how useful it is, (1) to all Python
users, (2) to Windows users.  Then, perhaps someone could write a
simple document making these files (and Tools) more accessible...

--Guido van Rossum (home page: http://www.python.org/~guido/)



From da at ski.org  Mon Apr 26 21:20:40 1999
From: da at ski.org (David Ascher)
Date: Mon, 26 Apr 1999 12:20:40 -0700 (Pacific Daylight Time)
Subject: [Python-Dev] Why unbundle Tools and Demo?
In-Reply-To: <199904261920.PAA22415@eric.cnri.reston.va.us>
Message-ID: <Pine.WNT.4.04.9904261220200.59-100000@rigoletto.ski.org>

> someone to go through all the various Demo directories and make an
> inventary of what is there and how useful it is, (1) to all Python
> users, (2) to Windows users.  Then, perhaps someone could write a
> simple document making these files (and Tools) more accessible...

Ok.  I can do that.






From guido at CNRI.Reston.VA.US  Mon Apr 26 21:22:55 1999
From: guido at CNRI.Reston.VA.US (Guido van Rossum)
Date: Mon, 26 Apr 1999 15:22:55 -0400
Subject: [Python-Dev] Why unbundle Tools and Demo?
In-Reply-To: Your message of "Mon, 26 Apr 1999 12:20:40 PDT."
             <Pine.WNT.4.04.9904261220200.59-100000@rigoletto.ski.org> 
References: <Pine.WNT.4.04.9904261220200.59-100000@rigoletto.ski.org> 
Message-ID: <199904261922.PAA22447@eric.cnri.reston.va.us>

[me]
> > someone to go through all the various Demo directories and make an
> > inventary of what is there and how useful it is, (1) to all Python
> > users, (2) to Windows users.  Then, perhaps someone could write a
> > simple document making these files (and Tools) more accessible...

[Dave]
> Ok.  I can do that.

Great!  I didn't mean to volunteer you -- but I think you'd do a great 
job.

--Guido van Rossum (home page: http://www.python.org/~guido/)



From tim_one at email.msn.com  Tue Apr 27 06:25:19 1999
From: tim_one at email.msn.com (Tim Peters)
Date: Tue, 27 Apr 1999 00:25:19 -0400
Subject: [Python-Dev] Public or private python-dev archives?
In-Reply-To: <19990426123042.A2617@cnri.reston.va.us>
Message-ID: <000501be9065$f5e3db80$ab9e2299@tim>

[Greg Ward, arguing in favor of
    ...
    a "secret cabal" discussing Python development off in a dark corner
    away from the grubby masses
]

That's what I'd like too -- but somebody already let Gordon in <wink>.

voting-to-leave-it-public-until-there's-a-problem-ly y'rs  - tim





From da at ski.org  Tue Apr 27 21:23:55 1999
From: da at ski.org (David Ascher)
Date: Tue, 27 Apr 1999 12:23:55 -0700 (Pacific Daylight Time)
Subject: [Python-Dev] numpy
Message-ID: <Pine.WNT.4.04.9904271220520.64-100000@rigoletto.ski.org>

What are the thoughts on NumPy integration into the core?

--David




From MHammond at skippinet.com.au  Wed Apr 28 01:28:59 1999
From: MHammond at skippinet.com.au (Mark Hammond)
Date: Wed, 28 Apr 1999 09:28:59 +1000
Subject: [Python-Dev] numpy
In-Reply-To: <Pine.WNT.4.04.9904271220520.64-100000@rigoletto.ski.org>
Message-ID: <001c01be9105$bae7ccd0$0801a8c0@bobcat>

> What are the thoughts on NumPy integration into the core?

he he - and while we are at it :-)  mxDateTime would need to be a popular
choice for inclusion, and Guido has offered in-principle support for moving
some of the Win32 stuff into the core - particularly the Registry stuff and
the native Window Handle support...

How far do we go :-)

Personally, I would simply like to see the distutils SIG solve this problem
for us.  (sure).  Eg, the "build" or "install" process (depending on the
OS) could build a local HTML file with knowledge many "common" extensions -
a single click, and it is downloaded, configured and built.   Oh well, back
to reality...

[Which isnt to say I am opposed to NumPy and mxDateTime.  Definately keen
on the win32 stuff tho :-]

Mark.




From da at ski.org  Wed Apr 28 01:31:56 1999
From: da at ski.org (David Ascher)
Date: Tue, 27 Apr 1999 16:31:56 -0700 (Pacific Daylight Time)
Subject: [Python-Dev] numpy
In-Reply-To: <001c01be9105$bae7ccd0$0801a8c0@bobcat>
Message-ID: <Pine.WNT.4.04.9904271628320.64-100000@rigoletto.ski.org>

On Wed, 28 Apr 1999, Mark Hammond wrote:

> > What are the thoughts on NumPy integration into the core?
> 
> he he - and while we are at it :-)  mxDateTime would need to be a popular
> choice for inclusion, and Guido has offered in-principle support for moving
> some of the Win32 stuff into the core - particularly the Registry stuff and
> the native Window Handle support...

It may seem strange, but I'll argue for the win32 registry calls before
the NumPy stuff.  That could be because I've looked at NumPy code and not
the win32 code.  Not Jim's cleanest code. =)

Mark, can you describe 'native Window Handle' support?

--david





From MHammond at skippinet.com.au  Wed Apr 28 07:03:48 1999
From: MHammond at skippinet.com.au (Mark Hammond)
Date: Wed, 28 Apr 1999 15:03:48 +1000
Subject: [Python-Dev] numpy
In-Reply-To: <Pine.WNT.4.04.9904271628320.64-100000@rigoletto.ski.org>
Message-ID: <001e01be9134$809ca8f0$0801a8c0@bobcat>

> It may seem strange, but I'll argue for the win32 registry
> calls before
> the NumPy stuff.  That could be because I've looked at NumPy
> code and not
> the win32 code.  Not Jim's cleanest code. =)

he he - and I can even get out of the Win32 stuff - I wrote a string-only
first version, and Bill Tutt rehashed it into what it is today, handling
all the registry types.

OTOH, there could also be a case for moving "win32api" completely to "core
status" (whether that means truly core or simply a standard .pyd).  For
example, ntpath.py now has code that attempts to use
"win32api.GetFullPathName()".

The down-side is that win32api has nowhere near complete coverage, and is
really a mixed bag of bits and pieces.  Most later efforts where complete
API sets are given coverage have different names - eg, win32file has the
complete Win32 file API wrapped up - even if there are overlaps with
existing functions in win32api.

Im not sure what the answer is - my guess is a new core module with Win32
features deemed absolutely necessary for the core - stuff like the
registry, and a few assorted other functions, such as GetFullPathName, but
stopping well short of the full win32api set.

> Mark, can you describe 'native Window Handle' support?

Sure!  We have a very light-weight "handle" object, representing a Win32
handle.  It has no methods, and a single property for returning the
underlying win32 handle as an integer.  When the object destructs, it calls
"CloseHandle()".  Thats about it!

It has no methods, so is passed as an argument.  There has been no attempt
to implement things like "handle.Read()" to represent "ReadFile(handle,
...)".  There are 2 reasons for this:
1) Handles are fairly general purpose, and not restricted to IO operations.
A handle is also used to represent a Mutex/Semaphores and
threads/processes - certainly doesnt make sense to have a "Read()" method
for those handles.
2) IMO, this should be done at the .py level anyway.  The Win32 Handle
support is pure C++ at the moment.

A simple complication is that there are 3 types of handles in use at the
moment - those that call "CloseHandle", those that call "RegCloseHandle"
(registry handles) and a 3rd I cant recall.  This is currently implemented
using C++ inheritance.  But even if the current implementation is not
favoured, the object is so small that a rewrite would not be a problem.

And for those that can be bothered to read this far, some more background:
Some time ago, Greg and I decided to implement a "pywintypes" module.  This
defines what we considered "core types" for the Win32 world.  All our
extension modules (including win32api, COM; basically win32*.pyd) use this
module.  The objects it supports are: Unicode, Handles, Win32 Time, IIDs,
Overlapped IO objects, 3 NT security related objects and importantly a
standard Win32 exception and functions for filling it.

Moving the registry stuff is dependant on the core having the Exception,
Handle and Registry support (hence this discussion).  We have our own Time
object, but mxDateTime would be fine.  One day, we hope to remove this
pywintypes entirely, as the core will have it all :-)

Mark.




From gward at cnri.reston.va.us  Wed Apr 28 14:51:43 1999
From: gward at cnri.reston.va.us (Greg Ward)
Date: Wed, 28 Apr 1999 08:51:43 -0400
Subject: [Python-Dev] numpy
In-Reply-To: <001c01be9105$bae7ccd0$0801a8c0@bobcat>; from Mark Hammond on Wed, Apr 28, 1999 at 09:28:59AM +1000
References: <Pine.WNT.4.04.9904271220520.64-100000@rigoletto.ski.org> <001c01be9105$bae7ccd0$0801a8c0@bobcat>
Message-ID: <19990428085143.A5571@cnri.reston.va.us>

On 28 April 1999, Mark Hammond said:
> How far do we go :-)
> 
> Personally, I would simply like to see the distutils SIG solve this problem
> for us.  (sure).  Eg, the "build" or "install" process (depending on the
> OS) could build a local HTML file with knowledge many "common" extensions -
> a single click, and it is downloaded, configured and built.   Oh well, back
> to reality...

It's not impossible, it just takes a while.  I think it took the Perl
community about three years to go from "hey! let's have a standard build
mechanism for modules!" to the point where I can install (almost) any
module from CPAN with one shell command:

  perl -MCPAN -e 'install ("MIME::Base64");'

which is insanely cool.  (It took about two minutes to do the above just
now; that included trying two CPAN mirrors that aren't being cooperative
this morning, finding one that was working, downloading the current
module list from it, determining that there is a more recent version
available than the one installed here, downloading it, unpacking it,
running "Makefile.PL" to generate the Makefile, running "make" [which
compiles any extensions in the distribution, copies all the .pm files
around, and generates the documentation], "make test" [run the module's
self-test suite], and "make install" [install it in the "site-perl"
library directory].  Amount of user interaction required: typing the
above command line.)

It's *still* rough around the edges, though, especially when building a
new installation from scratch -- mainly because Perl doesn't ship with
ftp or http libraries, so the CPAN.pm module has to try downloading
stuff with lynx, ncftp, or plain ol' ftp until it has downloaded and
installed the libnet and libwww-perl distributions.  That's one problem
we won't have with Python, at least.  Oh yeah, and it all works *great*
under Unix... but the rest of the world lags behind.

Also, two major components of being able to do this -- the Perl Module
List and CPAN -- are still vapourware in Python-land.  But hey, if we
can get to the "we *have* a standard build mechanism for modules!"
point, then all the rest becomes a lot more feasible.

Pep talk over...

        Greg
-- 
Greg Ward - software developer                    gward at cnri.reston.va.us
Corporation for National Research Initiatives    
1895 Preston White Drive                           voice: +1-703-620-8990
Reston, Virginia, USA  20191-5434                    fax: +1-703-620-0913



From mal at lemburg.com  Wed Apr 28 09:44:25 1999
From: mal at lemburg.com (M.-A. Lemburg)
Date: Wed, 28 Apr 1999 09:44:25 +0200
Subject: [Python-Dev] numpy
References: <001c01be9105$bae7ccd0$0801a8c0@bobcat>
Message-ID: <3726BC59.35E3C9DB@lemburg.com>

Mark Hammond wrote:
> 
> > What are the thoughts on NumPy integration into the core?
> 
> he he - and while we are at it :-)  mxDateTime would need to be a popular
> choice for inclusion, and Guido has offered in-principle support for moving
> some of the Win32 stuff into the core - particularly the Registry stuff and
> the native Window Handle support...
> 
> How far do we go :-)
> 
> Personally, I would simply like to see the distutils SIG solve this problem
> for us.  (sure).  Eg, the "build" or "install" process (depending on the
> OS) could build a local HTML file with knowledge many "common" extensions -
> a single click, and it is downloaded, configured and built.   Oh well, back
> to reality...

You're talking about fast moving targets there... are you sure that
you want those in the standard distribution ?

Maybe we have two distributions: the standard one and a pro
edition with all the slick stuff included (together with a
proper setup script to get those references to external libs
and include files right).

Actually, this is something I've been wanting to do for nearly
a year now... just haven't found the time to really get things
the way I want them. It's a project called Python Power Tools
and includes many generic extensions (currently only ones that
don't rely on external libs).

If you're interested, have a look at an old version available at:

    http://starship.skyport.net/~lemburg/PowerTools-0.2.zip

It includes the extensions BTree, mxDateTime, mxTools, mxStack,
Trie, avl and kjbuckets. NumPy should probably also be included.
The current setup uses a recursive Makefile approach (not too
elegant, but works). A distutils setup would be much better.

-- 
Marc-Andre Lemburg                               Y2000: 247 days left
---------------------------------------------------------------------
          : Python Pages >>> http://starship.skyport.net/~lemburg/  :
           ---------------------------------------------------------





From jack at oratrix.nl  Wed Apr 28 15:48:21 1999
From: jack at oratrix.nl (Jack Jansen)
Date: Wed, 28 Apr 1999 15:48:21 +0200
Subject: [Python-Dev] numpy 
In-Reply-To: Message by "Mark Hammond" <MHammond@skippinet.com.au> ,
	     Wed, 28 Apr 1999 09:28:59 +1000 , <001c01be9105$bae7ccd0$0801a8c0@bobcat>
Message-ID: <19990428134821.E9A68300F57@snelboot.oratrix.nl>

> [...] Guido has offered in-principle support for moving
> some of the Win32 stuff into the core - particularly the Registry stuff and
> the native Window Handle support...

I think it would be nice to put all the stuff that is shared between modules 
(I think that's only PyWinTypes, but who am I to think I have a clue about the 
windows port:-) into the core.

I just did the same for MacPython, and it makes life a whole lot easier.
--
Jack Jansen             | ++++ stop the execution of Mumia Abu-Jamal ++++
Jack.Jansen at oratrix.com | ++++ if you agree copy these lines to your sig ++++
www.oratrix.nl/~jack    | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm 





From skip at mojam.com  Wed Apr 28 17:57:40 1999
From: skip at mojam.com (skip at mojam.com)
Date: Wed, 28 Apr 1999 11:57:40 -0400
Subject: [Python-Dev] LLNL C++ as base for Python 2?
Message-ID: <199904281557.LAA06491@cm-29-94-14.nycap.rr.com>

Have we been talking about Python 2 or Python 1.6?  If we're talking about
Python 2, has anyone given a serious look at the LLNL gang's C++/Python
stuff?  If I recall Paul Dubois' talk at the last conference, it sounded
like their work made it much easier to implement extension modules.

Skip Montanaro	| Mojam: "Uniting the World of Music" http://www.mojam.com/
skip at mojam.com  | Musi-Cal: http://www.musi-cal.com/
518-372-5583




From guido at CNRI.Reston.VA.US  Wed Apr 28 18:06:03 1999
From: guido at CNRI.Reston.VA.US (Guido van Rossum)
Date: Wed, 28 Apr 1999 12:06:03 -0400
Subject: [Python-Dev] LLNL C++ as base for Python 2?
In-Reply-To: Your message of "Wed, 28 Apr 1999 11:57:40 EDT."
             <199904281557.LAA06491@cm-29-94-14.nycap.rr.com> 
References: <199904281557.LAA06491@cm-29-94-14.nycap.rr.com> 
Message-ID: <199904281606.MAA27526@eric.cnri.reston.va.us>

> Have we been talking about Python 2 or Python 1.6?  If we're talking about
> Python 2, has anyone given a serious look at the LLNL gang's C++/Python
> stuff?  If I recall Paul Dubois' talk at the last conference, it sounded
> like their work made it much easier to implement extension modules.

I've mostly had 1.6 in mind.  See recent traffic in the C++ SIG
archives for the status of Paul's CXX.

--Guido van Rossum (home page: http://www.python.org/~guido/)



From da at ski.org  Wed Apr 28 19:24:00 1999
From: da at ski.org (David Ascher)
Date: Wed, 28 Apr 1999 10:24:00 -0700 (Pacific Daylight Time)
Subject: [Python-Dev] LLNL C++ as base for Python 2?
In-Reply-To: <199904281606.MAA27526@eric.cnri.reston.va.us>
Message-ID: <Pine.WNT.4.04.9904281021061.346-100000@rigoletto.ski.org>

On Wed, 28 Apr 1999, Guido van Rossum wrote:

> > Have we been talking about Python 2 or Python 1.6?  If we're talking about
> > Python 2, has anyone given a serious look at the LLNL gang's C++/Python
> > stuff?  If I recall Paul Dubois' talk at the last conference, it sounded
> > like their work made it much easier to implement extension modules.
> 
> I've mostly had 1.6 in mind.  See recent traffic in the C++ SIG
> archives for the status of Paul's CXX.

Recent traffic?  There's nothing in there that's substantive since... uh,
well, I got tired of looking back. =)

CXX is very cool, but it is still pushing the envelope of many C++
compilers.  From what I gather, recent egcs' do manage with it, and since
egcs is going to replace gcc, I expect that many platforms will be able to
"do" CXX relatively soon.

I vote to stay on the 1.6 track for now.




From MHammond at skippinet.com.au  Fri Apr 30 04:40:09 1999
From: MHammond at skippinet.com.au (Mark Hammond)
Date: Fri, 30 Apr 1999 12:40:09 +1000
Subject: [Python-Dev] More flexible namespaces.
Message-ID: <008d01be92b2$c56ef5d0$0801a8c0@bobcat>

Here is a bit of an idea that I first came up with some years ago.  Guido's
response at the time was "sounds reasonable as long as we dont slow the
normal case down".

To cut a long story short, I would like eval and exec to be capable of
working with arbitrary mapping objects rather than only dictionaries.  The
general idea is that I can provide a class with mapping semantics, and pass
this to exec/eval.

This would give us 2 seriously cool features (that I want <wink>), should
anyone decide to write code that enables them:

* Case insensitive namespaces.  This would be very cool for COM, and as far
as I know would please the Alice people.  May open up more embedding
opportunities that are lost if people feel strongly about this issue.

* Dynamic name lookups.  At the moment, dynamic attribute lookups are
simple, but dynamic name lookups are hard.  If I execute code "print foo",
foo _must_ pre-exist in the namespace.  There is no reasonable way I can
some up with so that I can fetch "foo" as it is requested (raising the
NameError if necessary).  This would also be very cool for some of the COM
work - particularly Active Scripting.

Of course, these would not be enabled by standard Python, but would allow
people to create flexible execution environments that suit their purpose.

Any comments on this?  Is it a dumb idea?  Anyone have a feel for how deep
these changes would cut?  Its not something I want to happen soon, but it
does seem a reasonable mechanism that can provide very flexible
solutions...

Mark.




From guido at CNRI.Reston.VA.US  Fri Apr 30 05:00:52 1999
From: guido at CNRI.Reston.VA.US (Guido van Rossum)
Date: Thu, 29 Apr 1999 23:00:52 -0400
Subject: [Python-Dev] More flexible namespaces.
In-Reply-To: Your message of "Fri, 30 Apr 1999 12:40:09 +1000."
             <008d01be92b2$c56ef5d0$0801a8c0@bobcat> 
References: <008d01be92b2$c56ef5d0$0801a8c0@bobcat> 
Message-ID: <199904300300.XAA00608@eric.cnri.reston.va.us>

> To cut a long story short, I would like eval and exec to be capable of
> working with arbitrary mapping objects rather than only dictionaries.  The
> general idea is that I can provide a class with mapping semantics, and pass
> this to exec/eval.

I agree that this would be seriously cool.  It will definitely be in
Python 2.0; it's already in JPython.

Quite a while ago, Ian Castleden sent me patches for 1.5.1 to do this.
It was a lot of code and I was indeed worried about slowing things
down too much (and also about checking that he got all the endcases
right).

Ian did benchmarks and found that the new code was consistently
slower, by 3-6%.  Perhaps for Python 1.6 this will be acceptable (the
"Python IS slow" thread notwithstanding :-); or perhaps someone can
have a look at it and squeeze some more time out of it?  I'll gladly
forward the patches.

--Guido van Rossum (home page: http://www.python.org/~guido/)



From da at ski.org  Fri Apr 30 05:21:04 1999
From: da at ski.org (David Ascher)
Date: Thu, 29 Apr 1999 20:21:04 -0700 (Pacific Daylight Time)
Subject: [Python-Dev] More flexible namespaces.
In-Reply-To: <199904300300.XAA00608@eric.cnri.reston.va.us>
Message-ID: <Pine.WNT.4.05.9904292018290.153-100000@david.ski.org>

> > To cut a long story short, I would like eval and exec to be capable of
> > working with arbitrary mapping objects rather than only dictionaries.  The
> > general idea is that I can provide a class with mapping semantics, and pass
> > this to exec/eval.
> 
> I agree that this would be seriously cool.  It will definitely be in
> Python 2.0; it's already in JPython.

Seriously cool is an understatement. 

--david




From MHammond at skippinet.com.au  Fri Apr 30 06:13:25 1999
From: MHammond at skippinet.com.au (Mark Hammond)
Date: Fri, 30 Apr 1999 14:13:25 +1000
Subject: [Python-Dev] More flexible namespaces.
In-Reply-To: <199904300300.XAA00608@eric.cnri.reston.va.us>
Message-ID: <009001be92bf$cb998f80$0801a8c0@bobcat>

> Ian did benchmarks and found that the new code was consistently
> slower, by 3-6%.  Perhaps for Python 1.6 this will be acceptable (the
> "Python IS slow" thread notwithstanding :-); or perhaps someone can

As long as we get someone working on a consistent 3-6% speedup in other
areas this wont be a problem :-)

I will attach it to my long list - but Im going to put all my efforts here
into Unicode first, and probably the threading stuff second :-)

Mark.




From tismer at appliedbiometrics.com  Fri Apr 30 09:49:42 1999
From: tismer at appliedbiometrics.com (Christian Tismer)
Date: Fri, 30 Apr 1999 09:49:42 +0200
Subject: [Python-Dev] More flexible namespaces.
References: <008d01be92b2$c56ef5d0$0801a8c0@bobcat> <199904300300.XAA00608@eric.cnri.reston.va.us>
Message-ID: <37296096.D0C9C2CC@appliedbiometrics.com>


Guido van Rossum wrote:
...
> Ian did benchmarks and found that the new code was consistently
> slower, by 3-6%.  Perhaps for Python 1.6 this will be acceptable (the
> "Python IS slow" thread notwithstanding :-); or perhaps someone can
> have a look at it and squeeze some more time out of it?  I'll gladly
> forward the patches.

I'd really like to look into that.
Also I wouldn't worry too much about speed, since this is 
such a cool feature. It might even be a speedup in some cases
which otherwise would need more complex handling.

May I have a look?

ciao - chris

-- 
Christian Tismer             :^)   <mailto:tismer at appliedbiometrics.com>
Applied Biometrics GmbH      :     Have a break! Take a ride on Python's
Kaiserin-Augusta-Allee 101   :    *Starship* http://starship.python.net
10553 Berlin                 :     PGP key -> http://wwwkeys.pgp.net
PGP Fingerprint       E182 71C7 1A9D 66E9 9D15  D3CC D4D7 93E2 1FAE F6DF
     we're tired of banana software - shipped green, ripens at home



From mal at lemburg.com  Fri Apr 30 10:22:46 1999
From: mal at lemburg.com (M.-A. Lemburg)
Date: Fri, 30 Apr 1999 10:22:46 +0200
Subject: [Python-Dev] More flexible namespaces.
References: <008d01be92b2$c56ef5d0$0801a8c0@bobcat>
Message-ID: <37296856.5875AAAF@lemburg.com>

Mark Hammond wrote:
> 
> Here is a bit of an idea that I first came up with some years ago.  Guido's
> response at the time was "sounds reasonable as long as we dont slow the
> normal case down".
> 
> To cut a long story short, I would like eval and exec to be capable of
> working with arbitrary mapping objects rather than only dictionaries.  The
> general idea is that I can provide a class with mapping semantics, and pass
> this to exec/eval.

This involves a whole lot of changes: not only in the Python core,
but also in extensions that rely on having real dictionaries available.

Since you put out to objectives, I'd like to propose a little
different approach...

1. Have eval/exec accept any mapping object as input

2. Make those two copy the content of the mapping object into real
   dictionaries

3. Provide a hook into the dictionary implementation that can be
   used to redirect KeyErrors and use that redirection to forward
   the request to the original mapping objects

> This would give us 2 seriously cool features (that I want <wink>), should
> anyone decide to write code that enables them:
> 
> * Case insensitive namespaces.  This would be very cool for COM, and as far
> as I know would please the Alice people.  May open up more embedding
> opportunities that are lost if people feel strongly about this issue.

This is covered by 1 and 2.

> * Dynamic name lookups.  At the moment, dynamic attribute lookups are
> simple, but dynamic name lookups are hard.  If I execute code "print foo",
> foo _must_ pre-exist in the namespace.  There is no reasonable way I can
> some up with so that I can fetch "foo" as it is requested (raising the
> NameError if necessary).  This would also be very cool for some of the COM
> work - particularly Active Scripting.

This is something for 3.

I guess it wouldn't cause any significant slow-down and can be
imlemented with much less code than the "change all PyDict_GetItem
to PyObject_GetItem" thingie.

The real thing could then be done for 2.0 where PyDict_Check()
would presumably not rely on an adress but some kind of inheritance
scheme indicating that the object is in fact a dictionary.

Cheers,
-- 
Marc-Andre Lemburg                               Y2000: 245 days left
---------------------------------------------------------------------
          : Python Pages >>> http://starship.skyport.net/~lemburg/  :
           ---------------------------------------------------------




From guido at CNRI.Reston.VA.US  Fri Apr 30 17:17:20 1999
From: guido at CNRI.Reston.VA.US (Guido van Rossum)
Date: Fri, 30 Apr 1999 11:17:20 -0400
Subject: [Python-Dev] More flexible namespaces.
In-Reply-To: Your message of "Fri, 30 Apr 1999 09:49:42 +0200."
             <37296096.D0C9C2CC@appliedbiometrics.com> 
References: <008d01be92b2$c56ef5d0$0801a8c0@bobcat> <199904300300.XAA00608@eric.cnri.reston.va.us>  
            <37296096.D0C9C2CC@appliedbiometrics.com> 
Message-ID: <199904301517.LAA01422@eric.cnri.reston.va.us>

> From: Christian Tismer <tismer at appliedbiometrics.com>

> I'd really like to look into that.
> Also I wouldn't worry too much about speed, since this is 
> such a cool feature. It might even be a speedup in some cases
> which otherwise would need more complex handling.
> 
> May I have a look?

Sure!

(I've forwarded Christian the files per separate mail.)

I'm also interested in your opinion on how well thought-out and robust
the patches are -- I've never found the time to do a good close
reading of them.

--Guido van Rossum (home page: http://www.python.org/~guido/)



From gmcm at hypernet.com  Fri Apr 30 18:32:30 1999
From: gmcm at hypernet.com (Gordon McMillan)
Date: Fri, 30 Apr 1999 11:32:30 -0500
Subject: [Python-Dev] More flexible namespaces.
In-Reply-To: <199904301517.LAA01422@eric.cnri.reston.va.us>
References: Your message of "Fri, 30 Apr 1999 09:49:42 +0200."             <37296096.D0C9C2CC@appliedbiometrics.com> 
Message-ID: <1286632328-77246936@hypernet.com>

Guido wrote:

> > From: Christian Tismer <tismer at appliedbiometrics.com>
> 
> > I'd really like to look into that.
> > Also I wouldn't worry too much about speed, since this is 
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > such a cool feature. It might even be a speedup in some cases
> > which otherwise would need more complex handling.
> > 
> > May I have a look?
> 
> Sure!
> 
> (I've forwarded Christian the files per separate mail.)

I don't know who you sent that to, but it couldn't possibly have been 
Christian!

- Gordon



From tismer at appliedbiometrics.com  Fri Apr 30 17:57:09 1999
From: tismer at appliedbiometrics.com (Christian Tismer)
Date: Fri, 30 Apr 1999 17:57:09 +0200
Subject: [Python-Dev] More flexible namespaces.
References: <008d01be92b2$c56ef5d0$0801a8c0@bobcat> <199904300300.XAA00608@eric.cnri.reston.va.us>  
	            <37296096.D0C9C2CC@appliedbiometrics.com> <199904301517.LAA01422@eric.cnri.reston.va.us>
Message-ID: <3729D2D5.6844D6DA@appliedbiometrics.com>


Guido van Rossum wrote:
> 
> > From: Christian Tismer <tismer at appliedbiometrics.com>
> > May I have a look?
> 
> Sure!
> 
> (I've forwarded Christian the files per separate mail.)

Thanks a lot! 

> I'm also interested in your opinion on how well thought-out and robust
> the patches are -- I've never found the time to do a good close
> reading of them.

Yes, it is quite long and not so very easy to digest.
At first glance, most of the changes are replacements of
dict access with mapping access where we pay for the extra
indirection.
It depends on how often this feature will really replace
dicts. If dicts are more common, I'd like to figure out
how much code bloat extra special casing for dicts would give.

Puha - thanks - chris

-- 
Christian Tismer             :^)   <mailto:tismer at appliedbiometrics.com>
Applied Biometrics GmbH      :     Have a break! Take a ride on Python's
Kaiserin-Augusta-Allee 101   :    *Starship* http://starship.python.net
10553 Berlin                 :     PGP key -> http://wwwkeys.pgp.net
PGP Fingerprint       E182 71C7 1A9D 66E9 9D15  D3CC D4D7 93E2 1FAE F6DF
     we're tired of banana software - shipped green, ripens at home



From tismer at appliedbiometrics.com  Fri Apr 30 18:19:57 1999
From: tismer at appliedbiometrics.com (Christian Tismer)
Date: Fri, 30 Apr 1999 18:19:57 +0200
Subject: [Python-Dev] More flexible namespaces.
References: Your message of "Fri, 30 Apr 1999 09:49:42 +0200."             <37296096.D0C9C2CC@appliedbiometrics.com> <1286632328-77246936@hypernet.com>
Message-ID: <3729D82D.CE16884@appliedbiometrics.com>


Gordon McMillan wrote:
> 
> Guido wrote:
> 
> > > From: Christian Tismer <tismer at appliedbiometrics.com>
> >
> > > I'd really like to look into that.
> > > Also I wouldn't worry too much about speed, since this is
>     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > > such a cool feature. It might even be a speedup in some cases
> > > which otherwise would need more complex handling.
> > >
> > > May I have a look?
> >
> > Sure!
> >
> > (I've forwarded Christian the files per separate mail.)
> 
> I don't know who you sent that to, but it couldn't possibly have been
> Christian!

:-) :-) truely not if I had'n other things in mind.

I know that I will not get more than 30-40 percent by compiling
the interpreter away, so I will not even spend time at a
register machine right now. Will also not follow the ideas of
P2C any longer, doesn't pay off.
Instead, If I can manage to create something like static binding
snapshots, then I could resolve many of the lookups and internal
method indirections, for time critical applications.
For all the rest, Python is pretty much fast enough.

I've begun to write s special platform dependant version
which allows me to do all the things which can't go into the dist.
For instance, I just saved some 10 percent by dynamically
patching some of the ParseTuple and BuildObject calls out of the
core code (ahem). I hope Python will stay as clean as it is,
allowing me to try all kinds of tricks for one machine class.

ciao - chris.speedy

-- 
Christian Tismer             :^)   <mailto:tismer at appliedbiometrics.com>
Applied Biometrics GmbH      :     Have a break! Take a ride on Python's
Kaiserin-Augusta-Allee 101   :    *Starship* http://starship.python.net
10553 Berlin                 :     PGP key -> http://wwwkeys.pgp.net
PGP Fingerprint       E182 71C7 1A9D 66E9 9D15  D3CC D4D7 93E2 1FAE F6DF
     we're tired of banana software - shipped green, ripens at home



From akuchlin at cnri.reston.va.us  Fri Apr 30 18:33:34 1999
From: akuchlin at cnri.reston.va.us (Andrew M. Kuchling)
Date: Fri, 30 Apr 1999 12:33:34 -0400 (EDT)
Subject: [Python-Dev] More flexible namespaces.
In-Reply-To: <3729D82D.CE16884@appliedbiometrics.com>
References: <37296096.D0C9C2CC@appliedbiometrics.com>
	<1286632328-77246936@hypernet.com>
	<3729D82D.CE16884@appliedbiometrics.com>
Message-ID: <14121.55659.754846.708467@amarok.cnri.reston.va.us>

Christian Tismer writes:
>Instead, If I can manage to create something like static binding
>snapshots, then I could resolve many of the lookups and internal
>method indirections, for time critical applications.

	The usual assumption is that the lookups are what takes time.
Now, are we sure of that assumption?  I'd expect the lookup code to be
like:

1) Get hash of name
2) Retrieve object from dictionary
3) Do something with the object.

Now, since string objects cache their hash value, 1) should usually be
just "if (obj->cached_hash_value!=-1) return obj->cached_hash_value";
a comparision and a return.  Step 2) should be very fast, barring a
bad hash function.  So perhaps most of the time is spent in 3),
creating new local dicts, stack frames, and what not.  (Yes, I know
that doing this on every reference to an object is part of the
problem.)  I also wonder about the costs of all the Py_BuildValue and
Py_ParseTuple calls going on under the hood.  A performance
improvement project would definitely be a good idea for 1.6, and a
good sub-topic for python-dev.

	Incidentally, what's the verdict on python-dev archives:
public or not?

-- 
A.M. Kuchling			http://starship.python.net/crew/amk/
Despair says little, and is patient.
    -- From SANDMAN: "Season of Mists", episode 0




From tismer at appliedbiometrics.com  Fri Apr 30 18:55:55 1999
From: tismer at appliedbiometrics.com (Christian Tismer)
Date: Fri, 30 Apr 1999 18:55:55 +0200
Subject: [Python-Dev] More flexible namespaces.
References: <37296096.D0C9C2CC@appliedbiometrics.com>
		<1286632328-77246936@hypernet.com>
		<3729D82D.CE16884@appliedbiometrics.com> <14121.55659.754846.708467@amarok.cnri.reston.va.us>
Message-ID: <3729E09B.5F65E3CA@appliedbiometrics.com>


"Andrew M. Kuchling" wrote:
> 
> Christian Tismer writes:
> >Instead, If I can manage to create something like static binding
> >snapshots, then I could resolve many of the lookups and internal
> >method indirections, for time critical applications.
> 
>         The usual assumption is that the lookups are what takes time.
> Now, are we sure of that assumption?  I'd expect the lookup code to be
> like:
> 
> 1) Get hash of name
> 2) Retrieve object from dictionary
> 3) Do something with the object.
...
Right, but when you become more restrictive, you can do
lots, lots more. If I also allow to fix the type of an object,
I can go under the hood of the Python API, so you could
add some points 4) 5) 6) here.
But I shouldn't have talked before I can show something.
And at the time, I don't restrict myself to write clean
code, but try very machine specific things which I
don't believe should go into Python at all.

> I also wonder about the costs of all the Py_BuildValue and
> Py_ParseTuple calls going on under the hood.  A performance
> improvement project would definitely be a good idea for 1.6, and a
> good sub-topic for python-dev.

I wasn't sure, so I first wrote a module which does statistics
on that, and I found a lot of these calls. Some are even 
involved in ceval's code, where things like "(OOOO)" is parsed
all over again and again. Now I think this is ok in most cases.
But in some places these are very bad: If your builtin function
soes so very few work. 
Take len(): This uses ParseTuple, which calls a function to
find out its object, then calls a function to get the object,
then takes the len, and builds the result. But since everything
has a length, checking for no NULL pointer and grabbing the len
produces even shorter code. This applies to many places as well.
But right now, I don't change the core, but build hacky little
extension modules which squeak such things out at runtime.
No big deal yet, but maybe it could pay off to introduce
format strings which make them more suitableto be used
in macro substitutions.

sorry if I was too elaborate, this is so much fun :-)

ciao - chris

-- 
Christian Tismer             :^)   <mailto:tismer at appliedbiometrics.com>
Applied Biometrics GmbH      :     Have a break! Take a ride on Python's
Kaiserin-Augusta-Allee 101   :    *Starship* http://starship.python.net
10553 Berlin                 :     PGP key -> http://wwwkeys.pgp.net
PGP Fingerprint       E182 71C7 1A9D 66E9 9D15  D3CC D4D7 93E2 1FAE F6DF
     we're tired of banana software - shipped green, ripens at home