From guido@python.org  Sun Oct  1 06:31:43 2000
From: guido@python.org (Guido van Rossum)
Date: Sun, 01 Oct 2000 00:31:43 -0500
Subject: [Python-Dev] Release candidate followed by feature freeze?
Message-ID: <200010010531.AAA15697@cj20424-a.reston1.va.home.com>

I'm considering to issue a release candidate before the final 2.0
release.  I'd like to poll opinions about this (we haven't had a
PythonLabs group meeting about this yet).

The importance of a release candidate (RC) is twofold: we announce it
widely so it (hopefully) gets a lot of testing -- necessary since a
lot of things have changed again since beta2; and we impose a checkin
stop once the RC is out, with exceptions only allowed by the release
manager to fix showstopper bugs found in the RC.

This will hopefully avoid a disaster like we had with the buggy
last-minute changes in beta2 (for which I take full responsibility).

If the idea of a RC sounds okay, I'd like to propose to release it on
October 5.  The final release would still be on October 10, or perhaps
1-2 days later.  Much less than a week between the RC and the final
release is not good because it doesn't give testers enough time to try
out the RC; much more than a week is bad because the developers get
antsy when they can't check in their changes!

This means that any current bug reports and patches that aren't in the
RC, WON'T BE FIXED in the final release!  Think about it.  This is a
good thing, so we won't be able to screw up the final release at the
last moment.

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


From thomas@xs4all.net  Sun Oct  1 13:06:48 2000
From: thomas@xs4all.net (Thomas Wouters)
Date: Sun, 1 Oct 2000 14:06:48 +0200
Subject: [Python-Dev] Changes in semantics to str()?
In-Reply-To: <200009302056.PAA14718@cj20424-a.reston1.va.home.com>; from guido@python.org on Sat, Sep 30, 2000 at 03:56:18PM -0500
References: <200009302056.PAA14718@cj20424-a.reston1.va.home.com>
Message-ID: <20001001140648.A12812@xs4all.nl>

On Sat, Sep 30, 2000 at 03:56:18PM -0500, Guido van Rossum wrote:

> Below I have included changes to listobject.c, tupleobject.c and
> dictobject.c that fix this.  The fixes change the print and str()
> callbacks for these objects to use PyObject_Str() on the contained
> items -- except if the item is a string or Unicode string.  I made
> these exceptions because I don't like the idea of str(["abc"])
> yielding [abc] -- I'm too used to the idea of seeing ['abc'] here.
> And str() of a Unicode object fails when it contains non-ASCII
> characters, so that's no good either -- it would break too much code.

Personally, I'm -0, or perhaps -1 (I'll make up my mind while going out for
some lunch/breakfast ;) I would be in favor if the str() output were only
used to display something to a user, but that's not the case. And too many
people are under the impression that the 'print' handler is the same as the
'str' handler to make that distinction now, I'm afraid. My main gripe with
this change is that it makes str() for container objects unreliable...
Strings are a special case, but class-instances are not -- so something like
UserString will be displayed without quotes. I don't like the idea of
sometimes doing 'str' and sometimes doing 'repr'.

I understand what it's trying to solve, but I don't think that's a worse
inconsistency than the one this change introduces. It's also easy to
explain: 'str(list or dict) is the same as repr(list or dict)'. The new
phrase would be something like 'str(list or dict) calls str() on the objects
it contains, except for string and unicode objects.'. And even that breaks
when you mix in instances that wrap a container. A list containing a
UserList containing a set of (unicode-)strings would display the strings
without quotes. And you can't see that the second container is a UserList.

I also don't think this change should be made between the final beta and
2.0. Jeremy, don't let him ruin your feature freeze! :-)

-- 
Thomas Wouters <thomas@xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!


From jim@digicool.com  Sun Oct  1 15:32:27 2000
From: jim@digicool.com (Jim Fulton)
Date: Sun, 01 Oct 2000 10:32:27 -0400
Subject: [Python-Dev] select, signals, and "interrupted system call" (EINTR)
Message-ID: <39D74AFB.322E5187@digicool.com>

If a select-based (or, presumably, poll-based) server wants to
use signals for anything other than shutdown (e.g. closing and
reopening log files, rereading configs, etc.), then, on some 
platforms, a select call can fail with an "interrupted system
call" (EINTR) error that should be ignored.  The asyncore 
main loop should check for this error in it's select call
and the select module should make this error easier to check for.

In Python 1.5.2, the medusa select call can be changed from

        r,w,e = select.select (r,w,e, timeout)

to:

        while 1:
            try: r,w,e = select.select (r,w,e, timeout)
            except select.error, v:
                if v[0] != EINTR: raise
            else: break

I presume that this works in Python 1.6/2.0, but I
haven't tried it yet?

This depends on the structure of select.error values
and requires that we get EINTR from somewhere. (What
should the value be on NT?) 

I wonder if there should be an InterruptedSystemCall
exception somewhere that select raises in this case?

At a minimum, code like the above should be added to 
asyncore.

Thoughts?

Jim

--
Jim Fulton           mailto:jim@digicool.com
Technical Director   (888) 344-4332              Python Powered!
Digital Creations    http://www.digicool.com     http://www.python.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 rushing@nightmare.com  Sun Oct  1 20:07:59 2000
From: rushing@nightmare.com (Sam Rushing)
Date: Sun, 1 Oct 2000 12:07:59 -0700 (PDT)
Subject: [Python-Dev] [medusa] select, signals, and "interrupted system call" (EINTR)
In-Reply-To: <39D74AFB.322E5187@digicool.com>
References: <39D74AFB.322E5187@digicool.com>
Message-ID: <14807.35727.423642.721873@seattle.nightmare.com>

Jim Fulton writes:
 > The asyncore main loop should check for this error in it's select
 > call and the select module should make this error easier to check
 > for.

It might go better into the event_loop function, which I think of as a
more user-serviceable part.  [for example, the default loop vs. the
one in medusa/event_loop.py that supports schedulable events]

 > I presume that this works in Python 1.6/2.0, but I
 > haven't tried it yet?
 > 
 > This depends on the structure of select.error values
 > and requires that we get EINTR from somewhere. (What
 > should the value be on NT?) 

If it's a big problem, I guess we could use a different default
event_loop() function for win32 vs. unix.

 > At a minimum, code like the above should be added to asyncore.
 > 
 > Thoughts?

This has been asked for several times, I agree it'd be nice to have at
least a note in the docs..

-Sam



From loewis@informatik.hu-berlin.de  Sun Oct  1 20:13:41 2000
From: loewis@informatik.hu-berlin.de (Martin von Loewis)
Date: Sun, 1 Oct 2000 21:13:41 +0200 (MET DST)
Subject: [Python-Dev] Release candidate followed by feature freeze?
Message-ID: <200010011913.VAA01107@pandora.informatik.hu-berlin.de>

> I'd like to poll opinions about this (we haven't had a PythonLabs
> group meeting about this yet).

YES! I was hoping somebody would propose such a thing; I was quite
concerned that check-in procedures are still that liberate.

To report how similar projects operate: In gcc, a CVS release branch
is created at some point in time (usually months before the
release). When the code is declared frozen, all changes to the release
branch have to go through the release manager. After the release,
"important" changes to the mainline branch are manually propagated to
the release branch for subminor releases.

Regards,
Martin


From dkwolfe@pacbell.net  Sun Oct  1 22:23:03 2000
From: dkwolfe@pacbell.net (Dan Wolfe)
Date: Sun, 01 Oct 2000 14:23:03 -0700
Subject: [Python-Dev] FW: regarding the Python Developer posting...
Message-ID: <0G1R0061USP9TT@mta5.snfc21.pbi.net>

>> [commented out code that was causing seg fault in test_sre.py]

>you could try adding a Mac OS clause to the recursion limit stuff
>in Modules/_sre.c:
>
>#if !defined(USE_STACKCHECK)
>#if defined(...whatever's needed to detect Max OS X...)
[....]
>
>replace "...whatever...", and try larger values than 5000 (or smaller,
>if necessary.  10000 is clearly too large for your platform).
>
>(alternatively, you can increase the stack size.  maybe it's very small
>by default?)

the stack size is quite small by default - 512K.  After some testing I 
was able to figure out that it fails around 440 recursions... probably a 
bit too small in comparison to the other *nixes.... but then I'll defer 
to the experts in sre.

I was reading the August developer archives on the getrlimit and since 
that seem to be available, it's probably the right way to implement the 
stack check on Mac OS X.

Sure I can increase the default stack size - just a simple limit -h 
before running it in the shell... I let it run until about 7K 
recursions... even then it was only about 11MB and bumping the stack up 
by 30K or so per recursion... and I still had nearly 100MB free... and 
places to go. :-)

I'm going to write a bug report against Mac OS X and we'll see what 
happens.  In the meantime, you can hard code it to 440 and it will pass 
the test...  I've placed a patch on sourceforge that give the initial 
support for detecting Mac OS X as part of the make file but I still have 
to figure out how/where you defined MS_WIN64.... 

- Dan 



From barry@scottb.demon.co.uk  Sun Oct  1 23:19:21 2000
From: barry@scottb.demon.co.uk (Barry Scott)
Date: Sun, 1 Oct 2000 23:19:21 +0100
Subject: [Python-Dev] Patch to avoid conflict with older versions of Python.
In-Reply-To: <ECEPKNMJLHAPFFJHDOJBEEIHDLAA.MarkH@ActiveState.com>
Message-ID: <000b01c02bf5$a5edf070$060210ac@private>

I still think that Python needs to fix the problem with the API between
the core and the extensions. That way all the version checking would work
for Windows and Unix.

But since that approach has been rejected I'd take any change to python
that reduces support calls.

		BArry


> -----Original Message-----
> From: python-dev-admin@python.org [mailto:python-dev-admin@python.org]On
> Behalf Of Mark Hammond
> Sent: 29 September 2000 02:36
> To: python-dev@python.org
> Subject: [Python-Dev] Patch to avoid conflict with older versions of
> Python.
> 
> 
> Hi all,
> 	I'd like some feedback on a patch assigned to me.  It is designed to
> prevent Python extensions built for an earlier version of Python from
> crashing the new version.
> 
> I haven't actually tested the patch, but I am sure it works as advertised
> (who is db31 anyway?).
> 
> My question relates more to the "style" - the patch locates the new .pyd's
> address in memory, and parses through the MS PE/COFF format, locating the
> import table.  If then scans the import table looking for Pythonxx.dll, and
> compares any found entries with the current version.
> 
> Quite clever - a definite plus is that is should work for all old and
> future versions (of Python - dunno about Windows ;-) - but do we want this
> sort of code in Python?  Is this sort of hack, however clever, going to
> some back and bite us?
> 
> Second related question:  if people like it, is this feature something we
> can squeeze in for 2.0?
> 
> If there are no objections to any of this, I am happy to test it and check
> it in - but am not confident of doing so without some feedback.
> 
> Thanks,
> 
> Mark.
> 
> 
> _______________________________________________
> Python-Dev mailing list
> Python-Dev@python.org
> http://www.python.org/mailman/listinfo/python-dev
> 


From mal@lemburg.com  Mon Oct  2 08:36:49 2000
From: mal@lemburg.com (M.-A. Lemburg)
Date: Mon, 02 Oct 2000 09:36:49 +0200
Subject: [Python-Dev] Release candidate followed by feature freeze?
References: <200010011913.VAA01107@pandora.informatik.hu-berlin.de>
Message-ID: <39D83B11.C1DE9EE8@lemburg.com>

Martin von Loewis wrote:
> 
> > I'd like to poll opinions about this (we haven't had a PythonLabs
> > group meeting about this yet).
> 
> YES! I was hoping somebody would propose such a thing; I was quite
> concerned that check-in procedures are still that liberate.
> 
> To report how similar projects operate: In gcc, a CVS release branch
> is created at some point in time (usually months before the
> release). When the code is declared frozen, all changes to the release
> branch have to go through the release manager. After the release,
> "important" changes to the mainline branch are manually propagated to
> the release branch for subminor releases.

+1

I think this is very good approach to the problem which we should
consider to apply to Python too.

BTW, could the nightly snapshots of the CVS tree that Jeremy
installed be made official ? 

This would be a great way to attract more beta-tester since not
everyone is willing to first set CVS on their machine just
to download the current Python development version.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/


From martin@loewis.home.cs.tu-berlin.de  Mon Oct  2 08:39:09 2000
From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Mon, 2 Oct 2000 09:39:09 +0200
Subject: [Python-Dev] What is --with-next-framework
Message-ID: <200010020739.JAA01243@loewis.home.cs.tu-berlin.de>

I've been trying to understand how --with-next-framework is supposed
to work, and on what systems it is supposed to work - with little
success.

=46rom what I understand, it will create a python2.0.dylib, and it will
pass that to the linker when linking extension modules. Fine.

What confuses me is the snippet in Modules/getpath.c, where it somehow
assumes that the Python library will live in an unversioned lib
directory relative to the location of the Python framework. How is
that supposed to work? Is anybody here willing to claim that this code
is not entirely broken?

Regards,
Martin


From mal@lemburg.com  Mon Oct  2 08:51:37 2000
From: mal@lemburg.com (M.-A. Lemburg)
Date: Mon, 02 Oct 2000 09:51:37 +0200
Subject: [Python-Dev] Changes in semantics to str()?
References: <200009302056.PAA14718@cj20424-a.reston1.va.home.com>
Message-ID: <39D83E89.62F57D79@lemburg.com>

Guido van Rossum wrote:
> 
> When we changed floats to behave different on repr() than on str(), we
> briefly discussed changes to the container objects as well, but
> nothing came of it.
> 
> Currently, str() of a tuple, list or dictionary is the same as repr()
> of those objects.  This is not very consistent.  For example, when we
> have a float like 1.1 which can't be represented exactly, str() yields
> "1.1" but repr() yields "1.1000000000000001".  But if we place the
> same number in a list, it doesn't matter which function we use: we
> always get "[1.1000000000000001]".
> 
> Below I have included changes to listobject.c, tupleobject.c and
> dictobject.c that fix this.  The fixes change the print and str()
> callbacks for these objects to use PyObject_Str() on the contained
> items -- except if the item is a string or Unicode string.  I made
> these exceptions because I don't like the idea of str(["abc"])
> yielding [abc] -- I'm too used to the idea of seeing ['abc'] here.
> And str() of a Unicode object fails when it contains non-ASCII
> characters, so that's no good either -- it would break too much code.
> 
> Is it too late to check this in?  Another negative consequence would
> be that for user-defined or 3rd party extension objects that have
> different repr() and str(), like NumPy arrays, it might break some
> code -- but I think this is not very likely.

-1

I don't think that such a change is really worth breaking
code which relies on the current output of repr(list) or
str(list). As the test script from Fredrik for the Unicode
database showed there are some very subtle implications to
changes in str() and repr() -- e.g. in the mentioned case
the hash value would change.

Also, if I understand the patch correctly, str(list) would
be almost the same as '[' + ', '.join(map(str, entries)) + ']'
and '[' + ', '.join(map(repr, entries)) + ']' for repr().

While this may seem more transparent, I think it will cause
problems in practice: e.g. for large data buffers,
str(list) would now return the contents of the buffers
rather than just an abstract note about a buffer containing
the memory mapped data of file xyz.txt. As consequence, you'd
suddenly get a few MBs of output instead of a 100 char string...

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/


From martin@loewis.home.cs.tu-berlin.de  Mon Oct  2 08:48:37 2000
From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Mon, 2 Oct 2000 09:48:37 +0200
Subject: [Python-Dev] Usage of --with- configure options
Message-ID: <200010020748.JAA01293@loewis.home.cs.tu-berlin.de>

I noticed that Python's configure.in does not follow the autoconf
style for using --enable- options. The autoconf documentation says

#   Some packages require, or can optionally use, other software packages
# which are already installed.  The user can give `configure' command
# line options to specify which such external software to use.  The
#  options have one of these forms:
#
#     --with-PACKAGE[=ARG]
#     --without-PACKAGE
...
#    If a software package has optional compile-time features, the user
# can give `configure' command line options to specify whether to compile
# them.  The options have one of these forms:
#
#     --enable-FEATURE[=ARG]
#     --disable-FEATURE

So --with- options should be used for integrating 3rd party libraries,
--enable- options for features that that can be independently turned
on or off.

I'd conclude that the following options are provided incorrectly in
Python 2.0: --with-pydebug (should be --enable-pydebug),
--with(out)-cycle-gc (should be --disable-cycle-gc). Is this something
that should change?

Regards,
Martin



From guido@python.org  Mon Oct  2 12:30:45 2000
From: guido@python.org (Guido van Rossum)
Date: Mon, 02 Oct 2000 06:30:45 -0500
Subject: [Python-Dev] Usage of --with- configure options
In-Reply-To: Your message of "Mon, 02 Oct 2000 09:48:37 +0200."
 <200010020748.JAA01293@loewis.home.cs.tu-berlin.de>
References: <200010020748.JAA01293@loewis.home.cs.tu-berlin.de>
Message-ID: <200010021130.GAA23606@cj20424-a.reston1.va.home.com>

> I noticed that Python's configure.in does not follow the autoconf
> style for using --enable- options. The autoconf documentation says
> 
> #   Some packages require, or can optionally use, other software packages
> # which are already installed.  The user can give `configure' command
> # line options to specify which such external software to use.  The
> #  options have one of these forms:
> #
> #     --with-PACKAGE[=ARG]
> #     --without-PACKAGE
> ...
> #    If a software package has optional compile-time features, the user
> # can give `configure' command line options to specify whether to compile
> # them.  The options have one of these forms:
> #
> #     --enable-FEATURE[=ARG]
> #     --disable-FEATURE
> 
> So --with- options should be used for integrating 3rd party libraries,
> --enable- options for features that that can be independently turned
> on or off.
> 
> I'd conclude that the following options are provided incorrectly in
> Python 2.0: --with-pydebug (should be --enable-pydebug),
> --with(out)-cycle-gc (should be --disable-cycle-gc). Is this something
> that should change?

I noticed that too.  (Arguably also for --with-thread?)  I think it's
a forgiveable sin against the autoconf style guide, and not worth the
work of fixing it.

Either way the autoconf --with- or --enable- syntax is stupid because
it doesn't check for spelling errors in the options.  The rationale
for that is that some folks like to pass in unsupported options to a
whole tree of configure scripts.  I think that stinks, but what can I
do.  This would make the fix even more work, because we would have to
trap --with*-pydebug and --with*-cycle-gc to give an error message,
else developers used to the old syntax would never notice the change.

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



From guido@python.org  Mon Oct  2 12:35:40 2000
From: guido@python.org (Guido van Rossum)
Date: Mon, 02 Oct 2000 06:35:40 -0500
Subject: [Python-Dev] What is --with-next-framework
In-Reply-To: Your message of "Mon, 02 Oct 2000 09:39:09 +0200."
 <200010020739.JAA01243@loewis.home.cs.tu-berlin.de>
References: <200010020739.JAA01243@loewis.home.cs.tu-berlin.de>
Message-ID: <200010021135.GAA23630@cj20424-a.reston1.va.home.com>

> I've been trying to understand how --with-next-framework is supposed
> to work, and on what systems it is supposed to work - with little
> success.
> 
> From what I understand, it will create a python2.0.dylib, and it will
> pass that to the linker when linking extension modules. Fine.
> 
> What confuses me is the snippet in Modules/getpath.c, where it somehow
> assumes that the Python library will live in an unversioned lib
> directory relative to the location of the Python framework. How is
> that supposed to work? Is anybody here willing to claim that this code
> is not entirely broken?

It's most likely broken.  Which suggests that nobody has tried it in a
*looooooong* time.  I have no idea what the --with-next-framework
option does, and I have no idea what a NeXT framework is.

Why are we still trying to support NeXT?  Isn't it completely
obsolete?

I propose to rip out --with-next-framework and be done with it.  If
you feel --with-next-framework is worth having, feel free to propose
platform-specific fixes to getpathp.c.

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


From fdrake@beopen.com  Mon Oct  2 14:22:19 2000
From: fdrake@beopen.com (Fred L. Drake, Jr.)
Date: Mon, 2 Oct 2000 09:22:19 -0400 (EDT)
Subject: [Python-Dev] Usage of --with- configure options
In-Reply-To: <200010020748.JAA01293@loewis.home.cs.tu-berlin.de>
References: <200010020748.JAA01293@loewis.home.cs.tu-berlin.de>
Message-ID: <14808.35851.589320.360123@cj42289-a.reston1.va.home.com>

Martin v. Loewis writes:
 > I'd conclude that the following options are provided incorrectly in
 > Python 2.0: --with-pydebug (should be --enable-pydebug),
 > --with(out)-cycle-gc (should be --disable-cycle-gc). Is this something
 > that should change?

  Yes, if only to make it more consistent with existing practice.  A
harder one to change would be --enable-threads, because we've used
that for so long already.  Perhaps --enable-threads should be added,
and use that in the README instead of --with-threads.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member



From fredrik@pythonware.com  Mon Oct  2 14:41:21 2000
From: fredrik@pythonware.com (Fredrik Lundh)
Date: Mon, 2 Oct 2000 15:41:21 +0200
Subject: [Python-Dev] Release candidate followed by feature freeze?
References: <200010010531.AAA15697@cj20424-a.reston1.va.home.com>
Message-ID: <001601c02c76$73a1cac0$0900a8c0@SPIFF>

guido wrote:
> If the idea of a RC sounds okay

Sure does.

> I'd like to propose to release it on October 5. 

Hmm.  My plan was to to work on the remaining SRE issues on
Saturday, leaving Sunday-Tuesday for final "burn-in"...

</F>



From petrilli@amber.org  Mon Oct  2 15:14:23 2000
From: petrilli@amber.org (Christopher Petrilli)
Date: Mon, 2 Oct 2000 10:14:23 -0400
Subject: [Python-Dev] What is --with-next-framework
In-Reply-To: <200010021135.GAA23630@cj20424-a.reston1.va.home.com>; from guido@python.org on Mon, Oct 02, 2000 at 06:35:40AM -0500
References: <200010020739.JAA01243@loewis.home.cs.tu-berlin.de> <200010021135.GAA23630@cj20424-a.reston1.va.home.com>
Message-ID: <20001002101423.A18958@trump.amber.org>

Guido van Rossum [guido@python.org] wrote:
> > I've been trying to understand how --with-next-framework is supposed
> > to work, and on what systems it is supposed to work - with little
> > success.
> > 
> > From what I understand, it will create a python2.0.dylib, and it will
> > pass that to the linker when linking extension modules. Fine.
> > 
> > What confuses me is the snippet in Modules/getpath.c, where it somehow
> > assumes that the Python library will live in an unversioned lib
> > directory relative to the location of the Python framework. How is
> > that supposed to work? Is anybody here willing to claim that this code
> > is not entirely broken?
> 
> It's most likely broken.  Which suggests that nobody has tried it in a
> *looooooong* time.  I have no idea what the --with-next-framework
> option does, and I have no idea what a NeXT framework is.

A NeXT Framework is a way of building software on NeXTstep/OpenStep
machines, and as far as I can tell, it continues largely unmodified on 
MacOS X (which is more OpenStep than MacOS at many layers).  We just
got our development copies of MacOS X here at Digital Creations, so we 
can take a look, but... as I recall, Jeffrey Shell wasn't able to get
Python running without using these options.

> Why are we still trying to support NeXT?  Isn't it completely
> obsolete?

I know of a few dozen large organizations still on OpenStep, and with
MacOS X I'd say it's far frrom obsolete, if anything it's more likely
than ever to be a"strong platform".

> I propose to rip out --with-next-framework and be done with it.  If
> you feel --with-next-framework is worth having, feel free to propose
> platform-specific fixes to getpathp.c.

I think it should be auto-detected, there's just no reason not to.
The uname of a MacOS X box is quite different than a Mac OX 9 box
(which has no uname :-).  Hopefully we can get a chance to look at
this at work this week.

Chris
-- 
| Christopher Petrilli
| petrilli@amber.org


From thomas@xs4all.net  Mon Oct  2 18:23:19 2000
From: thomas@xs4all.net (Thomas Wouters)
Date: Mon, 2 Oct 2000 19:23:19 +0200
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules readline.c,2.32,2.33
In-Reply-To: <200010021553.IAA01251@slayer.i.sourceforge.net>; from gvanrossum@users.sourceforge.net on Mon, Oct 02, 2000 at 08:53:12AM -0700
References: <200010021553.IAA01251@slayer.i.sourceforge.net>
Message-ID: <20001002192319.C12812@xs4all.nl>

On Mon, Oct 02, 2000 at 08:53:12AM -0700, Guido van Rossum wrote:

> Update of /cvsroot/python/python/dist/src/Modules
> In directory slayer.i.sourceforge.net:/tmp/cvs-serv1200

> Modified Files:
> 	readline.c 
> Log Message:
> Supporting rl_library_version is more trouble than it's worth --
> readline doesn't have it before readline 2.2 and there's no
> compile-time way to find out which readline version is in use.

But we can detect whether readline has rl_library_version during runtime,
and #ifdef it ;) I think the readline version info is useful enough to
warrant the extra #define and #ifdef... I can whip it up tonight, if the
autoconf check is desired ;P

-- 
Thomas Wouters <thomas@xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!


From guido@python.org  Mon Oct  2 19:54:31 2000
From: guido@python.org (Guido van Rossum)
Date: Mon, 02 Oct 2000 13:54:31 -0500
Subject: [Python-Dev] What is --with-next-framework
In-Reply-To: Your message of "Mon, 02 Oct 2000 10:14:23 -0400."
 <20001002101423.A18958@trump.amber.org>
References: <200010020739.JAA01243@loewis.home.cs.tu-berlin.de> <200010021135.GAA23630@cj20424-a.reston1.va.home.com>
 <20001002101423.A18958@trump.amber.org>
Message-ID: <200010021854.NAA01120@cj20424-a.reston1.va.home.com>

[Argument for the continued viability of OpenStep noted.]

> I think it should be auto-detected, there's just no reason not to.
> The uname of a MacOS X box is quite different than a Mac OX 9 box
> (which has no uname :-).  Hopefully we can get a chance to look at
> this at work this week.

Hm...  That might not get there in time for the 2.0 Release Candidate,
and after that it's an absolute code freeze (with exceptions only for
showstopper bugfixes) until 2.0 is released.

I guess MacOS X itself is still in beta, so we can afford to require
the creation of additional patches to fully support it after 2.0 is
released.

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



From petrilli@trump.amber.org  Mon Oct  2 18:56:03 2000
From: petrilli@trump.amber.org (Christopher Petrilli)
Date: Mon, 2 Oct 2000 13:56:03 -0400
Subject: [Python-Dev] What is --with-next-framework
In-Reply-To: <200010021854.NAA01120@cj20424-a.reston1.va.home.com>; from guido@python.org on Mon, Oct 02, 2000 at 01:54:31PM -0500
References: <200010020739.JAA01243@loewis.home.cs.tu-berlin.de> <200010021135.GAA23630@cj20424-a.reston1.va.home.com> <20001002101423.A18958@trump.amber.org> <200010021854.NAA01120@cj20424-a.reston1.va.home.com>
Message-ID: <20001002135603.C18958@trump.amber.org>

Guido van Rossum [guido@python.org] wrote:
> [Argument for the continued viability of OpenStep noted.]
> 
> > I think it should be auto-detected, there's just no reason not to.
> > The uname of a MacOS X box is quite different than a Mac OX 9 box
> > (which has no uname :-).  Hopefully we can get a chance to look at
> > this at work this week.
> 
> Hm...  That might not get there in time for the 2.0 Release Candidate,
> and after that it's an absolute code freeze (with exceptions only for
> showstopper bugfixes) until 2.0 is released.
> 
> I guess MacOS X itself is still in beta, so we can afford to require
> the creation of additional patches to fully support it after 2.0 is
> released.

MacOS X is in beta until Q1 (and I'd bet the END of Q1), so if there's 
a 2.1 planned sometime around there, which I believe there is, then
it'd be fine to roll it into that level in my opinion.

Chris
-- 
| Christopher Petrilli
| petrilli@amber.org


From guido@python.org  Mon Oct  2 20:15:37 2000
From: guido@python.org (Guido van Rossum)
Date: Mon, 02 Oct 2000 14:15:37 -0500
Subject: [Python-Dev] Changes in semantics to str()?
In-Reply-To: Your message of "Sun, 01 Oct 2000 14:06:48 +0200."
 <20001001140648.A12812@xs4all.nl>
References: <200009302056.PAA14718@cj20424-a.reston1.va.home.com>
 <20001001140648.A12812@xs4all.nl>
Message-ID: <200010021915.OAA01219@cj20424-a.reston1.va.home.com>

I guess Thomas has settled the fate of my str() patch -- UserString
won't be dealt with properly.  I hereby withdraw the patch.

(I'm not sure what Marc-Andre means by buffer objects whose str() is
long but whose repr() is short, but it's probably a similar issue.)

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


From guido@python.org  Mon Oct  2 20:19:24 2000
From: guido@python.org (Guido van Rossum)
Date: Mon, 02 Oct 2000 14:19:24 -0500
Subject: [Python-Dev] Release candidate followed by feature freeze?
In-Reply-To: Your message of "Sun, 01 Oct 2000 21:13:41 +0200."
 <200010011913.VAA01107@pandora.informatik.hu-berlin.de>
References: <200010011913.VAA01107@pandora.informatik.hu-berlin.de>
Message-ID: <200010021919.OAA01232@cj20424-a.reston1.va.home.com>

> YES! I was hoping somebody would propose such a thing; I was quite
> concerned that check-in procedures are still that liberate.

Good.  We will have a release candidate then.

> To report how similar projects operate: In gcc, a CVS release branch
> is created at some point in time (usually months before the
> release). When the code is declared frozen, all changes to the release
> branch have to go through the release manager. After the release,
> "important" changes to the mainline branch are manually propagated to
> the release branch for subminor releases.

I am reluctant to use CVS branches (my experience with the branch for
1.6 suggests again that this is not at all smooth).

About the timing for the release candidate (RC): I think we need a
week +/- two days between the RC and the final release; this is needed
to make sure that the RC is actually tried out by enough people and
that the bug reports (if any) have been processed.  I believe we can
refrain from checkin in for a week but not much longer.

Fredrik Lundh mentions that he can't get his final batch of SRE
patches in before Saturday.  So the only realistic timing is to do the
RC on Monday (Oct 9) and the final release a week later (Oct 16).

Everybody okay with this?

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


From mal@lemburg.com  Mon Oct  2 19:35:27 2000
From: mal@lemburg.com (M.-A. Lemburg)
Date: Mon, 02 Oct 2000 20:35:27 +0200
Subject: [Python-Dev] Changes in semantics to str()?
References: <200009302056.PAA14718@cj20424-a.reston1.va.home.com>
 <20001001140648.A12812@xs4all.nl> <200010021915.OAA01219@cj20424-a.reston1.va.home.com>
Message-ID: <39D8D56F.F279B9E5@lemburg.com>

Guido van Rossum wrote:
> 
> I guess Thomas has settled the fate of my str() patch -- UserString
> won't be dealt with properly.  I hereby withdraw the patch.
> 
> (I'm not sure what Marc-Andre means by buffer objects whose str() is
> long but whose repr() is short, but it's probably a similar issue.)
>

Example for the record:

>>> b = buffer('long string')
>>> b
<read-only buffer for 0x82a0160, ptr 0x82a0174, size 11 at 0x82db170>
>>> l = [b]
>>> l
[<read-only buffer for 0x82a0160, ptr 0x82a0174, size 11 at 0x82db170>]
>>> [str(b)]
['long string']

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/


From nas@arctrix.com  Mon Oct  2 12:48:59 2000
From: nas@arctrix.com (Neil Schemenauer)
Date: Mon, 2 Oct 2000 04:48:59 -0700
Subject: [Python-Dev] Release candidate followed by feature freeze?
In-Reply-To: <200010021919.OAA01232@cj20424-a.reston1.va.home.com>; from guido@python.org on Mon, Oct 02, 2000 at 02:19:24PM -0500
References: <200010011913.VAA01107@pandora.informatik.hu-berlin.de> <200010021919.OAA01232@cj20424-a.reston1.va.home.com>
Message-ID: <20001002044859.A9639@glacier.fnational.com>

On Mon, Oct 02, 2000 at 02:19:24PM -0500, Guido van Rossum wrote:
> So the only realistic timing is to do the RC on Monday (Oct 9)
> and the final release a week later (Oct 16).
> 
> Everybody okay with this?

What is going to be the fate of the GC?  There are currently two
reported bugs which I have been unable to reproduce.  If its
going to be disabled for 2.0 then it should be disabled in the
beta release.

  Neil


From Fredrik Lundh" <effbot@telia.com  Mon Oct  2 20:11:58 2000
From: Fredrik Lundh" <effbot@telia.com (Fredrik Lundh)
Date: Mon, 2 Oct 2000 21:11:58 +0200
Subject: [Python-Dev] Re: [Bug #115845] sre: maxsplit as keyword argument
References: <200010021341.GAA26413@bush.i.sourceforge.net>
Message-ID: <003e01c02ca4$a7e2ef20$766940d5@hagrid>

http://sourceforge.net/bugs/?func=detailbug&bug_id=115845&group_id=5470

> Details: Split gives TypeError when called as a method of compiled
> regular expression object with maxsplit as keyword argument.
> This error is only in sre, pre is OK.
> 
> Python 1.6 (#2, Sep  6 2000, 18:20:07) [C] on osf1V4
> >>> import re
> >>> patt = re.compile(' ')
> >>> list = patt.split("a b c",50)              # OK
> >>> list = re.split(' ',"a b c",maxsplit=50)   # OK     
> >>> list = patt.split("a b c",maxsplit=50)     # ERROR
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
> TypeError: this function takes no keyword arguments
> 
> >>> import pre
> >>> patt = pre.compile(' ')
> >>> list = patt.split("a b c",maxsplit=50)     # OK

is this really a bug?  should users expect to be able to use
keyword arguments anywhere?

</F>



From guido@python.org  Mon Oct  2 21:09:32 2000
From: guido@python.org (Guido van Rossum)
Date: Mon, 02 Oct 2000 15:09:32 -0500
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules readline.c,2.32,2.33
In-Reply-To: Your message of "Mon, 02 Oct 2000 19:23:19 +0200."
 <20001002192319.C12812@xs4all.nl>
References: <200010021553.IAA01251@slayer.i.sourceforge.net>
 <20001002192319.C12812@xs4all.nl>
Message-ID: <200010022009.PAA01439@cj20424-a.reston1.va.home.com>

> But we can detect whether readline has rl_library_version during runtime,
> and #ifdef it ;) I think the readline version info is useful enough to
> warrant the extra #define and #ifdef... I can whip it up tonight, if the
> autoconf check is desired ;P

Actually, I'm not sure what difference the readline version makes --
why would you need it?

Also, I'm not sure that the configure check is enough -- it's possible
that readline lives in a non-standard place where configure can't find
it but ppointed to by the Setup file.

I think it's just not worth it.

Please don't.

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


From guido@python.org  Mon Oct  2 21:18:57 2000
From: guido@python.org (Guido van Rossum)
Date: Mon, 02 Oct 2000 15:18:57 -0500
Subject: [Python-Dev] Re: [Bug #115845] sre: maxsplit as keyword argument
In-Reply-To: Your message of "Mon, 02 Oct 2000 21:11:58 +0200."
 <003e01c02ca4$a7e2ef20$766940d5@hagrid>
References: <200010021341.GAA26413@bush.i.sourceforge.net>
 <003e01c02ca4$a7e2ef20$766940d5@hagrid>
Message-ID: <200010022018.PAA01525@cj20424-a.reston1.va.home.com>

> http://sourceforge.net/bugs/?func=detailbug&bug_id=115845&group_id=5470
> 
> > Details: Split gives TypeError when called as a method of compiled
> > regular expression object with maxsplit as keyword argument.
> > This error is only in sre, pre is OK.
> > 
> > Python 1.6 (#2, Sep  6 2000, 18:20:07) [C] on osf1V4
> > >>> import re
> > >>> patt = re.compile(' ')
> > >>> list = patt.split("a b c",50)              # OK
> > >>> list = re.split(' ',"a b c",maxsplit=50)   # OK     
> > >>> list = patt.split("a b c",maxsplit=50)     # ERROR
> > Traceback (most recent call last):
> >   File "<stdin>", line 1, in ?
> > TypeError: this function takes no keyword arguments
> > 
> > >>> import pre
> > >>> patt = pre.compile(' ')
> > >>> list = patt.split("a b c",maxsplit=50)     # OK
> 
> is this really a bug?  should users expect to be able to use
> keyword arguments anywhere?

Unclear, but the names were documented, and it worked before (when
pattern objects were Python instances) -- so who knows how much code
there's lying around that assumes this.  Well, we know it's more than
zero, because the bug report came from soemone who ran into this. :-)

Can we at PythonLabs help by adding keyword arguments to all of the
_sre.c functions?  I presume it's a pretty straightforward change.

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


From Fredrik Lundh" <effbot@telia.com  Mon Oct  2 20:35:45 2000
From: Fredrik Lundh" <effbot@telia.com (Fredrik Lundh)
Date: Mon, 2 Oct 2000 21:35:45 +0200
Subject: [Python-Dev] Re: [Bug #115845] sre: maxsplit as keyword argument
References: <200010021341.GAA26413@bush.i.sourceforge.net>              <003e01c02ca4$a7e2ef20$766940d5@hagrid>  <200010022018.PAA01525@cj20424-a.reston1.va.home.com>
Message-ID: <014001c02ca8$44f7eb00$766940d5@hagrid>

> Can we at PythonLabs help by adding keyword arguments to all of the
> _sre.c functions?  I presume it's a pretty straightforward change.

if anyone can post (or point me to) an example showing
how to use the keyword API, I can take if from there.

</F>



From guido@python.org  Mon Oct  2 22:06:00 2000
From: guido@python.org (Guido van Rossum)
Date: Mon, 02 Oct 2000 16:06:00 -0500
Subject: [Python-Dev] Re: [Bug #115845] sre: maxsplit as keyword argument
In-Reply-To: Your message of "Mon, 02 Oct 2000 21:35:45 +0200."
 <014001c02ca8$44f7eb00$766940d5@hagrid>
References: <200010021341.GAA26413@bush.i.sourceforge.net> <003e01c02ca4$a7e2ef20$766940d5@hagrid> <200010022018.PAA01525@cj20424-a.reston1.va.home.com>
 <014001c02ca8$44f7eb00$766940d5@hagrid>
Message-ID: <200010022106.QAA01620@cj20424-a.reston1.va.home.com>

> if anyone can post (or point me to) an example showing
> how to use the keyword API, I can take if from there.

Grep the Modules directory for PyArg_ParseTupleAndKeywords.  It's used
in the mmap, parser, pyexpat and sha modules.

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


From fdrake@beopen.com  Mon Oct  2 21:04:30 2000
From: fdrake@beopen.com (Fred L. Drake, Jr.)
Date: Mon, 2 Oct 2000 16:04:30 -0400 (EDT)
Subject: [Python-Dev] Re: [Bug #115845] sre: maxsplit as keyword argument
In-Reply-To: <014001c02ca8$44f7eb00$766940d5@hagrid>
References: <200010021341.GAA26413@bush.i.sourceforge.net>
 <003e01c02ca4$a7e2ef20$766940d5@hagrid>
 <200010022018.PAA01525@cj20424-a.reston1.va.home.com>
 <014001c02ca8$44f7eb00$766940d5@hagrid>
Message-ID: <14808.59982.32731.732799@cj42289-a.reston1.va.home.com>

Fredrik Lundh writes:
 > if anyone can post (or point me to) an example showing
 > how to use the keyword API, I can take if from there.

  This is documented in the Extending & Embedding manual.  The parser
module (Modules/parsermodule.c) uses this.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member



From MarkH@ActiveState.com  Mon Oct  2 23:37:13 2000
From: MarkH@ActiveState.com (Mark Hammond)
Date: Tue, 3 Oct 2000 09:37:13 +1100
Subject: [Python-Dev] Release candidate followed by feature freeze?
In-Reply-To: <001601c02c76$73a1cac0$0900a8c0@SPIFF>
Message-ID: <ECEPKNMJLHAPFFJHDOJBGEOBDLAA.MarkH@ActiveState.com>

> guido wrote:
> > If the idea of a RC sounds okay
>
> Sure does.
>
> > I'd like to propose to release it on October 5.
>
> Hmm.  My plan was to to work on the remaining SRE issues on
> Saturday, leaving Sunday-Tuesday for final "burn-in"...

Also FYI, I intend applying the previous-version-crash patch tomorrow (or
late today), so those extra few days for /F would also prevent this patch
going out _too_ green...

Mark.



From fdrake@beopen.com  Tue Oct  3 01:23:13 2000
From: fdrake@beopen.com (Fred L. Drake, Jr.)
Date: Mon, 2 Oct 2000 20:23:13 -0400 (EDT)
Subject: [Python-Dev] Development HTML docs online
Message-ID: <14809.9969.61986.897165@cj42289-a.reston1.va.home.com>

  I've set things up so I can easily "publish" the Python
documentation online without actually building a release.  It's not
entirely automatic, but I can push it online easily, so you'll be able
to see what I'm doing.  It can include more than just what's in CVS,
but I try not to have too much waiting to checkin at once.
  Check it out:

	ftp://python.beopen.com/pub/docco/devel/index.html


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member



From guido@python.org  Tue Oct  3 03:36:03 2000
From: guido@python.org (Guido van Rossum)
Date: Mon, 02 Oct 2000 21:36:03 -0500
Subject: [Python-Dev] Release candidate followed by feature freeze?
In-Reply-To: Your message of "Mon, 02 Oct 2000 04:48:59 MST."
 <20001002044859.A9639@glacier.fnational.com>
References: <200010011913.VAA01107@pandora.informatik.hu-berlin.de> <200010021919.OAA01232@cj20424-a.reston1.va.home.com>
 <20001002044859.A9639@glacier.fnational.com>
Message-ID: <200010030236.VAA02702@cj20424-a.reston1.va.home.com>

> What is going to be the fate of the GC?  There are currently two
> reported bugs which I have been unable to reproduce.  If its
> going to be disabled for 2.0 then it should be disabled in the
> beta release.

Good point.  I see only the one that's assigned to you (reported by
Rob Hooft):

http://sourceforge.net/bugs/?group_id=5470&func=detailbug&bug_id=115341

What's the other?

Hooft's problem makes heavy use of Tkinter and Pmw, it seems.  Maybe
that's a clue?  Does he also use threads?  Is he willing to send his
entire program over?  (If you don't have time, we may have time at
PythonLabs!)

Anyway, I'm not yet ready to disable GC by default -- that's sensible
but also defeats the purpose...

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


From gward@python.net  Tue Oct  3 05:08:45 2000
From: gward@python.net (Greg Ward)
Date: Tue, 3 Oct 2000 00:08:45 -0400
Subject: [Python-Dev] ANNOUNCE: Distutils 1.0
Message-ID: <20001003000845.A1812@beelzebub>

                     Python Distribution Utilities
                              release 1.0
                            October 2, 2000

The Python Distribution Utilities, or Distutils for short, are a
collection of modules that aid in the development, distribution, and
installation of Python modules.  (It is intended that ultimately the
Distutils will grow up into a system for distributing and installing
whole Python applications, but for now their scope is limited to module
distributions.)

The Distutils are a standard part of Python 1.6 and 2.0; if you are running
1.6 or 2.0, you don't need to install the Distutils separately.  (However,
you might want to upgrade if you're running Python 1.6.)  This release is
primarily so that you can add the Distutils to a Python 1.5.2 installation
-- you will then be able to install modules that require the Distutils, or
use the Distutils to distribute your own modules.

Distutils 1.0 is the version that will be released with Python 2.0 (unless
last-minute bugs pop up).

More information is available at the Distutils web page:

    http://www.python.org/sigs/distutils-sig/

and in the README.txt included in the Distutils source distribution.

You can download the Distutils from

    http://www.python.org/sigs/distutils-sig/download.html

Trivial patches can be sent to me (Greg Ward) at gward@python.net.
Larger patches should be discussed on the Distutils mailing list:
distutils-sig@python.org.

        Greg
-- 
Greg Ward                                      gward@python.net
http://starship.python.net/~gward/
And now for something completely different.


From fredrik@pythonware.com  Tue Oct  3 09:52:37 2000
From: fredrik@pythonware.com (Fredrik Lundh)
Date: Tue, 3 Oct 2000 10:52:37 +0200
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib cgi.py,1.53,1.54
References: <200010030832.BAA05615@slayer.i.sourceforge.net>
Message-ID: <011801c02d17$48659b10$0900a8c0@SPIFF>

> Change first line to #!/usr/bin/env python (really just to test check-in).

hmm.  cgi.py is a CGI script.  according to the Python FAQ, CGI
scripts should use an explicit path, not /usr/bin/env:

    "Note -- *don't* do this for CGI scripts. The $PATH variable
    for CGI scripts is often very minimal, so you need to use the
    actual absolute pathname of the interpreter."

(since this comes up over and over again, maybe someone should
add a comment to the file?)

</F>



From ping@lfw.org  Tue Oct  3 11:15:13 2000
From: ping@lfw.org (Ka-Ping Yee)
Date: Tue, 3 Oct 2000 03:15:13 -0700 (PDT)
Subject: [Python-Dev] Re: CVS: python/dist/src/Lib cgi.py,1.53,1.54
In-Reply-To: <011801c02d17$48659b10$0900a8c0@SPIFF>
Message-ID: <Pine.LNX.4.10.10010030310460.744-100000@skuld.kingmanhall.org>

On Tue, 3 Oct 2000, Fredrik Lundh wrote:
> > Change first line to #!/usr/bin/env python (really just to test check-in).
> 
> hmm.  cgi.py is a CGI script.  according to the Python FAQ, CGI
> scripts should use an explicit path, not /usr/bin/env:
> 
>     "Note -- *don't* do this for CGI scripts. The $PATH variable
>     for CGI scripts is often very minimal, so you need to use the
>     actual absolute pathname of the interpreter."

The $PATH variable for CGI scripts may be minimal, but minimal
as it is, Python should still be on it.  Using /usr/bin/python
works for half the people and /usr/local/bin/python works for
the other half... /usr/bin/env is supposed to work for everyone.

If this has already been argued soundly to death, i'm happy to
back out the change and add a comment.  It was a meaningless
change for me anyway.

Oh well.  Anyway, i'm glad CVS commit *finally* works for me.
Sorry for the extra hassle.


-- ?!ng

"To be human is to continually change.  Your desire to remain as you are
is what ultimately limits you."
    -- The Puppet Master, Ghost in the Shell



From nas@arctrix.com  Tue Oct  3 07:41:18 2000
From: nas@arctrix.com (Neil Schemenauer)
Date: Mon, 2 Oct 2000 23:41:18 -0700
Subject: [Python-Dev] Release candidate followed by feature freeze?
In-Reply-To: <200010030236.VAA02702@cj20424-a.reston1.va.home.com>; from guido@python.org on Mon, Oct 02, 2000 at 09:36:03PM -0500
References: <200010011913.VAA01107@pandora.informatik.hu-berlin.de> <200010021919.OAA01232@cj20424-a.reston1.va.home.com> <20001002044859.A9639@glacier.fnational.com> <200010030236.VAA02702@cj20424-a.reston1.va.home.com>
Message-ID: <20001002234118.A11108@glacier.fnational.com>

On Mon, Oct 02, 2000 at 09:36:03PM -0500, Guido van Rossum wrote:
> What's the other?

Some people from Origin Systems have reported a crash.  They are
using Python in a large application (probably related to the
Ultima Online game).  I will put the bug report in the database
today.

They are using a custom version of cPickle that may be causing
the problem.  It is an instance object which is causing the
trouble.  My malloc() == NULL patch for classobject.c did not fix
things.  They still haven't reported back regarding the cPickle
fix.

> Hooft's problem makes heavy use of Tkinter and Pmw, it seems.
> Maybe that's a clue?

I don't think _tkinter does anything special (unlike cPickle and
new).

> Does he also use threads?

His interpreter has threads enabled it seems.  Maybe I should get
him to test without threads, assuming he doesn't require them.

> Is he willing to send his entire program over?

From his bug report I understood that he was unwilling to make it
available.  New that I re-read the report I see that he did not
say that.  I will ask him.

> Anyway, I'm not yet ready to disable GC by default -- that's sensible
> but also defeats the purpose...

Okay.  I think I've found a possible problem.  When I set
threshold0 to 1 in the C code, weird things start happening.  I'm
looking into it.

  Neil


From bwarsaw@beopen.com  Tue Oct  3 14:49:23 2000
From: bwarsaw@beopen.com (Barry A. Warsaw)
Date: Tue, 3 Oct 2000 09:49:23 -0400 (EDT)
Subject: [Python-Dev] Re: CVS: python/dist/src/Lib cgi.py,1.53,1.54
References: <011801c02d17$48659b10$0900a8c0@SPIFF>
 <Pine.LNX.4.10.10010030310460.744-100000@skuld.kingmanhall.org>
Message-ID: <14809.58339.707476.273418@anthem.concentric.net>

>>>>> "KY" == Ka-Ping Yee <ping@lfw.org> writes:

    KY> The $PATH variable for CGI scripts may be minimal, but minimal
    KY> as it is, Python should still be on it.

Well, maybe. :) E.g. Mailman's cgi wrapper program explicitly removes
$PATH from the environment before calling python with a compiled in
absolute path.

Which leads me to ask: how often are you calling cgi.py directly
anyway?  That'll just run the text() function which isn't terribly
useful other than to debug your cgi setup.  Usually you're calling
some other module that imports cgi, and in that case this line won't
have any effect.  And besides, it's not very safe to call a script
directly so I'd recommend a wrapper program anyway.
    
I'd say this one is rather harmless.

-Barry


From guido@python.org  Tue Oct  3 15:58:00 2000
From: guido@python.org (Guido van Rossum)
Date: Tue, 03 Oct 2000 09:58:00 -0500
Subject: [Python-Dev] Re: CVS: python/dist/src/Lib cgi.py,1.53,1.54
In-Reply-To: Your message of "Tue, 03 Oct 2000 03:15:13 MST."
 <Pine.LNX.4.10.10010030310460.744-100000@skuld.kingmanhall.org>
References: <Pine.LNX.4.10.10010030310460.744-100000@skuld.kingmanhall.org>
Message-ID: <200010031458.JAA05661@cj20424-a.reston1.va.home.com>

> > hmm.  cgi.py is a CGI script.  according to the Python FAQ, CGI
> > scripts should use an explicit path, not /usr/bin/env:
> > 
> >     "Note -- *don't* do this for CGI scripts. The $PATH variable
> >     for CGI scripts is often very minimal, so you need to use the
> >     actual absolute pathname of the interpreter."
> 
> The $PATH variable for CGI scripts may be minimal, but minimal
> as it is, Python should still be on it.  Using /usr/bin/python
> works for half the people and /usr/local/bin/python works for
> the other half... /usr/bin/env is supposed to work for everyone.

No.  On a typical Unix system (Linux perhaps excluded), /usr/local/bin
is not on the default $PATH.

> If this has already been argued soundly to death, i'm happy to
> back out the change and add a comment.  It was a meaningless
> change for me anyway.

I backed it out for you.  It really has been argued to death.

Glad CVS works for you!

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


From jeremy@beopen.com  Tue Oct  3 16:37:21 2000
From: jeremy@beopen.com (Jeremy Hylton)
Date: Tue, 3 Oct 2000 11:37:21 -0400 (EDT)
Subject: [Python-Dev] Release candidate followed by feature freeze?
In-Reply-To: <20001002234118.A11108@glacier.fnational.com>
References: <200010011913.VAA01107@pandora.informatik.hu-berlin.de>
 <200010021919.OAA01232@cj20424-a.reston1.va.home.com>
 <20001002044859.A9639@glacier.fnational.com>
 <200010030236.VAA02702@cj20424-a.reston1.va.home.com>
 <20001002234118.A11108@glacier.fnational.com>
Message-ID: <14809.64817.295610.920807@bitdiddle.concentric.net>

>>>>> "NS" == Neil Schemenauer <nas@arctrix.com> writes:

  [GvR writes:]
  >> Anyway, I'm not yet ready to disable GC by default -- that's
  >> sensible but also defeats the purpose...

  NS> Okay.  I think I've found a possible problem.  When I set
  NS> threshold0 to 1 in the C code, weird things start happening.
  NS> I'm looking into it.

I agree that it isn't too useful to ship the garbage collector, but
have it turned off.  On the other hand, we're going to get a lot of
unhappy users if GC bugs cause inexplicable crashes in large
programs.  It would be hard to sell Python for important applications,
e.g. long-running server processes, if there was a small possibility
that the program could crash through no fault of its own.

Jeremy



From bwarsaw@beopen.com  Tue Oct  3 16:39:19 2000
From: bwarsaw@beopen.com (Barry A. Warsaw)
Date: Tue, 3 Oct 2000 11:39:19 -0400 (EDT)
Subject: [Python-Dev] Suggested change for Setup.in
Message-ID: <14809.64935.157146.681813@anthem.concentric.net>

I have a small suggestion for Modules/Setup.in.  On Linux (RH6.1) with
the zlib rpm installed, all I need to enable this module is the
following line:

    zlib zlibmodule.c -lz

but Setup.in has this suggestion, which I think is too hard for people
to figure out what to do:

    zlib zlibmodule.c -I$(prefix)/include -L$(exec_prefix)/lib -lz

The standard build options will already include the right -I and -L
flags for this to Just Work.  I suggest we make the common case
(Linux?) simple, and let others figure out what the right -I and -L
flags are.  I submit that even if they /do/ have to handcraft -I and
-L, the defaults in Setup.in are pretty meaningless.

A worthy change?  For 2.0 final?

-Barry


From guido@python.org  Tue Oct  3 18:31:47 2000
From: guido@python.org (Guido van Rossum)
Date: Tue, 03 Oct 2000 12:31:47 -0500
Subject: [Python-Dev] Canvas.Canvas.bbox() return value
Message-ID: <200010031731.MAA08827@cj20424-a.reston1.va.home.com>

Hi Fredrik,

Re this bug report:

http://sourceforge.net/bugs/?func=detailbug&bug_id=110677&group_id=5470

I can take care of the Canvas issues, but I need your advice on
bbox().  He's right that the bbox() method the Canvas class in the
Canvas module is different from all other bbox() methods: it returns a
tuple of tuples ((x1,y1),(x2,y2)) instead of a flat 4-tuple
(x,y1,x2,y2).

Do you think it's worth not breaking existing code here???

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


From bwarsaw@beopen.com  Tue Oct  3 17:34:51 2000
From: bwarsaw@beopen.com (Barry A. Warsaw)
Date: Tue, 3 Oct 2000 12:34:51 -0400 (EDT)
Subject: [Python-Dev] Small memory leak in unicodeobject.c
Message-ID: <14810.2731.466997.243906@anthem.concentric.net>

I've found a small memory leak in unicodeobject.c, in the way
_PyUnicode_Fini() shuts down.  Take a loop such as:

-------------------- snip snip --------------------
#include "Python.h"

int main(int argc, char** argv)
{
    int i;

    while (1) {
        Py_Initialize();
        Py_Finalize();
    }
    return 0;
}
-------------------- snip snip --------------------

and you'll find that unicode_empty leaks.  This is because, while
_PyUnicode_Fini() decrefs unicode_empty, it never actually gets
freed.  Instead it gets placed on the already freed unicode_freelist!
See _PyUnicode_Free() for why.

I've come up with the following nasty hack to force unicode_empty to
really be freed in _PyUnicode_Fini().  Maybe there's a better way to
do this.  Note that moving the decref of unicode_empty to above the
freeing of unicode_freelist didn't plug the memory leak for me (but
I'm quite tired so maybe I missed something! ;} ).

Below is the proposed patch.
-Barry

-------------------- snip snip --------------------
Index: unicodeobject.c
===================================================================
RCS file: /cvsroot/python/python/dist/src/Objects/unicodeobject.c,v
retrieving revision 2.64
diff -u -r2.64 unicodeobject.c
--- unicodeobject.c	2000/09/26 05:46:01	2.64
+++ unicodeobject.c	2000/10/03 16:31:32
@@ -5234,7 +5234,11 @@
 	PyObject_DEL(v);
     }
     unicode_freelist = NULL;
-    unicode_freelist_size = 0;
+    /* XXX This is a hack to force the freeing of unicode_empty's memory.
+     * Otherwise, it'll get placed on the already freed free list.
+     */
+    unicode_freelist_size = MAX_UNICODE_FREELIST_SIZE;
     Py_XDECREF(unicode_empty);
     unicode_empty = NULL;
+    unicode_freelist_size = 0;
 }


From Fredrik Lundh" <effbot@telia.com  Tue Oct  3 18:08:05 2000
From: Fredrik Lundh" <effbot@telia.com (Fredrik Lundh)
Date: Tue, 3 Oct 2000 19:08:05 +0200
Subject: [Python-Dev] Canvas.Canvas.bbox() return value
References: <200010031731.MAA08827@cj20424-a.reston1.va.home.com>
Message-ID: <001801c02d5c$801d0300$766940d5@hagrid>

> Hi Fredrik,
> 
> Re this bug report:
> 
> http://sourceforge.net/bugs/?func=detailbug&bug_id=110677&group_id=5470
> 
> I can take care of the Canvas issues, but I need your advice on
> bbox().  He's right that the bbox() method the Canvas class in the
> Canvas module is different from all other bbox() methods: it returns a
> tuple of tuples ((x1,y1),(x2,y2)) instead of a flat 4-tuple
> (x,y1,x2,y2).
> 
> Do you think it's worth not breaking existing code here???

no idea -- I don't think I've ever used that module (!).

(I'd deprecate the entire module if I were in charge -- there
are better ways to put objects on the canvas)

but in case someone's using it, it's probably best to leave things
as they are...

</F>



From thomas@xs4all.net  Tue Oct  3 18:07:11 2000
From: thomas@xs4all.net (Thomas Wouters)
Date: Tue, 3 Oct 2000 19:07:11 +0200
Subject: [Python-Dev] Suggested change for Setup.in
In-Reply-To: <14809.64935.157146.681813@anthem.concentric.net>; from bwarsaw@beopen.com on Tue, Oct 03, 2000 at 11:39:19AM -0400
References: <14809.64935.157146.681813@anthem.concentric.net>
Message-ID: <20001003190711.D12812@xs4all.nl>

On Tue, Oct 03, 2000 at 11:39:19AM -0400, Barry A. Warsaw wrote:

> but Setup.in has this suggestion, which I think is too hard for people
> to figure out what to do:

>     zlib zlibmodule.c -I$(prefix)/include -L$(exec_prefix)/lib -lz

> The standard build options will already include the right -I and -L
> flags for this to Just Work.  I suggest we make the common case
> (Linux?) simple, and let others figure out what the right -I and -L
> flags are.  I submit that even if they /do/ have to handcraft -I and
> -L, the defaults in Setup.in are pretty meaningless.

> A worthy change?  For 2.0 final?

What about including both -I$(prefix)/include and -L$(exec_prefix)/lib by
default, for all modules, if those directories already exist ? Because zlib
is not the only module that has this problem. On BSDI and Solaris, the
same problem exists for curses, readline and gdbm, at least. If you are
installing in a completely separate tree, for whatever reason, either those
include/lib directories won't exist, they won't contain anything useful, or
they will contain the actual libraries you want to link with, anyway ;-P

And if you are installing in a 'standard' tree, like /usr, /usr/local,
/usr/contrib, /opt, or whatever, the optional GNU stuff is likely to be
there, too. If you don't fall under any of these cases, you'll have to do
what you have to do now, figure it out by hand.

I don't think changing the zlib line alone is going to matter much; it stops
working 'out of the box' for the slightly-less common case of non-linux
platforms (and not even all linux platforms ! There is no reason why a
distribution would install zlib in /usr.) I would prefer adding a
comment that clarifies the -I/-L lines, over removing them altogether, if we
aren't including $prefix/include and $exec_prefix/lib by default.

I-compile-on-BSDI-a-lot--and-every-little-bit-helps-;-)

-- 
Thomas Wouters <thomas@xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!


From jeremy@beopen.com  Tue Oct  3 18:13:39 2000
From: jeremy@beopen.com (Jeremy Hylton)
Date: Tue, 3 Oct 2000 13:13:39 -0400 (EDT)
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/test test_pty.py,1.4,1.5
In-Reply-To: <200010031651.JAA06853@slayer.i.sourceforge.net>
References: <200010031651.JAA06853@slayer.i.sourceforge.net>
Message-ID: <14810.5059.445654.876073@bitdiddle.concentric.net>

Thomas,

Thanks for taking care of this.  One nit on the checkin procedure,
pleae reference the SF bug number when you're fixing a bug.  Also,
report the revision number of the changed file when you close the bug.

Thanks,
Jeremy


From fdrake@beopen.com  Tue Oct  3 18:08:06 2000
From: fdrake@beopen.com (Fred L. Drake, Jr.)
Date: Tue, 3 Oct 2000 13:08:06 -0400 (EDT)
Subject: [Python-Dev] Suggested change for Setup.in
In-Reply-To: <14809.64935.157146.681813@anthem.concentric.net>
References: <14809.64935.157146.681813@anthem.concentric.net>
Message-ID: <14810.4726.855657.955145@cj42289-a.reston1.va.home.com>

Barry A. Warsaw writes:
 > A worthy change?  For 2.0 final?

  This is good; even better would be the configure magic to make it
work automatically, similar to what we have for bsddb.  Given the
short time frame, your approach is good.  There may be other modules
that need similar adjustments in Setup.in.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member



From mal@lemburg.com  Tue Oct  3 18:13:40 2000
From: mal@lemburg.com (M.-A. Lemburg)
Date: Tue, 03 Oct 2000 19:13:40 +0200
Subject: [Python-Dev] Small memory leak in unicodeobject.c
References: <14810.2731.466997.243906@anthem.concentric.net>
Message-ID: <39DA13C4.B1855D9A@lemburg.com>

"Barry A. Warsaw" wrote:
> 
> I've found a small memory leak in unicodeobject.c, in the way
> _PyUnicode_Fini() shuts down.  Take a loop such as:
> 
> -------------------- snip snip --------------------
> #include "Python.h"
> 
> int main(int argc, char** argv)
> {
>     int i;
> 
>     while (1) {
>         Py_Initialize();
>         Py_Finalize();
>     }
>     return 0;
> }
> -------------------- snip snip --------------------
> 
> and you'll find that unicode_empty leaks.  This is because, while
> _PyUnicode_Fini() decrefs unicode_empty, it never actually gets
> freed.  Instead it gets placed on the already freed unicode_freelist!
> See _PyUnicode_Free() for why.
> 
> I've come up with the following nasty hack to force unicode_empty to
> really be freed in _PyUnicode_Fini().  Maybe there's a better way to
> do this.  Note that moving the decref of unicode_empty to above the
> freeing of unicode_freelist didn't plug the memory leak for me (but
> I'm quite tired so maybe I missed something! ;} ).

It would be easier to simply move the Py_DECREF() in front of the
cleanup code for the free list. That way, unicode_empty would
be placed on the free list, but then immedialtely cleaned up
by the following code.

Should I check in such a patch ?
 
> Below is the proposed patch.
> -Barry
> 
> -------------------- snip snip --------------------
> Index: unicodeobject.c
> ===================================================================
> RCS file: /cvsroot/python/python/dist/src/Objects/unicodeobject.c,v
> retrieving revision 2.64
> diff -u -r2.64 unicodeobject.c
> --- unicodeobject.c     2000/09/26 05:46:01     2.64
> +++ unicodeobject.c     2000/10/03 16:31:32
> @@ -5234,7 +5234,11 @@
>         PyObject_DEL(v);
>      }
>      unicode_freelist = NULL;
> -    unicode_freelist_size = 0;
> +    /* XXX This is a hack to force the freeing of unicode_empty's memory.
> +     * Otherwise, it'll get placed on the already freed free list.
> +     */
> +    unicode_freelist_size = MAX_UNICODE_FREELIST_SIZE;
>      Py_XDECREF(unicode_empty);
>      unicode_empty = NULL;
> +    unicode_freelist_size = 0;
>  }
> 
> _______________________________________________
> Python-Dev mailing list
> Python-Dev@python.org
> http://www.python.org/mailman/listinfo/python-dev

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/


From guido@python.org  Tue Oct  3 19:28:08 2000
From: guido@python.org (Guido van Rossum)
Date: Tue, 03 Oct 2000 13:28:08 -0500
Subject: [Python-Dev] Suggested change for Setup.in
In-Reply-To: Your message of "Tue, 03 Oct 2000 11:39:19 -0400."
 <14809.64935.157146.681813@anthem.concentric.net>
References: <14809.64935.157146.681813@anthem.concentric.net>
Message-ID: <200010031828.NAA09229@cj20424-a.reston1.va.home.com>

> I have a small suggestion for Modules/Setup.in.  On Linux (RH6.1) with
> the zlib rpm installed, all I need to enable this module is the
> following line:
> 
>     zlib zlibmodule.c -lz
> 
> but Setup.in has this suggestion, which I think is too hard for people
> to figure out what to do:
> 
>     zlib zlibmodule.c -I$(prefix)/include -L$(exec_prefix)/lib -lz
> 
> The standard build options will already include the right -I and -L
> flags for this to Just Work.  I suggest we make the common case
> (Linux?) simple, and let others figure out what the right -I and -L
> flags are.  I submit that even if they /do/ have to handcraft -I and
> -L, the defaults in Setup.in are pretty meaningless.
> 
> A worthy change?  For 2.0 final?

Check it in right now.

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


From Fredrik Lundh" <effbot@telia.com  Tue Oct  3 18:54:44 2000
From: Fredrik Lundh" <effbot@telia.com (Fredrik Lundh)
Date: Tue, 3 Oct 2000 19:54:44 +0200
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/test test_pty.py,1.4,1.5
References: <200010031651.JAA06853@slayer.i.sourceforge.net> <14810.5059.445654.876073@bitdiddle.concentric.net>
Message-ID: <005901c02d63$05cb5dc0$766940d5@hagrid>

> Thanks for taking care of this.  One nit on the checkin procedure,
> pleae reference the SF bug number when you're fixing a bug.  Also,
> report the revision number of the changed file when you close the bug.

do you really need both?  the former is easy, the latter is more
of a PITA, at least with the CVS setup I'm using here...

</F>



From guido@python.org  Tue Oct  3 19:58:20 2000
From: guido@python.org (Guido van Rossum)
Date: Tue, 03 Oct 2000 13:58:20 -0500
Subject: [Python-Dev] Small memory leak in unicodeobject.c
In-Reply-To: Your message of "Tue, 03 Oct 2000 12:34:51 -0400."
 <14810.2731.466997.243906@anthem.concentric.net>
References: <14810.2731.466997.243906@anthem.concentric.net>
Message-ID: <200010031858.NAA09564@cj20424-a.reston1.va.home.com>

> Index: unicodeobject.c
> ===================================================================
> RCS file: /cvsroot/python/python/dist/src/Objects/unicodeobject.c,v
> retrieving revision 2.64
> diff -u -r2.64 unicodeobject.c
> --- unicodeobject.c	2000/09/26 05:46:01	2.64
> +++ unicodeobject.c	2000/10/03 16:31:32
> @@ -5234,7 +5234,11 @@
>  	PyObject_DEL(v);
>      }
>      unicode_freelist = NULL;
> -    unicode_freelist_size = 0;
> +    /* XXX This is a hack to force the freeing of unicode_empty's memory.
> +     * Otherwise, it'll get placed on the already freed free list.
> +     */
> +    unicode_freelist_size = MAX_UNICODE_FREELIST_SIZE;
>      Py_XDECREF(unicode_empty);
>      unicode_empty = NULL;
> +    unicode_freelist_size = 0;
>  }

Doesn't it make more sense to decref unicode_empty sooner?  The loop
over the free list won't touch it:

Index: unicodeobject.c
===================================================================
RCS file: /cvsroot/python/python/dist/src/Objects/unicodeobject.c,v
retrieving revision 2.64
diff -c -r2.64 unicodeobject.c
*** unicodeobject.c	2000/09/26 05:46:01	2.64
--- unicodeobject.c	2000/10/03 17:55:34
***************
*** 5225,5230 ****
--- 5225,5232 ----
  {
      PyUnicodeObject *u = unicode_freelist;
  
+     Py_XDECREF(unicode_empty);
+     unicode_empty = NULL;
      while (u != NULL) {
  	PyUnicodeObject *v = u;
  	u = *(PyUnicodeObject **)u;
***************
*** 5235,5240 ****
      }
      unicode_freelist = NULL;
      unicode_freelist_size = 0;
-     Py_XDECREF(unicode_empty);
-     unicode_empty = NULL;
  }
--- 5237,5240 ----


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


From mal@lemburg.com  Tue Oct  3 19:02:39 2000
From: mal@lemburg.com (M.-A. Lemburg)
Date: Tue, 03 Oct 2000 20:02:39 +0200
Subject: [Python-Dev] Small memory leak in unicodeobject.c
References: <14810.2731.466997.243906@anthem.concentric.net> <200010031858.NAA09564@cj20424-a.reston1.va.home.com>
Message-ID: <39DA1F3F.9EFA41EB@lemburg.com>

Guido van Rossum wrote:
> 
> > Index: unicodeobject.c
> > ===================================================================
> > RCS file: /cvsroot/python/python/dist/src/Objects/unicodeobject.c,v
> > retrieving revision 2.64
> > diff -u -r2.64 unicodeobject.c
> > --- unicodeobject.c   2000/09/26 05:46:01     2.64
> > +++ unicodeobject.c   2000/10/03 16:31:32
> > @@ -5234,7 +5234,11 @@
> >       PyObject_DEL(v);
> >      }
> >      unicode_freelist = NULL;
> > -    unicode_freelist_size = 0;
> > +    /* XXX This is a hack to force the freeing of unicode_empty's memory.
> > +     * Otherwise, it'll get placed on the already freed free list.
> > +     */
> > +    unicode_freelist_size = MAX_UNICODE_FREELIST_SIZE;
> >      Py_XDECREF(unicode_empty);
> >      unicode_empty = NULL;
> > +    unicode_freelist_size = 0;
> >  }
> 
> Doesn't it make more sense to decref unicode_empty sooner? 

Right. That's the change I proposed to Barry in my last mail.
Please check this in.

Thanks,
Marc-Andre

> The loop
> over the free list won't touch it:
> 
> Index: unicodeobject.c
> ===================================================================
> RCS file: /cvsroot/python/python/dist/src/Objects/unicodeobject.c,v
> retrieving revision 2.64
> diff -c -r2.64 unicodeobject.c
> *** unicodeobject.c     2000/09/26 05:46:01     2.64
> --- unicodeobject.c     2000/10/03 17:55:34
> ***************
> *** 5225,5230 ****
> --- 5225,5232 ----
>   {
>       PyUnicodeObject *u = unicode_freelist;
> 
> +     Py_XDECREF(unicode_empty);
> +     unicode_empty = NULL;
>       while (u != NULL) {
>         PyUnicodeObject *v = u;
>         u = *(PyUnicodeObject **)u;
> ***************
> *** 5235,5240 ****
>       }
>       unicode_freelist = NULL;
>       unicode_freelist_size = 0;
> -     Py_XDECREF(unicode_empty);
> -     unicode_empty = NULL;
>   }
> --- 5237,5240 ----
> 
> --Guido van Rossum (home page: http://www.python.org/~guido/)
> 
> _______________________________________________
> Python-Dev mailing list
> Python-Dev@python.org
> http://www.python.org/mailman/listinfo/python-dev

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/


From bwarsaw@beopen.com  Tue Oct  3 21:35:10 2000
From: bwarsaw@beopen.com (Barry A. Warsaw)
Date: Tue, 3 Oct 2000 16:35:10 -0400 (EDT)
Subject: [Python-Dev] Small memory leak in unicodeobject.c
References: <14810.2731.466997.243906@anthem.concentric.net>
 <39DA13C4.B1855D9A@lemburg.com>
Message-ID: <14810.17150.777092.128211@anthem.concentric.net>

>>>>> "M" == M  <mal@lemburg.com> writes:

    M> It would be easier to simply move the Py_DECREF() in front of
    M> the cleanup code for the free list. That way, unicode_empty
    M> would be placed on the free list, but then immedialtely cleaned
    M> up by the following code.

I know that's the obvious fix -- and it was the first thing I tried,
but it doesn't work!  (I thought I mentioned that in my original
message).

Verifying after a cvs up still shows unicode_empty leaking (I loop
through the Py_Initialize/Py_Finalize loop 10 times):

-------------------- snip snip --------------------
       240 bytes     10 chunks allocated at unicodeobject.c, 227
                          malloc()
                  _PyUnicode_New()  unicodeobject.c, 227
                 _PyUnicode_Init()  unicodeobject.c, 5217
                   Py_Initialize()  pythonrun.c, 125
                            main()
        30 bytes     10 chunks allocated at unicodeobject.c, 230
                          malloc()
                  _PyUnicode_New()  unicodeobject.c, 230
                 _PyUnicode_Init()  unicodeobject.c, 5217
                   Py_Initialize()  pythonrun.c, 125
                            main()
-------------------- snip snip --------------------

So let me step through the code and figure out what's wrong...

-Barry


From loewis@informatik.hu-berlin.de  Tue Oct  3 21:39:06 2000
From: loewis@informatik.hu-berlin.de (Martin von Loewis)
Date: Tue, 3 Oct 2000 22:39:06 +0200 (MET DST)
Subject: [Python-Dev] Release candidate followed by feature freeze?
Message-ID: <200010032039.WAA27659@pandora.informatik.hu-berlin.de>

> It would be hard to sell Python for important applications,
> e.g. long-running server processes, if there was a small possibility
> that the program could crash through no fault of its own.

There is always a small possibility that the program could crash
through no faults of its own - i.e. I don't believe that Python is bug
free without gc. I'd agree that bugs in the gc are more serious than
other bugs.

If it turns out that there are serious bugs in 2.0 (whether in the gc
or elsewhere), I'd hope BeOpen will release 2.0.1 shortly after they
get fixed.

Regards,
Martin


From bwarsaw@beopen.com  Tue Oct  3 21:42:25 2000
From: bwarsaw@beopen.com (Barry A. Warsaw)
Date: Tue, 3 Oct 2000 16:42:25 -0400 (EDT)
Subject: [Python-Dev] Small memory leak in unicodeobject.c
References: <14810.2731.466997.243906@anthem.concentric.net>
 <39DA13C4.B1855D9A@lemburg.com>
Message-ID: <14810.17585.567814.278594@anthem.concentric.net>

Oh the problem is obvious.  You have to initialize the local variable
`u' /after/ unicode_empty is freed otherwise it doesn't point to the
proper start of the free list.

I'll check that change in.
-Barry


From MarkH@ActiveState.com  Tue Oct  3 23:58:14 2000
From: MarkH@ActiveState.com (Mark Hammond)
Date: Wed, 4 Oct 2000 09:58:14 +1100
Subject: [Python-Dev] pep42 procedure?
Message-ID: <ECEPKNMJLHAPFFJHDOJBOEAJDMAA.MarkH@ActiveState.com>

Please excuse my ignorance...

I am in the process of applying the patch to prevent 1.5/1.6 extensions
crashing 2.0 under Windows.

Based on the feedback here (ie, "this should be a short term patch"), the
various other patches that try to do the same thing, and the belief by some
that we should be more like Unix anyway, I believe we should try and
capture this entire issue in a more formal manner.

The 2 logical places would be as a bug, and in pep42.  However, after
applying this patch, it doesnt really qualify as a bug!  Putting it in
pep42 is slightly suspect, as it is not a thought-out feature request yet -
however, I believe capturing it there, with links to the relevant patches
and discussions would be valuable.

So, assuming this sounds reasonable - a bug, or pep42?  If pep42, what is
the procedure for changing it?  I couldnt find it (or any pep) in the CVS
repository, and the source-force pages would show me the peps, but not
their source.  I do remember seeing this mentioned some time ago, but can't
locate that mail either...

Thanks,

Mark.



From trentm@ActiveState.com  Wed Oct  4 00:08:09 2000
From: trentm@ActiveState.com (Trent Mick)
Date: Tue, 3 Oct 2000 16:08:09 -0700
Subject: [Python-Dev] change to Lib/popen2.py break test_popen2 on windows
Message-ID: <20001003160809.A18387@ActiveState.com>

Fred's checkin:
http://www.python.org/pipermail/python-checkins/2000-September/008355.html
breaks test_popen2.py on windows.

This is because test_popen2.py attempts to refer to popen2's internal
'_active' variable, which is now explicitly deleted on Windows platforms.

test_popen2.py should be updated for the new popen2 semantics.


sorry-no-patch-ly yours,
Trent

-- 
Trent Mick
TrentM@ActiveState.com


From trentm@ActiveState.com  Wed Oct  4 00:10:09 2000
From: trentm@ActiveState.com (Trent Mick)
Date: Tue, 3 Oct 2000 16:10:09 -0700
Subject: [Python-Dev] change to Lib/popen2.py break test_popen2 on windows
In-Reply-To: <20001003160809.A18387@ActiveState.com>; from trentm@ActiveState.com on Tue, Oct 03, 2000 at 04:08:09PM -0700
References: <20001003160809.A18387@ActiveState.com>
Message-ID: <20001003161009.B18387@ActiveState.com>

On Tue, Oct 03, 2000 at 04:08:09PM -0700, Trent Mick wrote:
> 
> Fred's checkin:
> http://www.python.org/pipermail/python-checkins/2000-September/008355.html
> breaks test_popen2.py on windows.
> 
> This is because test_popen2.py attempts to refer to popen2's internal
> '_active' variable, which is now explicitly deleted on Windows platforms.
> 
> test_popen2.py should be updated for the new popen2 semantics.
> 

Geez, you are fast Tim! (for others: he patched test_popen.py after I sent my
email but before my email made it to python-dev!)


Trent


-- 
Trent Mick
TrentM@ActiveState.com


From skip@mojam.com (Skip Montanaro)  Wed Oct  4 01:54:55 2000
From: skip@mojam.com (Skip Montanaro) (Skip Montanaro)
Date: Tue, 3 Oct 2000 19:54:55 -0500 (CDT)
Subject: [Python-Dev] pep42 procedure?
In-Reply-To: <ECEPKNMJLHAPFFJHDOJBOEAJDMAA.MarkH@ActiveState.com>
References: <ECEPKNMJLHAPFFJHDOJBOEAJDMAA.MarkH@ActiveState.com>
Message-ID: <14810.32735.229954.547385@beluga.mojam.com>

    Mark> So, assuming this sounds reasonable - a bug, or pep42?  

I think neither.  This topic seems to have generated a lot of discussion.  I
think it deserves a bit more elaboration than what you'd find reasonable for
pep42.  Also, it would be kinda nice to add it to the Python FAQ with a
reference to a specific pep for all the gory details of the problem and
solution(s).

Skip


From MarkH@ActiveState.com  Wed Oct  4 04:58:25 2000
From: MarkH@ActiveState.com (Mark Hammond)
Date: Wed, 4 Oct 2000 14:58:25 +1100
Subject: [Python-Dev] pep42 procedure?
In-Reply-To: <14810.32735.229954.547385@beluga.mojam.com>
Message-ID: <ECEPKNMJLHAPFFJHDOJBAEBJDMAA.MarkH@ActiveState.com>

> I think neither.  This topic seems to have generated a lot of
> discussion.  I
> think it deserves a bit more elaboration than what you'd find
> reasonable for
> pep42.  Also, it would be kinda nice to add it to the Python FAQ with a
> reference to a specific pep for all the gory details of the problem and
> solution(s).

That would be a great idea, if only we had a PEP author.  To be honest, I
really dont care too much about this issue, and have been doing my level
best to avoid it.  But Tim knows that, and delights in assigning related
patches to me ;-)  I certainly don't care enough to own a pep on it.

The way things stand, I have a checkin ready to go, and am unwilling to
commit to any sort of pep in the short or medium term.  The best I could do
is to add links to the 3 or 4 other patches submitted for the same thing,
and pep42 seemed ideal.

So given this, what should I do - just check it in, and leave it to the
collective memory? ;-)

Mark.



From tim_one@email.msn.com  Wed Oct  4 05:58:46 2000
From: tim_one@email.msn.com (Tim Peters)
Date: Wed, 4 Oct 2000 00:58:46 -0400
Subject: [Python-Dev] CIV
Message-ID: <LNBBLJKPBEHFEDALKOLCAEIDHJAA.tim_one@email.msn.com>

No, that's not 104, it's a Call for Indentation Volunteers!

An item that mistakenly got dropped on the floor before 2.0b1 was to ensure
that the standard Python libraries follow the recommended "4-space indents,
no hard tabs" guideline.  Since 100s of files (especially older ones in
oddball directories) are affected, I moved that it into PEP42 rather than
risk destabilizing the release after 2.0b1.

So it will happen instead soon after 2.0final is released.  I looked at
existing tools for doing this, and found they all left way too much manual
fiddling to bear,  too prone to screw up on comment lines (e.g., try running
your favorite tool over pindent.py:  does the output bear any resemblance to
the input?!  The Emacs pymode does OK there because pindent comments match
its conventions for "indenting comment lines", but nothing else even gets
close; OTOH,

    if 1:    # some insane people like
             # writing comments
             # like this too

and nobody knows what to do about that).

Attached is a new tool that tries much harder to get perverse comments right
(everything else is easy).  Try it and gripe at will.  Since I wrote it
while on vacation, it's public domain <0.5 wink>.

regularly y'rs  - tim

#! /usr/bin/env python

# Released to the public domain, by Tim Peters, 03 October 2000.

"""reindent [-d][-r][-v] path ...

-d  Dry run.  Analyze, but don't make any changes to, files.
-r  Recurse.  Search for all .py files in subdirectories too.
-v  Verbose.  Print informative msgs; else no output.

Change Python (.py) files to use 4-space indents and no hard tab characters.
Also trim excess whitespace from ends of lines, and empty lines at the ends
of files.  Ensure the last line ends with a newline.

Pass one or more file and/or directory paths.  When a directory path, all
.py files within the directory will be examined, and, if the -r option is
given, likewise recursively for subdirectories.

Overwrites files in place, renaming the originals with a .bak extension.
If reindent finds nothing to change, the file is left alone.  If reindent
does change a file, the changed file is a fixed-point for reindent (i.e.,
running reindent on the resulting .py file won't change it again).

The hard part of reindenting is figuring out what to do with comment
lines.  So long as the input files get a clean bill of health from
tabnanny.py, reindent should do a good job.
"""

import tokenize
import os
import sys

verbose = 0
recurse = 0
dryrun  = 0

def errprint(*args):
    sep = ""
    for arg in args:
        sys.stderr.write(sep + str(arg))
        sep = " "
    sys.stderr.write("\n")

def main():
    import getopt
    global verbose, recurse, dryrun
    try:
        opts, args = getopt.getopt(sys.argv[1:], "drv")
    except getopt.error, msg:
        errprint(msg)
        return
    for o, a in opts:
        if o == '-d':
            dryrun += 1
        elif o == '-r':
            recurse += 1
        elif o == '-v':
            verbose += 1
    if not args:
        errprint("Usage:", __doc__)
        return
    for arg in args:
        check(arg)

def check(file):
    if os.path.isdir(file) and not os.path.islink(file):
        if verbose:
            print "listing directory", file
        names = os.listdir(file)
        for name in names:
            fullname = os.path.join(file, name)
            if ((recurse and os.path.isdir(fullname) and
                 not os.path.islink(fullname))
                or name.lower().endswith(".py")):
                check(fullname)
        return

    if verbose:
        print "checking", file, "...",
    try:
        f = open(file)
    except IOError, msg:
        errprint("%s: I/O Error: %s" % (file, str(msg)))
        return

    r = Reindenter(f)
    f.close()
    if r.run():
        if verbose:
            print "changed."
            if dryrun:
                print "But this is a dry run, so leaving it alone."
        if not dryrun:
            bak = file + ".bak"
            if os.path.exists(bak):
                os.remove(bak)
            os.rename(file, bak)
            if verbose:
                print "renamed", file, "to", bak
            f = open(file, "w")
            r.write(f)
            f.close()
            if verbose:
                print "wrote new", file
    else:
        if verbose:
            print "unchanged."

class Reindenter:

    def __init__(self, f):
        self.find_stmt = 1  # next token begins a fresh stmt?
        self.level = 0      # current indent level

        # Raw file lines.
        self.raw = f.readlines()

        # File lines, rstripped & tab-expanded.  Dummy at start is so
        # that we can use tokenize's 1-based line numbering easily.
        # Note that a line is all-blank iff it's "\n".
        self.lines = [line.rstrip().expandtabs() + "\n"
                      for line in self.raw]
        self.lines.insert(0, None)
        self.index = 1  # index into self.lines of next line

        # List of (lineno, indentlevel) pairs, one for each stmt and
        # comment line.  indentlevel is -1 for comment lines, as a
        # signal that tokenize doesn't know what to do about them;
        # indeed, they're our headache!
        self.stats = []

    def run(self):
        tokenize.tokenize(self.getline, self.tokeneater)
        # Remove trailing empty lines.
        lines = self.lines
        while lines and lines[-1] == "\n":
            lines.pop()
        # Sentinel.
        stats = self.stats
        stats.append((len(lines), 0))
        # Map count of leading spaces to # we want.
        have2want = {}
        # Program after transformation.
        after = self.after = []
        for i in range(len(stats)-1):
            thisstmt, thislevel = stats[i]
            nextstmt = stats[i+1][0]
            have = getlspace(lines[thisstmt])
            want = thislevel * 4
            if want < 0:
                # A comment line.
                if have:
                    # An indented comment line.  If we saw the same
                    # indentation before, reuse what it most recently
                    # mapped to.
                    want = have2want.get(have, -1)
                    if want < 0:
                        # Then it probably belongs to the next real stmt.
                        for j in xrange(i+1, len(stats)-1):
                            jline, jlevel = stats[j]
                            if jlevel >= 0:
                                if have == getlspace(lines[jline]):
                                    want = jlevel * 4
                                break
                    if want < 0:           # Maybe it's a hanging
                                           # comment like this one,
                        # in which case we should shift it like its base
                        # line got shifted.
                        for j in xrange(i-1, -1, -1):
                            jline, jlevel = stats[j]
                            if jlevel >= 0:
                                want = have + getlspace(after[jline-1]) - \
                                       getlspace(lines[jline])
                                break
                    if want < 0:
                        # Still no luck -- leave it alone.
                        want = have
                else:
                    want = 0
            assert want >= 0
            have2want[have] = want
            diff = want - have
            if diff == 0 or have == 0:
                after.extend(lines[thisstmt:nextstmt])
            else:
                for line in lines[thisstmt:nextstmt]:
                    if diff > 0:
                        if line == "\n":
                            after.append(line)
                        else:
                            after.append(" " * diff + line)
                    else:
                        remove = min(getlspace(line), -diff)
                        after.append(line[remove:])
        return self.raw != self.after

    def write(self, f):
        f.writelines(self.after)

    # Line-getter for tokenize.
    def getline(self):
        if self.index >= len(self.lines):
            line = ""
        else:
            line = self.lines[self.index]
            self.index += 1
        return line

    # Line-eater for tokenize.
    def tokeneater(self, type, token, (sline, scol), end, line,
                   INDENT=tokenize.INDENT,
                   DEDENT=tokenize.DEDENT,
                   NEWLINE=tokenize.NEWLINE,
                   COMMENT=tokenize.COMMENT,
                   NL=tokenize.NL):

        if type == NEWLINE:
            # A program statement, or ENDMARKER, will eventually follow,
            # after some (possibly empty) run of tokens of the form
            #     (NL | COMMENT)* (INDENT | DEDENT+)?
            self.find_stmt = 1

        elif type == INDENT:
            self.find_stmt = 1
            self.level += 1

        elif type == DEDENT:
            self.find_stmt = 1
            self.level -= 1

        elif type == COMMENT:
            if self.find_stmt:
                self.stats.append((sline, -1))
                # but we're still looking for a new stmt, so leave
                # find_stmt alone

        elif type == NL:
            pass

        elif self.find_stmt:
            # This is the first "real token" following a NEWLINE, so it
            # must be the first token of the next program statement, or an
            # ENDMARKER.
            self.find_stmt = 0
            if line:   # not endmarker
                self.stats.append((sline, self.level))

# Count number of leading blanks.
def getlspace(line):
    i, n = 0, len(line)
    while i < n and line[i] == " ":
        i += 1
    return i

if __name__ == '__main__':
    main()




From bwarsaw@beopen.com  Wed Oct  4 07:06:14 2000
From: bwarsaw@beopen.com (Barry A. Warsaw)
Date: Wed, 4 Oct 2000 02:06:14 -0400 (EDT)
Subject: [Python-Dev] pep42 procedure?
References: <ECEPKNMJLHAPFFJHDOJBOEAJDMAA.MarkH@ActiveState.com>
Message-ID: <14810.51414.59852.855231@anthem.concentric.net>

>>>>> "MH" == Mark Hammond <MarkH@ActiveState.com> writes:

    MH> I couldnt find it (or any pep) in the CVS repository, and the
    MH> source-force pages would show me the peps, but not their
    MH> source.

The PEPs are located in the nondist directory, under nondist/peps!

-Barry


From bwarsaw@beopen.com  Wed Oct  4 07:07:06 2000
From: bwarsaw@beopen.com (Barry A. Warsaw)
Date: Wed, 4 Oct 2000 02:07:06 -0400 (EDT)
Subject: [Python-Dev] forwarded message from aahz@panix.com
Message-ID: <14810.51466.486982.938180@anthem.concentric.net>

Return-Path: <aahz@panix.com>
Delivered-To: bwarsaw@mail.wooz.org
Received: from ns1.beopen.com (unknown [208.185.174.104])
	by mail.wooz.org (Postfix) with ESMTP id 02DB0D37D5
	for <barry@wooz.org>; Tue,  3 Oct 2000 19:28:09 -0400 (EDT)
Received: from mail2.panix.com (mail2.panix.com [166.84.0.213])
	by ns1.beopen.com (8.9.3/8.9.3) with ESMTP id QAA66074
	for <bwarsaw@beopen.com>; Tue, 3 Oct 2000 16:28:36 -0700 (PDT)
	(envelope-from aahz@panix.com)
Received: from panix6.panix.com (panix6.panix.com [166.84.0.231])
	by mail2.panix.com (Postfix) with ESMTP id 4CD318F00
	for <bwarsaw@beopen.com>; Tue,  3 Oct 2000 19:26:33 -0400 (EDT)
Received: (from aahz@localhost) by panix6.panix.com (8.8.8/8.7.1/PanixN1.0) id TAA27108 for bwarsaw@beopen.com; Tue, 3 Oct 2000 19:26:33 -0400 (EDT)
Message-Id: <200010032326.TAA27108@panix6.panix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
From: aahz@panix.com
To: bwarsaw@beopen.com
Subject: htmllib.HTMLescape()
Date: Tue, 3 Oct 2000 16:26:32 -0700 (PDT)
X-Mailer: ELM [version 2.5 PL3]
Reply-To: aahz@pobox.com

Someone just pointed out on c.l.py that we need an HTMLescape() function
that takes a string and converts special characters to entities.  I'm
not on python-dev, so could you please forward this and find out whether
I need to run a PEP?
-- 
                      --- Aahz (Copyright 2000 by aahz@pobox.com)

Androgynous poly kinky vanilla queer het    <*>     http://www.rahul.net/aahz/
Hugs and backrubs -- I break Rule 6

There's a difference between a person who gets shit zie doesn't
deserve and a person who gets more shit than zie deserves.  --Aahz


From thomas@xs4all.net  Wed Oct  4 07:16:58 2000
From: thomas@xs4all.net (Thomas Wouters)
Date: Wed, 4 Oct 2000 08:16:58 +0200
Subject: [Python-Dev] pep42 procedure?
In-Reply-To: <ECEPKNMJLHAPFFJHDOJBAEBJDMAA.MarkH@ActiveState.com>; from MarkH@ActiveState.com on Wed, Oct 04, 2000 at 02:58:25PM +1100
References: <14810.32735.229954.547385@beluga.mojam.com> <ECEPKNMJLHAPFFJHDOJBAEBJDMAA.MarkH@ActiveState.com>
Message-ID: <20001004081658.E12812@xs4all.nl>

On Wed, Oct 04, 2000 at 02:58:25PM +1100, Mark Hammond wrote:

[ Mark wants to apply a patch that prevents crashes on windows when loading
extentions linked with old Python DLLs, but doesn't know where to document
it: PEP 42 or the bug report(s) ]

[ Skip proposes a separate PEP ]

[ Mark doesn't have time to write a PEP ]

> So given this, what should I do - just check it in, and leave it to the
> collective memory? ;-)

PEP 42 is the meaning of life PEP, meaning that it's everything that needs
to be done before python-dev can rest in pieces. I don't think that a solved
issue is in its place there, even if it had such a section. A PEP on its own
would probably be the best spot, because even if it's a 'temporary' solution
now, we or someone else might need the info later. And a PEP doesn't have to
be that hard to write ;)

And besides, you don't have to be the person to write the PEP, someone else
can. And if noone suitable volunteers, perhaps a checkin-message giving
'full' documentation, the necessary sourcecode comments and a reference to
both in the bugreport message will suffice... But I'm willing to PEPify
whatever docs or comments you write on this issue, Mark. I will need some
guidance on what exactly is the issue, but I'm sure I'll get that from one
of you Windows lovers ! :-)

And no, I don't think Python should be more like UNIX. Windows, yes, but
it's not Python's job to turn Windows into a halfhearted UNIX ;-P Besides,
that would only alienate the Windows users with Uni(x)fobia.

Unix-unix-unix-ly y'rs,

-- 
Thomas Wouters <thomas@xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!


From ping@lfw.org  Wed Oct  4 12:02:51 2000
From: ping@lfw.org (Ka-Ping Yee)
Date: Wed, 4 Oct 2000 04:02:51 -0700 (PDT)
Subject: [Python-Dev] Installing python in /usr/bin
Message-ID: <Pine.LNX.4.10.10010040357390.4474-100000@skuld.kingmanhall.org>

The cgi.py discussion brought my attention to this comment from Guido:

> No, no, no!  The /usr/bin/env form *fails* on most platforms (except
> Linux) because Python is not installed in any of the default "bin"
> directories -- /usr/local/bin is the standard install place and that's
> not in the default path.

So the natural question to ask is -- why not install Python in /usr/bin
like everyone else?

Perhaps a while ago Python wasn't popular enough to belong in /usr/bin
and decided to modestly stay out of the way in /usr/local/bin instead?

But by now, i think it's quite qualified to take its seat in /usr/bin
along with all the other standard Unix binaries like /usr/bin/vi,
/usr/bin/ftp, /usr/bin/perl, etc.  Python *should* be in the default
binary directory.

Your thoughts?


-- ?!ng



From thomas@xs4all.net  Wed Oct  4 12:35:28 2000
From: thomas@xs4all.net (Thomas Wouters)
Date: Wed, 4 Oct 2000 13:35:28 +0200
Subject: [Python-Dev] Installing python in /usr/bin
In-Reply-To: <Pine.LNX.4.10.10010040357390.4474-100000@skuld.kingmanhall.org>; from ping@lfw.org on Wed, Oct 04, 2000 at 04:02:51AM -0700
References: <Pine.LNX.4.10.10010040357390.4474-100000@skuld.kingmanhall.org>
Message-ID: <20001004133528.G12812@xs4all.nl>

On Wed, Oct 04, 2000 at 04:02:51AM -0700, Ka-Ping Yee wrote:

> So the natural question to ask is -- why not install Python in /usr/bin
> like everyone else?

> Perhaps a while ago Python wasn't popular enough to belong in /usr/bin
> and decided to modestly stay out of the way in /usr/local/bin instead?

The only reason is the hysterical one: it's always been that way.
Traditionally, /usr/local/bin was the place for user-installed binaries.
This sets them apart from the the vendor-supplied binaries (commonly in /bin
and /usr/bin, where /bin are the tools necessary to boot and mount /usr, and
/usr/bin is the rest) and the vendor-installed 3rd-party binaries (commonly
in /usr/contrib/bin, or /opt/bin, or /opt/gnu/bin, and the like.)

> But by now, i think it's quite qualified to take its seat in /usr/bin
> along with all the other standard Unix binaries like /usr/bin/vi,
> /usr/bin/ftp, /usr/bin/perl, etc.  Python *should* be in the default
> binary directory.

Perl only resides in /usr/bin if the vendor (or distribution-maker, in the
case of the Free OSes) put it there. The default for Perl is /usr/local as
well. In fact, almost all source packages default to /usr/local; I have yet
to see a package that uses autoconf and does not have /usr/local as the
default prefix, for instance.

I think the best solution is just for every OS to put /usr/local/bin in
their path, and not pretend they delivered the Definitive Collection of
Useful Programs. Installing Python in /usr can do more damage than good --
think of all the people that are used to have it installed in /usr/local,
don't specify a prefix because they 'know' it's /usr/local by default, and
end up filling up their minimal /usr partition with Python ;)

-- 
Thomas Wouters <thomas@xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!


From gward@python.net  Tue Oct  3 05:08:45 2000
From: gward@python.net (Greg Ward)
Date: Tue, 3 Oct 2000 00:08:45 -0400
Subject: [Python-Dev] ANNOUNCE: Distutils 1.0
Message-ID: <mailman.970578302.4920.clpa-moderators@python.org>

                     Python Distribution Utilities
                              release 1.0
                            October 2, 2000

The Python Distribution Utilities, or Distutils for short, are a
collection of modules that aid in the development, distribution, and
installation of Python modules.  (It is intended that ultimately the
Distutils will grow up into a system for distributing and installing
whole Python applications, but for now their scope is limited to module
distributions.)

The Distutils are a standard part of Python 1.6 and 2.0; if you are running
1.6 or 2.0, you don't need to install the Distutils separately.  (However,
you might want to upgrade if you're running Python 1.6.)  This release is
primarily so that you can add the Distutils to a Python 1.5.2 installation
-- you will then be able to install modules that require the Distutils, or
use the Distutils to distribute your own modules.

Distutils 1.0 is the version that will be released with Python 2.0 (unless
last-minute bugs pop up).

More information is available at the Distutils web page:

    http://www.python.org/sigs/distutils-sig/

and in the README.txt included in the Distutils source distribution.

You can download the Distutils from

    http://www.python.org/sigs/distutils-sig/download.html

Trivial patches can be sent to me (Greg Ward) at gward@python.net.
Larger patches should be discussed on the Distutils mailing list:
distutils-sig@python.org.

        Greg
-- 
Greg Ward                                      gward@python.net
http://starship.python.net/~gward/
And now for something completely different.



From bwarsaw@beopen.com  Wed Oct  4 14:44:40 2000
From: bwarsaw@beopen.com (Barry A. Warsaw)
Date: Wed, 4 Oct 2000 09:44:40 -0400 (EDT)
Subject: [Python-Dev] Installing python in /usr/bin
References: <Pine.LNX.4.10.10010040357390.4474-100000@skuld.kingmanhall.org>
 <20001004133528.G12812@xs4all.nl>
Message-ID: <14811.13384.137080.196973@anthem.concentric.net>

>>>>> "TW" == Thomas Wouters <thomas@xs4all.net> writes:

    TW> The only reason is the hysterical one: it's always been that
    TW> way.  Traditionally, /usr/local/bin was the place for
    TW> user-installed binaries.

Yes exactly.

And in fact on my RH6.1 system, I have Python in both /usr/bin and
/usr/local/bin.  RedHat sticks its rpms in /usr/bin, and right now,
1.5.2 resides there.  My dev copy gets installed from source into
/usr/local/bin, and that's the current CVS snapshot.  This is as it
should be and all is right in the world.

The rule is -- and ought to be -- that the default install location in
a build-from-source distro is /usr/local.  rpms or other package
installs can install where ever is appropriate for that platform
(e.g. if someone were to build a Solaris pkg distro, it probably ought
to install to /opt by default).

if-it-ain't-broke...-ly y'rs,
-Barry


From nas@arctrix.com  Wed Oct  4 10:46:36 2000
From: nas@arctrix.com (Neil Schemenauer)
Date: Wed, 4 Oct 2000 02:46:36 -0700
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules cPickle.c,2.52,2.53
In-Reply-To: <200010041622.JAA17363@slayer.i.sourceforge.net>; from nascheme@users.sourceforge.net on Wed, Oct 04, 2000 at 09:22:31AM -0700
References: <200010041622.JAA17363@slayer.i.sourceforge.net>
Message-ID: <20001004024636.A13475@glacier.fnational.com>

On Wed, Oct 04, 2000 at 09:22:31AM -0700, Neil Schemenauer wrote:
> Update of /cvsroot/python/python/dist/src/Modules
> In directory slayer.i.sourceforge.net:/tmp/cvs-serv16887/Modules
> 
> Modified Files:
> 	cPickle.c 
> Log Message:
> - Fix a GC bug caused by PyDict_New() failing.
> 
> 
> Index: cPickle.c
> ===================================================================
> RCS file: /cvsroot/python/python/dist/src/Modules/cPickle.c,v
> retrieving revision 2.52
> retrieving revision 2.53
> diff -C2 -r2.52 -r2.53
> *** cPickle.c	2000/09/07 14:35:37	2.52
> --- cPickle.c	2000/10/04 16:22:26	2.53
> ***************
> *** 2876,2880 ****
>                 Py_INCREF(cls);
>                 UNLESS (inst->in_dict=PyDict_New()) {
> !                 Py_DECREF(inst);
>                   goto err;
>                 }
> --- 2876,2881 ----
>                 Py_INCREF(cls);
>                 UNLESS (inst->in_dict=PyDict_New()) {
> !                 inst = (PyInstanceObject *) PyObject_AS_GC(inst);
> !                 PyObject_DEL(inst);
>                   goto err;
>                 }

I aways seem to think harder when reviewing a commit message than
a diff. :(  I just realized that this commit subtly modifies
cPickle's behavior.  Before the change instances __del__ methods
would be called if allocating __dict__ failed.  After the change
they are not.  I think the new behavior is better but the
question is will it break existing code?  I think probably not.

BTW, pickle seems to follow the new behavior.

  Neil


From esr@snark.thyrsus.com  Wed Oct  4 18:17:39 2000
From: esr@snark.thyrsus.com (Eric S. Raymond)
Date: Wed, 4 Oct 2000 13:17:39 -0400
Subject: [Python-Dev] Proposal -- makefile patches and scripts to generate python RPMs
Message-ID: <200010041717.NAA03509@snark.thyrsus.com>

In the course of maintaining fetchmail, I've developed effective
techniques for integrating RPM and lsm generation into the release machinery
of a package.  I'm willing to do this for Python; it will involve
adding a makefile production and a couple of scripts to the
distribution.

The benefit would be that we could generate correct RPMs automatically
and ship them with each release.  I think RPM is a sufficiently
important distribution format to justify this effort.  Comments?
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

The prestige of government has undoubtedly been lowered considerably
by the Prohibition law. For nothing is more destructive of respect for
the government and the law of the land than passing laws which cannot
be enforced. It is an open secret that the dangerous increase of crime
in this country is closely connected with this.
	-- Albert Einstein, "My First Impression of the U.S.A.", 1921


From Fredrik Lundh" <effbot@telia.com  Wed Oct  4 18:25:37 2000
From: Fredrik Lundh" <effbot@telia.com (Fredrik Lundh)
Date: Wed, 4 Oct 2000 19:25:37 +0200
Subject: [Python-Dev] Proposal -- makefile patches and scripts to generate python RPMs
References: <200010041717.NAA03509@snark.thyrsus.com>
Message-ID: <002c01c02e28$1dc20d00$766940d5@hagrid>

eric wrote:
> In the course of maintaining fetchmail, I've developed effective
> techniques for integrating RPM and lsm generation into the release machinery
> of a package.  I'm willing to do this for Python; it will involve
> adding a makefile production and a couple of scripts to the
> distribution.
> 
> The benefit would be that we could generate correct RPMs automatically
> and ship them with each release.  I think RPM is a sufficiently
> important distribution format to justify this effort.  Comments?

isn't this a distutils thing?  see:

ftp://python.beopen.com/pub/docco/devel/dist/creating-rpms.html

(lazy programmers just press the "deploy" button, of course ;-)

</F>



From akuchlin@mems-exchange.org  Wed Oct  4 19:02:19 2000
From: akuchlin@mems-exchange.org (Andrew Kuchling)
Date: Wed, 4 Oct 2000 14:02:19 -0400
Subject: [Python-Dev] Proposal -- makefile patches and scripts to generate python RPMs
In-Reply-To: <002c01c02e28$1dc20d00$766940d5@hagrid>; from effbot@telia.com on Wed, Oct 04, 2000 at 07:25:37PM +0200
References: <200010041717.NAA03509@snark.thyrsus.com> <002c01c02e28$1dc20d00$766940d5@hagrid>
Message-ID: <20001004140219.A5125@kronos.cnri.reston.va.us>

On Wed, Oct 04, 2000 at 07:25:37PM +0200, Fredrik Lundh wrote:
>isn't this a distutils thing?  see:
>ftp://python.beopen.com/pub/docco/devel/dist/creating-rpms.html
>(lazy programmers just press the "deploy" button, of course ;-)

It's not immediately obvious that the Distutils 1.0, which after all
mostly aims to support installing Python modules, can be applied to
installing Python itself, what with all the libraries and scripts and
such that Python needs.  It certainly is something to aim for, and I
intend to work on this some more after 2.0, but the attempt might run
into missing Distutil features.  Whether it's worth adding rules for
RPM in the meantime is up to the Pythoneers; I'm 0 on it.  (Not +0 or
-0, just 0 -- a Nirvana-like state of utter unconcern.)

--amk



From gward@mems-exchange.org  Wed Oct  4 19:13:01 2000
From: gward@mems-exchange.org (Greg Ward)
Date: Wed, 4 Oct 2000 14:13:01 -0400
Subject: [Python-Dev] Proposal -- makefile patches and scripts to generate python RPMs
In-Reply-To: <002c01c02e28$1dc20d00$766940d5@hagrid>; from effbot@telia.com on Wed, Oct 04, 2000 at 07:25:37PM +0200
References: <200010041717.NAA03509@snark.thyrsus.com> <002c01c02e28$1dc20d00$766940d5@hagrid>
Message-ID: <20001004141301.A31167@ludwig.cnri.reston.va.us>

On 04 October 2000, Fredrik Lundh said:
> isn't this a distutils thing?  see:
> 
> ftp://python.beopen.com/pub/docco/devel/dist/creating-rpms.html

But the Distutils brag line is:

  The Python Distribution Utilities, or Distutils for short, are a
  collection of modules that aid in the development, distribution, and
  installation of Python modules.

If that first sentence were instead

  The Python Distribution Utilities, or Distutils for short, are a
  collection of modules that aid in the development, distribution, and
  installation of Python.

then you'd have a point.

What a difference one little word can make...

        Greg


From gward@mems-exchange.org  Wed Oct  4 19:16:20 2000
From: gward@mems-exchange.org (Greg Ward)
Date: Wed, 4 Oct 2000 14:16:20 -0400
Subject: [Python-Dev] Adding a section to PEP 0042
Message-ID: <20001004141620.A31293@ludwig.cnri.reston.va.us>

I need to add an entry to PEP 0042 about the lack of cross-compilation
support, because that's a bug report that was assigned to me, and needs
to be marked "Closed/Feature Request/Later" and put in PEP 0042.  Seems
to me that I should just add a section on "Build/Installation" to the
PEP -- anyone disagree?  This might also be a good place to gather
other gripes about Python's build/installation machinery...

        Greg
-- 
Greg Ward - software developer                gward@mems-exchange.org
MEMS Exchange / CNRI                           voice: +1-703-262-5376
Reston, Virginia, USA                            fax: +1-703-262-5367


From Fredrik Lundh" <effbot@telia.com  Wed Oct  4 19:53:48 2000
From: Fredrik Lundh" <effbot@telia.com (Fredrik Lundh)
Date: Wed, 4 Oct 2000 20:53:48 +0200
Subject: [Python-Dev] Proposal -- makefile patches and scripts to generate python RPMs
References: <200010041717.NAA03509@snark.thyrsus.com> <002c01c02e28$1dc20d00$766940d5@hagrid> <20001004141301.A31167@ludwig.cnri.reston.va.us>
Message-ID: <007901c02e34$81e32ce0$766940d5@hagrid>

greg wrote:
> If that first sentence were instead
> 
>   The Python Distribution Utilities, or Distutils for short, are a
>   collection of modules that aid in the development, distribution, and
>   installation of Python.
> 
> then you'd have a point.
> 
> What a difference one little word can make...

so why not fix it?  cannot be too hard to remove one
little word, can it? ;-)

</F>



From loewis@informatik.hu-berlin.de  Wed Oct  4 21:31:23 2000
From: loewis@informatik.hu-berlin.de (Martin von Loewis)
Date: Wed, 4 Oct 2000 22:31:23 +0200 (MET DST)
Subject: [Python-Dev] htmllib.HTMLescape()
Message-ID: <200010042031.WAA17378@pandora.informatik.hu-berlin.de>

> Someone just pointed out on c.l.py that we need an HTMLescape()
> function that takes a string and converts special characters to
> entities.  I'm not on python-dev, so could you please forward this
> and find out whether I need to run a PEP?

Doesn't xml.sax.saxutils.escape do what you want (together with
htmlentitydefs)? I was going to say that this is quite a small change
to warrant a PEP - but there are two obvious approaches (working from
scratch, or working on top of xml.sax.saxutils.escape - perhaps
modifying and relocating that function), so *some* design probably
needs to be recorded in a PEP.

Regards,
Martin


From trentm@ActiveState.com  Wed Oct  4 22:17:37 2000
From: trentm@ActiveState.com (Trent Mick)
Date: Wed, 4 Oct 2000 14:17:37 -0700
Subject: [Python-Dev] test_sre.py fails on Win64 because PyOS_CheckStack *never* fails
Message-ID: <20001004141737.A16659@ActiveState.com>

I did not follow the discussion a while back regarding the implementation and
use of PyOS_CheckStack on Windows. In any case, its use (USE_STACKCHECK)
instead of recursion limit checking (USE_RECURSION_LIMIT) in _sre.c results
in this test:
    test(r"""sre.match(r'(x)*', 50000*'x').span()""", (0, 50000), RuntimeError)
in test_sre.py failing on Win64.


This is because PyOS_CheckStack seem to *never* fail on Win64. Three
possibilites:
  (1) I don't understand the PyOS_CheckStack code or I am misintepreting the
      problem.
  (2) The semantics of _alloca() has changed for Win64 such that a stack
      overflow exception is no longer thrown if space cannot be allocated.
      NOTE: I changed the number of pointers allocated in PyOS_CheckStack
            from 2048 to over 1 *Tera*byte and it *still* did not fail.
  (3) I am stoopid.


In any case, I would like to *not* define USE_STACKCHECK on Win64 for the
time being (and for 2.0, unless a Win64 angel comes to me in the next couple
of days). Does anybody have a problem with me checking this in?

*** Include\pythonrun.h~     Wed Oct 04 14:18:00 2000
--- Include\pythonrun.h      Wed Oct 04 13:17:17 2000
***************
*** 88,94 ****
     to a 8k margin. */
  #define PYOS_STACK_MARGIN 2048

! #if defined(WIN32) && defined(_MSC_VER)
  /* Enable stack checking under Microsoft C */
  #define USE_STACKCHECK
  #endif
--- 88,94 ----
     to a 8k margin. */
  #define PYOS_STACK_MARGIN 2048

! #if defined(WIN32) && !defined(MS_WIN64) && defined(_MSC_VER)
  /* Enable stack checking under Microsoft C */
  #define USE_STACKCHECK
  #endif


Thanks,
Trent

-- 
Trent Mick
TrentM@ActiveState.com


From Fredrik Lundh" <effbot@telia.com  Wed Oct  4 22:34:50 2000
From: Fredrik Lundh" <effbot@telia.com (Fredrik Lundh)
Date: Wed, 4 Oct 2000 23:34:50 +0200
Subject: [Python-Dev] test_sre.py fails on Win64 because PyOS_CheckStack *never* fails
References: <20001004141737.A16659@ActiveState.com>
Message-ID: <000701c02e4a$edf6b580$766940d5@hagrid>

trent wrote:
> I did not follow the discussion a while back regarding the implementation and
> use of PyOS_CheckStack on Windows. In any case, its use (USE_STACKCHECK)
> instead of recursion limit checking (USE_RECURSION_LIMIT) in _sre.c results
> in this test:
>     test(r"""sre.match(r'(x)*', 50000*'x').span()""", (0, 50000), RuntimeError)
> in test_sre.py failing on Win64.

note that the test assumes that 50000 iterations would be
enough to hit the stack limit.  maybe Win64 has a *huge*
stack?

what does this little program do:

    import sre
    sre.match(r'(x)*', 50000*'x').span()

if it prints (0, 50000), all is well, and the *test* should be
disabled (or modified) on Win64...

</F>



From jeremy@beopen.com  Wed Oct  4 22:35:26 2000
From: jeremy@beopen.com (Jeremy Hylton)
Date: Wed, 4 Oct 2000 17:35:26 -0400 (EDT)
Subject: [Python-Dev] Proposal -- makefile patches and scripts to generate python RPMs
In-Reply-To: <200010041717.NAA03509@snark.thyrsus.com>
References: <200010041717.NAA03509@snark.thyrsus.com>
Message-ID: <14811.41630.554137.351253@bitdiddle.concentric.net>

>>>>> "ESR" == Eric S Raymond <esr@snark.thyrsus.com> writes:

  ESR> In the course of maintaining fetchmail, I've developed
  ESR> effective techniques for integrating RPM and lsm generation
  ESR> into the release machinery of a package.  I'm willing to do
  ESR> this for Python; it will involve adding a makefile production
  ESR> and a couple of scripts to the distribution.

  ESR> The benefit would be that we could generate correct RPMs
  ESR> automatically and ship them with each release.  I think RPM is
  ESR> a sufficiently important distribution format to justify this
  ESR> effort.  Comments?

We are now distributing RPMs for RH 6 with Python and have plans to
support other distributions we have access to, namely those available
on the SF compile farm.

This page has the RPMs:
http://www.pythonlabs.com/products/python2.0/download_python2.0b2.html

Can you compare this approach to using a hand-crafted .spec file for
the RPMs?  It took a little while to figure out how to generate the
.spec, but now that it has been created it does not seem hard to
maintain.

I imagine, without knowing any details of what you propose, that this
is primarily beneficial for people who do not know how to build RPMs.

Jeremy



From Fredrik Lundh" <effbot@telia.com  Wed Oct  4 22:43:41 2000
From: Fredrik Lundh" <effbot@telia.com (Fredrik Lundh)
Date: Wed, 4 Oct 2000 23:43:41 +0200
Subject: [Python-Dev] test_sre.py fails on Win64 because PyOS_CheckStack *never* fails
References: <20001004141737.A16659@ActiveState.com>
Message-ID: <000b01c02e4c$2ac63980$766940d5@hagrid>

trent wrote:
> This is because PyOS_CheckStack seem to *never* fail on Win64. Three
> possibilites:
>   (1) I don't understand the PyOS_CheckStack code or I am misintepreting the
>       problem.
>   (2) The semantics of _alloca() has changed for Win64 such that a stack
>       overflow exception is no longer thrown if space cannot be allocated.
>       NOTE: I changed the number of pointers allocated in PyOS_CheckStack
>             from 2048 to over 1 *Tera*byte and it *still* did not fail.

me again: didn't read the note carefully enough, so I didn't
quite figure out what you said...

:::

what happens if you run this program (on my win95 box, it
counts up to 8, and stops).

#include <malloc.h>
#include <excpt.h>

int __inline
PyOS_CheckStack()
{
    __try {
        _alloca(100000);
        return 0;
    } __except (EXCEPTION_EXECUTE_HANDLER) {
        /* just ignore all errors */
    }
    return 1;
}

void
callme(int i)
{
    char buf[100000];
    if (PyOS_CheckStack())
        return;
    printf("%d\n", i);
    memset(buf, 0, sizeof buf);
    callme(i+1);
}

int
main()
{
    callme(0);
}

:::

if it goes on and on and on, check the assembler output from
this program.

(maybe the win64 compiler is smarter than I -- if it realizes that I
don't actually use the return value from _alloca, it may of course
remove the entire thing...)

</F>



From esr@thyrsus.com  Wed Oct  4 22:56:38 2000
From: esr@thyrsus.com (Eric S. Raymond)
Date: Wed, 4 Oct 2000 17:56:38 -0400
Subject: [Python-Dev] Proposal -- makefile patches and scripts to generate python RPMs
In-Reply-To: <14811.41630.554137.351253@bitdiddle.concentric.net>; from jeremy@beopen.com on Wed, Oct 04, 2000 at 05:35:26PM -0400
References: <200010041717.NAA03509@snark.thyrsus.com> <14811.41630.554137.351253@bitdiddle.concentric.net>
Message-ID: <20001004175638.A4423@thyrsus.com>

Jeremy Hylton <jeremy@beopen.com>:
> We are now distributing RPMs for RH 6 with Python and have plans to
> support other distributions we have access to, namely those available
> on the SF compile farm.
> 
> This page has the RPMs:
> http://www.pythonlabs.com/products/python2.0/download_python2.0b2.html
> 
> Can you compare this approach to using a hand-crafted .spec file for
> the RPMs?  It took a little while to figure out how to generate the
> .spec, but now that it has been created it does not seem hard to
> maintain.
> 
> I imagine, without knowing any details of what you propose, that this
> is primarily beneficial for people who do not know how to build RPMs.

Actually, the point of my approach is *not* to hand-craft the spec file.
What I normally do is write a specfile generator script in shell, which
takes the release version as an argument.  Most of the point of the generator
script is so the file list part of the specfile never has to be handhacked.

So, for example, a specfile generator script for Python would know that for
each library file foo.py in the Python X.Y release tree, it needs to generate 
a file entry /usr/lib/pythonX.Y/foo.py -- that way whenever a module is
added to the library it will automatically ripple through to the RPM.

Then I embed something like this in the Makefile:

# Make RPMs.  You need to be root to make this work
RPMROOT=/usr/src/redhat
RPM = rpm
RPMFLAGS = -ba
rpm: dist
	cp foo-$(VERSION).tar.gz foo.xpm $(RPMROOT)/SOURCES;
	$(srcdir)/specgen.sh $(VERSION) >$(RPMROOT)/SPECS/foo.spec
	cd $(RPMROOT)/SPECS; $(RPM) $(RPMFLAGS) foo.spec	
	cp $(RPMROOT)/RPMS/`arch|sed 's/i[4-9]86/i386/'`/foo*-$(VERSION)*.rpm $(srcdir)
	cp $(RPMROOT)/SRPMS/foo*-$(VERSION)*.src.rpm $(srcdir)

Hey presto!  Instant RPMs.  I use this approach for several of my projects.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

The most foolish mistake we could possibly make would be to permit 
the conquered Eastern peoples to have arms.  History teaches that all 
conquerors who have allowed their subject races to carry arms have 
prepared their own downfall by doing so.
        -- Hitler, April 11 1942, revealing the real agenda of "gun control"


From nas@arctrix.com  Wed Oct  4 17:12:04 2000
From: nas@arctrix.com (Neil Schemenauer)
Date: Wed, 4 Oct 2000 09:12:04 -0700
Subject: [Python-Dev] Proposal -- makefile patches and scripts to generate python RPMs
In-Reply-To: <20001004175638.A4423@thyrsus.com>; from esr@thyrsus.com on Wed, Oct 04, 2000 at 05:56:38PM -0400
References: <200010041717.NAA03509@snark.thyrsus.com> <14811.41630.554137.351253@bitdiddle.concentric.net> <20001004175638.A4423@thyrsus.com>
Message-ID: <20001004091204.A787@glacier.fnational.com>

On Wed, Oct 04, 2000 at 05:56:38PM -0400, Eric S. Raymond wrote:
> Jeremy Hylton <jeremy@beopen.com>:
> > Can you compare this approach to using a hand-crafted .spec file for
> > the RPMs?  It took a little while to figure out how to generate the
> > .spec, but now that it has been created it does not seem hard to
> > maintain.
> Actually, the point of my approach is *not* to hand-craft the spec file.

Okay, but we already have the spec file.  Why is your approach
better?  Is your script that generates the the spec easier to
maintain then the spec file itself?  Is it just as flexible?  If
so then Red Hat screwed up designing RPM.  I can see the utility
of such as script but I don't see how it helps in this situation.

  Neil


From esr@thyrsus.com  Thu Oct  5 03:23:18 2000
From: esr@thyrsus.com (Eric S. Raymond)
Date: Wed, 4 Oct 2000 22:23:18 -0400
Subject: [Python-Dev] Proposal -- makefile patches and scripts to generate python RPMs
In-Reply-To: <20001004091204.A787@glacier.fnational.com>; from nas@arctrix.com on Wed, Oct 04, 2000 at 09:12:04AM -0700
References: <200010041717.NAA03509@snark.thyrsus.com> <14811.41630.554137.351253@bitdiddle.concentric.net> <20001004175638.A4423@thyrsus.com> <20001004091204.A787@glacier.fnational.com>
Message-ID: <20001004222318.E4742@thyrsus.com>

Neil Schemenauer <nas@arctrix.com>:
> On Wed, Oct 04, 2000 at 05:56:38PM -0400, Eric S. Raymond wrote:
> > Jeremy Hylton <jeremy@beopen.com>:
> > > Can you compare this approach to using a hand-crafted .spec file for
> > > the RPMs?  It took a little while to figure out how to generate the
> > > .spec, but now that it has been created it does not seem hard to
> > > maintain.
> > Actually, the point of my approach is *not* to hand-craft the spec file.
> 
> Okay, but we already have the spec file.  Why is your approach
> better?  Is your script that generates the the spec easier to
> maintain then the spec file itself?  Is it just as flexible?  If
> so then Red Hat screwed up designing RPM.  I can see the utility
> of such as script but I don't see how it helps in this situation.

The main thing a specfile generator can accomplish is to automate the
generation of the file list so that (for example) when we add a new
library module the specfile doesn't have to be hand-edited.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

"Guard with jealous attention the public liberty.  Suspect every one
who approaches that jewel.  Unfortunately, nothing will preserve it
but downright force.  Whenever you give up that force, you are
inevitably ruined."
	-- Patrick Henry, speech of June 5 1788


From nas@arctrix.com  Wed Oct  4 22:43:50 2000
From: nas@arctrix.com (Neil Schemenauer)
Date: Wed, 4 Oct 2000 14:43:50 -0700
Subject: [Python-Dev] Release candidate followed by feature freeze?
In-Reply-To: <200010030236.VAA02702@cj20424-a.reston1.va.home.com>; from guido@python.org on Mon, Oct 02, 2000 at 09:36:03PM -0500
References: <200010011913.VAA01107@pandora.informatik.hu-berlin.de> <200010021919.OAA01232@cj20424-a.reston1.va.home.com> <20001002044859.A9639@glacier.fnational.com> <200010030236.VAA02702@cj20424-a.reston1.va.home.com>
Message-ID: <20001004144350.A434@glacier.fnational.com>

On Mon, Oct 02, 2000 at 09:36:03PM -0500, Guido van Rossum wrote:
> Hooft's problem makes heavy use of Tkinter and Pmw, it seems.  Maybe
> that's a clue?

Rob was kind enough to send me some code to trigger the bug.  The
winner is ... tupleobject.c!  When MAXSAVESIZE is zero Rob's
program seems to work fine.  I think Pmw uses lots of tuples.

Looking closely at the code I see that _PyTuple_Resize is almost
certainly buggy.  I think something is wrong with PyTuple_New as
well.  I'll have to come up with a patch later as it is much to
late now for me to fully understand such hairy code. :(

  Neil


From pf@artcom-gmbh.de  Thu Oct  5 06:55:19 2000
From: pf@artcom-gmbh.de (Peter Funk)
Date: Thu, 5 Oct 2000 07:55:19 +0200 (MEST)
Subject: [Python-Dev] irritating 'No such file or directory' message (was Re: [Python-checkins] CVS: python/nondist/peps pep-0004.txt,NONE,1.1)
In-Reply-To: <200010042240.PAA14714@slayer.i.sourceforge.net> from Barry Warsaw at "Oct 4, 2000  3:40:33 pm"
Message-ID: <m13h3zz-000DmMC@artcom0.artcom-gmbh.de>

Hi,

Barry Warsaw :
> Update of /cvsroot/python/python/nondist/peps
> In directory slayer.i.sourceforge.net:/tmp/cvs-serv14669
> 
> Added Files:
> 	pep-0004.txt 
> Log Message:
> Added PEP 4, Deprecation of Standard Modules, Martin von Loewis
> 
> 
> ***** Error reading new file: (2, 'No such file or directory')

Whenever Barry adds a new file to the CVS, its initial content
is invisible on the checkins mailing list due to the error message
above.  However if for example fdrake adds a new file (for example the
support.py recently added to the doc subtree) then this doesn't happen.
Is there anybody out there able to fix this for future checkins-mails?

Regards, Peter


From fdrake@beopen.com  Thu Oct  5 07:23:10 2000
From: fdrake@beopen.com (Fred L. Drake, Jr.)
Date: Thu, 5 Oct 2000 02:23:10 -0400 (EDT)
Subject: [Python-Dev] irritating 'No such file or directory' message (was Re: [Python-checkins] CVS: python/nondist/peps pep-0004.txt,NONE,1.1)
In-Reply-To: <m13h3zz-000DmMC@artcom0.artcom-gmbh.de>
References: <200010042240.PAA14714@slayer.i.sourceforge.net>
 <m13h3zz-000DmMC@artcom0.artcom-gmbh.de>
Message-ID: <14812.7758.940994.732616@cj42289-a.reston1.va.home.com>

Peter Funk writes:
 > Whenever Barry adds a new file to the CVS, its initial content
 > is invisible on the checkins mailing list due to the error message
 > above.  However if for example fdrake adds a new file (for example the
 > support.py recently added to the doc subtree) then this doesn't happen.
 > Is there anybody out there able to fix this for future checkins-mails?

  Wow!  I had noticed the bolluxed messages, but hadn't tied it to
Barry!  But I just checked the added files for this month and
spot-checked the ones from last month, and Barry's all exhibit this
problem, and no one else's do.
  I wonder if something is wrong with his SourceForge account?  Barry,
check your group memberships, please!  If nothing obvious is wrong,
submit a support request, because this is definately annoying.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member



From tim_one@email.msn.com  Thu Oct  5 08:09:20 2000
From: tim_one@email.msn.com (Tim Peters)
Date: Thu, 5 Oct 2000 03:09:20 -0400
Subject: [Python-Dev] change to Lib/popen2.py break test_popen2 on windows
In-Reply-To: <20001003161009.B18387@ActiveState.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCOEKMHJAA.tim_one@email.msn.com>

[Trent Mick, pointing out that test_popen2 was busted on Windows]
> Geez, you are fast Tim! (for others: he patched test_popen.py
> after I sent my email but before my email made it to python-dev!)

I hate to be honest, but I actually pointed out the test_popen2 failure on
Python-Dev last week.  However, I was On Vacation(tm) then, so thought
merely mentioning it would shame someone else into fixing it.  At this
point, I'll happily settle for that somebody else eventually *noticed* it!

our-windows-testing-dept-may-be-on-permanent-vacation-ly y'rs  - tim




From tim_one@email.msn.com  Thu Oct  5 08:09:17 2000
From: tim_one@email.msn.com (Tim Peters)
Date: Thu, 5 Oct 2000 03:09:17 -0400
Subject: [Python-Dev] pep42 procedure?
In-Reply-To: <ECEPKNMJLHAPFFJHDOJBAEBJDMAA.MarkH@ActiveState.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCMEKMHJAA.tim_one@email.msn.com>

[Mark Hammond]
> That would be a great idea, if only we had a PEP author.  To be honest,
> I really dont care too much about this issue, and have been doing my
> level best to avoid it.  But Tim knows that, and delights in assigning
> related patches to me ;-)  I certainly don't care enough to own a pep
> on it. ...

I assign them to you because there's barely a line of Windows startup code
you didn't write, and you gave Windows the notion of naming the main DLL
differently across (some) different releases thus creating the possibility
for the problem these patches are trying to solve <wink>.  That's not to say
it's "your problem", but is to say you've thought more about "stuff like
this" than anyone else, and have very particular ideas about how you want
"stuff like this" done:  you're the best qualified.

That said, the subject of the PEP shouldn't be competing hacks to worm
around Windows-specific startup problems, it should be an actual design for
binary compatibility across iterations of the C API, or at least a reliable
way for extensions to *know* they're not getting a version of the Python
core they can use.

we're-only-hacking-because-we've-ignored-the-real-problem-ly y'rs  - tim




From martin@loewis.home.cs.tu-berlin.de  Thu Oct  5 08:44:52 2000
From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Thu, 5 Oct 2000 09:44:52 +0200
Subject: [Python-Dev] Proposal -- makefile patches and scripts to generate python RPMs
Message-ID: <200010050744.JAA00782@loewis.home.cs.tu-berlin.de>

> The main thing a specfile generator can accomplish is to automate
> the generation of the file list so that (for example) when we add a
> new library module the specfile doesn't have to be hand-edited.

That sounds similar to the rationale for having automatically
generated dependency files for make, e.g. by gcc -MM. Many projects
use this as a convenience, and it kind-of works. However, I still like
it better to have dependencies explicitly recorded in the
Makefiles. That requires more discipline, but is easier to understand,
and the behaviour is more reproducable.

So given the option of using an existing hand-written spec file, and
having some magic generate one for me, I'd always use the hand-written
one. The magic is only good if there is no hand-written one.

Regards,
Martin



From fredrik@pythonware.com  Thu Oct  5 08:50:37 2000
From: fredrik@pythonware.com (Fredrik Lundh)
Date: Thu, 5 Oct 2000 09:50:37 +0200
Subject: [Python-Dev] Release candidate followed by feature freeze?
References: <200010011913.VAA01107@pandora.informatik.hu-berlin.de> <200010021919.OAA01232@cj20424-a.reston1.va.home.com> <20001002044859.A9639@glacier.fnational.com> <200010030236.VAA02702@cj20424-a.reston1.va.home.com> <20001004144350.A434@glacier.fnational.com>
Message-ID: <00e301c02ea0$f3ea5680$0900a8c0@SPIFF>

neil wrote:
> On Mon, Oct 02, 2000 at 09:36:03PM -0500, Guido van Rossum wrote:
> > Hooft's problem makes heavy use of Tkinter and Pmw, it seems.  Maybe
> > that's a clue?
> 
> Rob was kind enough to send me some code to trigger the bug.  The
> winner is ... tupleobject.c!  When MAXSAVESIZE is zero Rob's
> program seems to work fine.  I think Pmw uses lots of tuples.

The new version of Tkinter contains a _flatten function written in C,
which uses PyTuple_Resize extensively.

To check if Rob's program works better without it, you can comment
out the "_flatten = _tkinter._flatten" line in Tkinter.py (it's line 70 or
so, iirc).

</F>



From larsga@garshol.priv.no  Thu Oct  5 09:36:33 2000
From: larsga@garshol.priv.no (Lars Marius Garshol)
Date: 05 Oct 2000 10:36:33 +0200
Subject: [Python-Dev] htmllib.HTMLescape()
In-Reply-To: <200010042031.WAA17378@pandora.informatik.hu-berlin.de>
References: <200010042031.WAA17378@pandora.informatik.hu-berlin.de>
Message-ID: <m3itr7elbi.fsf@lambda.garshol.priv.no>

* Martin von Loewis
| 
| Doesn't xml.sax.saxutils.escape do what you want (together with
| htmlentitydefs)? I was going to say that this is quite a small
| change to warrant a PEP - but there are two obvious approaches
| (working from scratch, or working on top of xml.sax.saxutils.escape
| - perhaps modifying and relocating that function), so *some* design
| probably needs to be recorded in a PEP.

It would probably help, but now that Python has Unicode support there
should be some way to convert string data to a legacy encoding and
represent all characters not available in that encoding using numeric
character references.  This would be very useful for both XML and
HTML.  The difficulty, I assume, lies in figuring out which encodings
support what characters.

--Lars M.



From nas@arctrix.com  Thu Oct  5 06:59:38 2000
From: nas@arctrix.com (Neil Schemenauer)
Date: Wed, 4 Oct 2000 22:59:38 -0700
Subject: [Python-Dev] Release candidate followed by feature freeze?
In-Reply-To: <00e301c02ea0$f3ea5680$0900a8c0@SPIFF>; from fredrik@pythonware.com on Thu, Oct 05, 2000 at 09:50:37AM +0200
References: <200010011913.VAA01107@pandora.informatik.hu-berlin.de> <200010021919.OAA01232@cj20424-a.reston1.va.home.com> <20001002044859.A9639@glacier.fnational.com> <200010030236.VAA02702@cj20424-a.reston1.va.home.com> <20001004144350.A434@glacier.fnational.com> <00e301c02ea0$f3ea5680$0900a8c0@SPIFF>
Message-ID: <20001004225938.A802@glacier.fnational.com>

On Thu, Oct 05, 2000 at 09:50:37AM +0200, Fredrik Lundh wrote:
> The new version of Tkinter contains a _flatten function written in C,
> which uses PyTuple_Resize extensively.
> 
> To check if Rob's program works better without it, you can comment
> out the "_flatten = _tkinter._flatten" line in Tkinter.py (it's line 70 or
> so, iirc).

That fixes the crash as well.

  Neil


From bwarsaw@beopen.com  Thu Oct  5 14:33:53 2000
From: bwarsaw@beopen.com (Barry A. Warsaw)
Date: Thu, 5 Oct 2000 09:33:53 -0400 (EDT)
Subject: [Python-Dev] irritating 'No such file or directory' message (was Re: [Python-checkins] CVS: python/nondist/peps pep-0004.txt,NONE,1.1)
References: <200010042240.PAA14714@slayer.i.sourceforge.net>
 <m13h3zz-000DmMC@artcom0.artcom-gmbh.de>
 <14812.7758.940994.732616@cj42289-a.reston1.va.home.com>
Message-ID: <14812.33601.730022.889777@anthem.concentric.net>

>>>>> "Fred" == Fred L Drake, Jr <fdrake@beopen.com> writes:

    Fred>   Wow!  I had noticed the bolluxed messages, but hadn't tied
    Fred> it to Barry!  But I just checked the added files for this
    Fred> month and spot-checked the ones from last month, and Barry's
    Fred> all exhibit this problem, and no one else's do.  I wonder if
    Fred> something is wrong with his SourceForge account?  Barry,
    Fred> check your group memberships, please!  If nothing obvious is
    Fred> wrong, submit a support request, because this is definately
    Fred> annoying.

I don't understand why this is happening, esp. just for me!  My
primary group is users and I'm definitely in the python group as
well.  Why would it be a permission problem anyway, since that's not
what the error message is saying?

Better log messages in syncmail would help diagnose this, but I
haven't got the time right now to hack on that.

-Barry


From pf@artcom-gmbh.de  Thu Oct  5 14:54:58 2000
From: pf@artcom-gmbh.de (Peter Funk)
Date: Thu, 5 Oct 2000 15:54:58 +0200 (MEST)
Subject: [Python-Dev] irritating 'No such file or directory' message (was Re: [Python-checkins] CVS: python/nondist/peps pep-0004.txt
In-Reply-To: <14812.33601.730022.889777@anthem.concentric.net> from "Barry A. Warsaw" at "Oct 5, 2000  9:33:53 am"
Message-ID: <m13hBUA-000DmMC@artcom0.artcom-gmbh.de>

Hi,

Barry A. Warsaw:
> 
> >>>>> "Fred" == Fred L Drake, Jr <fdrake@beopen.com> writes:
> 
>     Fred>   Wow!  I had noticed the bolluxed messages, but hadn't tied
>     Fred> it to Barry!  But I just checked the added files for this
>     Fred> month and spot-checked the ones from last month, and Barry's
>     Fred> all exhibit this problem, and no one else's do.  I wonder if
>     Fred> something is wrong with his SourceForge account?  Barry,
>     Fred> check your group memberships, please!  If nothing obvious is
>     Fred> wrong, submit a support request, because this is definately
>     Fred> annoying.
> 
> I don't understand why this is happening, esp. just for me!  My
> primary group is users and I'm definitely in the python group as
> well.  Why would it be a permission problem anyway, since that's not
> what the error message is saying?
> 
> Better log messages in syncmail would help diagnose this, but I
> haven't got the time right now to hack on that.

Just speculating: it has something todo with the current directory 
where the cvs commit command is executed in or it depends on the 
difference that the PEPs are under nondist and Freds files were under dist.

Possible ugly workaround for Barry: for new files first commit an empty 
file and then the real file just a moment later. ;-)

Regards, Peter
-- 
Peter Funk, Oldenburger Str.86, D-27777 Ganderkesee, Germany, Fax:+49 4222950260
office: +49 421 20419-0 (ArtCom GmbH, Grazer Str.8, D-28359 Bremen)


From jeremy@beopen.com  Thu Oct  5 15:42:31 2000
From: jeremy@beopen.com (Jeremy Hylton)
Date: Thu, 5 Oct 2000 10:42:31 -0400 (EDT)
Subject: [Python-Dev] Release candidate schedule
Message-ID: <14812.37719.248406.924744@bitdiddle.concentric.net>

There are still a number of open bugs that need to be addressed before
we can issue a release candidate.  We plan to issue the release
candidate on Monday and the final release a week later.

According to the Sourceforge bug report --
http://sourceforge.net/bugs/reporting/?group_id=5470&run_report=1&tech=1
-- the following people still have open bugs:

akuchlin (3) 
bwarsaw (3) 
dcjim (2) 
effbot (5) 
fdrake (4) 
gvanrossum (12) 
gward (1) 
jackjansen (1) 
jhylton (8) 
lemburg (2) 
mhammond (5) 
nascheme (3) 
tim_one (5)

I don't expect that every bug will be closed before 2.0 final, but
there are some open bugs about test failures and build problems with
2.0 beta releases.  We should address these if at all possible.

Please review your open bugs and make sure you aren't forgetting about
something.  If you have bugs that will not be fixed for 2.0, make sure
they have a fairly low priority.  If you have bugs you will not be
able to address, assign them to me.

Jeremy


From Fredrik Lundh" <effbot@telia.com  Thu Oct  5 15:53:48 2000
From: Fredrik Lundh" <effbot@telia.com (Fredrik Lundh)
Date: Thu, 5 Oct 2000 16:53:48 +0200
Subject: [Python-Dev] Release candidate followed by feature freeze?
References: <200010011913.VAA01107@pandora.informatik.hu-berlin.de> <200010021919.OAA01232@cj20424-a.reston1.va.home.com> <20001002044859.A9639@glacier.fnational.com> <200010030236.VAA02702@cj20424-a.reston1.va.home.com> <20001004144350.A434@glacier.fnational.com> <00e301c02ea0$f3ea5680$0900a8c0@SPIFF> <20001004225938.A802@glacier.fnational.com>
Message-ID: <002501c02edc$1302b040$766940d5@hagrid>

what's the current release schedule, btw?

is the repository frozen, or do we still have a chance to fix
the GC tuple problem and SRE's "nothing to repeat" bug?

</F>



From Fredrik Lundh" <effbot@telia.com  Thu Oct  5 15:51:25 2000
From: Fredrik Lundh" <effbot@telia.com (Fredrik Lundh)
Date: Thu, 5 Oct 2000 16:51:25 +0200
Subject: [Python-Dev] Release candidate followed by feature freeze?
References: <200010011913.VAA01107@pandora.informatik.hu-berlin.de> <200010021919.OAA01232@cj20424-a.reston1.va.home.com> <20001002044859.A9639@glacier.fnational.com> <200010030236.VAA02702@cj20424-a.reston1.va.home.com> <20001004144350.A434@glacier.fnational.com> <00e301c02ea0$f3ea5680$0900a8c0@SPIFF> <20001004225938.A802@glacier.fnational.com>
Message-ID: <002401c02edc$12aec3e0$766940d5@hagrid>

> > To check if Rob's program works better without it, you can comment
> > out the "_flatten = _tkinter._flatten" line in Tkinter.py (it's line 70 or
> > so, iirc).
> 
> That fixes the crash as well.

in other words, _PyTuple_Resize needs some work...

(or does _flatten do something wrong?  it starts by creating
a tuple, and if it needs more space, it doubles the size one or
more times, and ends by calling Resize again to set the final
size...)

:::

btw, the start of Resize looks a bit strange: should that
DECREF really be there?  should least be an XDECREF, or
am I missing something?

 if (v == NULL || !PyTuple_Check(v) || v->ob_refcnt != 1) {
  *pv = 0;
  Py_DECREF(v); /* really? what if v is NULL? */
  PyErr_BadInternalCall();
  return -1;
 }

</F>



From mal@lemburg.com  Thu Oct  5 16:00:12 2000
From: mal@lemburg.com (M.-A. Lemburg)
Date: Thu, 05 Oct 2000 17:00:12 +0200
Subject: [Python-Dev] Proposal -- makefile patches and scripts to generate
 python RPMs
References: <200010041717.NAA03509@snark.thyrsus.com> <002c01c02e28$1dc20d00$766940d5@hagrid> <20001004140219.A5125@kronos.cnri.reston.va.us>
Message-ID: <39DC977C.89D14AB1@lemburg.com>

Andrew Kuchling wrote:
> 
> On Wed, Oct 04, 2000 at 07:25:37PM +0200, Fredrik Lundh wrote:
> >isn't this a distutils thing?  see:
> >ftp://python.beopen.com/pub/docco/devel/dist/creating-rpms.html
> >(lazy programmers just press the "deploy" button, of course ;-)
> 
> It's not immediately obvious that the Distutils 1.0, which after all
> mostly aims to support installing Python modules, can be applied to
> installing Python itself, what with all the libraries and scripts and
> such that Python needs.  It certainly is something to aim for, and I
> intend to work on this some more after 2.0, but the attempt might run
> into missing Distutil features.  Whether it's worth adding rules for
> RPM in the meantime is up to the Pythoneers; I'm 0 on it.  (Not +0 or
> -0, just 0 -- a Nirvana-like state of utter unconcern.)

distutils is not useful for installing Python (it needs Python
to start with), but it does a pretty good job at finding the
needed files and can generate RPMs which can be used without
distutils or Python. It even allows adding handcrafted sections
to the resulting RPM.

If anybody plans to help in this direction, I'd suggest to add
those efforts to the build_rpm command in distutils (and the
build_deb command for that matter).

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/


From akuchlin@mems-exchange.org  Thu Oct  5 16:24:32 2000
From: akuchlin@mems-exchange.org (Andrew Kuchling)
Date: Thu, 5 Oct 2000 11:24:32 -0400
Subject: [Python-Dev] Proposal -- makefile patches and scripts to generate python RPMs
In-Reply-To: <39DC977C.89D14AB1@lemburg.com>; from mal@lemburg.com on Thu, Oct 05, 2000 at 05:00:12PM +0200
References: <200010041717.NAA03509@snark.thyrsus.com> <002c01c02e28$1dc20d00$766940d5@hagrid> <20001004140219.A5125@kronos.cnri.reston.va.us> <39DC977C.89D14AB1@lemburg.com>
Message-ID: <20001005112432.A30233@kronos.cnri.reston.va.us>

On Thu, Oct 05, 2000 at 05:00:12PM +0200, M.-A. Lemburg wrote:
>distutils is not useful for installing Python (it needs Python
>to start with), ...

Note that the Distutils doesn't need many C-based modules: _sre,
posix, and string are about it.  So those modules could be
automatically compiled into the Python binary (perhaps being moved
from Modules/ into Python/ to signify their new importance) and the
resulting binary should have enough marbles to run a setup.py script
that would build everything else in Modules/.  

The downside is that you could no longer compile those 3 modules as
dynamically loadable, but the upside is that the setup.py could be
smarter about detecting which libraries are available on the system,
and compiling everything which can be.  This would, one hopes, make
Setup file hacking a thing of the past...

--amk




From tismer@appliedbiometrics.com  Thu Oct  5 15:33:54 2000
From: tismer@appliedbiometrics.com (Christian Tismer)
Date: Thu, 05 Oct 2000 17:33:54 +0300
Subject: [Python-Dev] Stackless Python Mailing List
Message-ID: <39DC9152.7998DFC0@appliedbiometrics.com>

Hi Pythoneers (without or not without Stack (yet:))

there have been a couple of interviews, and some
articles on Stackless Python are published or in
preparation. I recognize an increasing number
of individual emails concerning Stackless Python.

This lets me take the opportunity to start a mailing
list on Stackless Python, an overdue task.

The goal of this list is two-fold:
On the one hand, people should have a forum to
discuss their use of SLP, its further development,
concurrency in general, and more.
The other reason is to increase the support for SLP,
with the final goal to get it merged into Standard Python.
There are a couple of ways to help me with that, see
http://starShip.python.net/mailman/listinfo/stackless

Everybody who is interested in Stackless Python and
all the related topics may feel invited to join this
discussion group.

cheers - chris

-- 
Christian Tismer             :^)   <mailto:tismer@appliedbiometrics.com>
Applied Biometrics GmbH      :     Have a break! Take a ride on Python's
Kaunstr. 26                  :    *Starship* http://starship.python.net
14163 Berlin                 :     PGP key -> http://wwwkeys.pgp.net
PGP Fingerprint       E182 71C7 1A9D 66E9 9D15  D3CC D4D7 93E2 1FAE F6DF
     where do you want to jump today?   http://www.stackless.com


From nas@arctrix.com  Thu Oct  5 09:40:28 2000
From: nas@arctrix.com (Neil Schemenauer)
Date: Thu, 5 Oct 2000 01:40:28 -0700
Subject: [Python-Dev] Release candidate followed by feature freeze?
In-Reply-To: <002401c02edc$12aec3e0$766940d5@hagrid>; from effbot@telia.com on Thu, Oct 05, 2000 at 04:51:25PM +0200
References: <200010011913.VAA01107@pandora.informatik.hu-berlin.de> <200010021919.OAA01232@cj20424-a.reston1.va.home.com> <20001002044859.A9639@glacier.fnational.com> <200010030236.VAA02702@cj20424-a.reston1.va.home.com> <20001004144350.A434@glacier.fnational.com> <00e301c02ea0$f3ea5680$0900a8c0@SPIFF> <20001004225938.A802@glacier.fnational.com> <002401c02edc$12aec3e0$766940d5@hagrid>
Message-ID: <20001005014028.A1055@glacier.fnational.com>

On Thu, Oct 05, 2000 at 04:51:25PM +0200, Fredrik Lundh wrote:
> in other words, _PyTuple_Resize needs some work...

Yup.  I've attached a patch which I believe fixes some GC bugs in
addition to making it simpler.

> btw, the start of Resize looks a bit strange: should that
> DECREF really be there?  should least be an XDECREF, or
> am I missing something?
> 
>  if (v == NULL || !PyTuple_Check(v) || v->ob_refcnt != 1) {
>   *pv = 0;
>   Py_DECREF(v); /* really? what if v is NULL? */
>   PyErr_BadInternalCall();
>   return -1;
>  }

I think your right.  Here's a fun little program:

    from _tkinter import _flatten
    import random # don't ask me why
    for x in xrange(10000):
        print x
        t = _flatten([(0,)*x]*x)

It gives:

    0
    1
    2
    3
    4
    5
    Segmentation fault

on the two Linux machines I've tested it on.  It also crashes
with GC disabled.

  Neil


*** Objects/tupleobject.c	Thu Oct  5 11:31:30 2000
--- tupleobject.c	Thu Oct  5 10:47:44 2000
***************
*** 500,531 ****
  	} else 
  #endif		
  	{
! #ifdef WITH_CYCLE_GC
! 		PyGC_Head *g = PyObject_AS_GC((PyObject *)v);
! 		PyObject_GC_Fini((PyObject *)v);
! 		g = (PyGC_Head *)
! 			PyObject_REALLOC((char *)g, sizeof(PyTupleObject) 
! 					+ PyGC_HEAD_SIZE
! 					+ newsize * sizeof(PyObject *));
! 		if (g == NULL) {
! 			sv = NULL;
! 		} else {
! 			sv = (PyTupleObject *)PyObject_FROM_GC(g);
! 		}
! #else
  		sv = (PyTupleObject *)
! 			PyObject_REALLOC((char *)v, sizeof(PyTupleObject) 
! 					+ PyGC_HEAD_SIZE
! 					+ newsize * sizeof(PyObject *));
! #endif
! 		*pv = (PyObject *) sv;
  		if (sv == NULL) {
! 			PyObject_GC_Init((PyObject *)v);
! 			v = (PyTupleObject *) PyObject_AS_GC(v);
  			PyObject_DEL(v);
  			PyErr_NoMemory();
  			return -1;
  		}
  	}
  	_Py_NewReference((PyObject *)sv);
  	for (i = sv->ob_size; i < newsize; i++)
--- 500,519 ----
  	} else 
  #endif		
  	{
! 		PyObject_GC_Fini(v);
! 		v = (PyObject *) PyObject_AS_GC(v);
  		sv = (PyTupleObject *)
! 			PyObject_REALLOC((char *)v, sizeof(PyTupleObject)
! 					 + PyGC_HEAD_SIZE
! 					 + newsize * sizeof(PyObject *));
  		if (sv == NULL) {
! 			*pv = NULL;
  			PyObject_DEL(v);
  			PyErr_NoMemory();
  			return -1;
  		}
+ 		sv = (PyTupleObject *) PyObject_FROM_GC(sv);
+ 		*pv = (PyObject *) sv;
  	}
  	_Py_NewReference((PyObject *)sv);
  	for (i = sv->ob_size; i < newsize; i++)





From guido@python.org  Thu Oct  5 19:22:49 2000
From: guido@python.org (Guido van Rossum)
Date: Thu, 05 Oct 2000 13:22:49 -0500
Subject: [Python-Dev] forwarded message from aahz@panix.com
In-Reply-To: Your message of "Wed, 04 Oct 2000 02:07:06 -0400."
 <14810.51466.486982.938180@anthem.concentric.net>
References: <14810.51466.486982.938180@anthem.concentric.net>
Message-ID: <200010051822.NAA14228@cj20424-a.reston1.va.home.com>

[Aahz]
> Someone just pointed out on c.l.py that we need an HTMLescape() function
> that takes a string and converts special characters to entities.  I'm
> not on python-dev, so could you please forward this and find out whether
> I need to run a PEP?

Has someone pointed out yet that this is done by cgi.escape()?

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


From guido@python.org  Thu Oct  5 19:24:20 2000
From: guido@python.org (Guido van Rossum)
Date: Thu, 05 Oct 2000 13:24:20 -0500
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules cPickle.c,2.52,2.53
In-Reply-To: Your message of "Wed, 04 Oct 2000 02:46:36 MST."
 <20001004024636.A13475@glacier.fnational.com>
References: <200010041622.JAA17363@slayer.i.sourceforge.net>
 <20001004024636.A13475@glacier.fnational.com>
Message-ID: <200010051824.NAA14253@cj20424-a.reston1.va.home.com>

> I aways seem to think harder when reviewing a commit message than
> a diff. :(  I just realized that this commit subtly modifies
> cPickle's behavior.  Before the change instances __del__ methods
> would be called if allocating __dict__ failed.  After the change
> they are not.  I think the new behavior is better but the
> question is will it break existing code?  I think probably not.

This is goodness.  Don't worry about breaking code -- it probably
*fixes* code.  Most __del__ methods don't know what to do when the
instance variables haven't been defined yet!

> BTW, pickle seems to follow the new behavior.

Even better.

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


From guido@python.org  Thu Oct  5 19:29:27 2000
From: guido@python.org (Guido van Rossum)
Date: Thu, 05 Oct 2000 13:29:27 -0500
Subject: [Python-Dev] Adding a section to PEP 0042
In-Reply-To: Your message of "Wed, 04 Oct 2000 14:16:20 -0400."
 <20001004141620.A31293@ludwig.cnri.reston.va.us>
References: <20001004141620.A31293@ludwig.cnri.reston.va.us>
Message-ID: <200010051829.NAA14300@cj20424-a.reston1.va.home.com>

> I need to add an entry to PEP 0042 about the lack of cross-compilation
> support, because that's a bug report that was assigned to me, and needs
> to be marked "Closed/Feature Request/Later" and put in PEP 0042.  Seems
> to me that I should just add a section on "Build/Installation" to the
> PEP -- anyone disagree?  This might also be a good place to gather
> other gripes about Python's build/installation machinery...

+1

(I think the "Library" section is growing too big and may be split in
"Lib" and "Modules" sections.)

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


From guido@python.org  Thu Oct  5 19:33:47 2000
From: guido@python.org (Guido van Rossum)
Date: Thu, 05 Oct 2000 13:33:47 -0500
Subject: [Python-Dev] Proposal -- makefile patches and scripts to generate python RPMs
In-Reply-To: Your message of "Thu, 05 Oct 2000 09:44:52 +0200."
 <200010050744.JAA00782@loewis.home.cs.tu-berlin.de>
References: <200010050744.JAA00782@loewis.home.cs.tu-berlin.de>
Message-ID: <200010051833.NAA14356@cj20424-a.reston1.va.home.com>

Whatever the outcome of this discussion, this is too late for 2.0.

But I tend to side with Jeremy and Martin -- "explicit is better".
I do want Jeremy to check his RPM generation scripts in, so they can
be improved in a truly open source project.  (Maybe in Tools/rpm?)

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


From guido@python.org  Thu Oct  5 19:43:30 2000
From: guido@python.org (Guido van Rossum)
Date: Thu, 05 Oct 2000 13:43:30 -0500
Subject: [Python-Dev] Release candidate followed by feature freeze?
In-Reply-To: Your message of "Thu, 05 Oct 2000 16:53:48 +0200."
 <002501c02edc$1302b040$766940d5@hagrid>
References: <200010011913.VAA01107@pandora.informatik.hu-berlin.de> <200010021919.OAA01232@cj20424-a.reston1.va.home.com> <20001002044859.A9639@glacier.fnational.com> <200010030236.VAA02702@cj20424-a.reston1.va.home.com> <20001004144350.A434@glacier.fnational.com> <00e301c02ea0$f3ea5680$0900a8c0@SPIFF> <20001004225938.A802@glacier.fnational.com>
 <002501c02edc$1302b040$766940d5@hagrid>
Message-ID: <200010051843.NAA14435@cj20424-a.reston1.va.home.com>

> what's the current release schedule, btw?

Let me give that a shot...

-   Feature Freeze Now.  I.e. it's too late for anything even vaguely
    resembling a feature -- even if it's been discussed to death.

-   Bugfix Checkin Freeze Saturday (Oct 7)
    Starting Saturday, all checkins must be coordinated with the
    releasemeister (still Jeremy).

-   Release Candidate Monday (Oct 9)

-   Final Release Monday week (Oct 16)

Between the Release Candidate and the Final Release, all checkins must
fix bugs and must be approved by the releasemeister.

> is the repository frozen, or do we still have a chance to fix
> the GC tuple problem and SRE's "nothing to repeat" bug?

Simple bugfixes are okay till Saturday.  Bugfixes that are complex and
may break other stuff should be discussed with the releasemeister,
possibly cc'ing python-dev.

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


From Fredrik Lundh" <effbot@telia.com  Thu Oct  5 19:05:54 2000
From: Fredrik Lundh" <effbot@telia.com (Fredrik Lundh)
Date: Thu, 5 Oct 2000 20:05:54 +0200
Subject: [Python-Dev] Release candidate followed by feature freeze?
References: <200010011913.VAA01107@pandora.informatik.hu-berlin.de> <200010021919.OAA01232@cj20424-a.reston1.va.home.com> <20001002044859.A9639@glacier.fnational.com> <200010030236.VAA02702@cj20424-a.reston1.va.home.com> <20001004144350.A434@glacier.fnational.com> <00e301c02ea0$f3ea5680$0900a8c0@SPIFF> <20001004225938.A802@glacier.fnational.com> <002401c02edc$12aec3e0$766940d5@hagrid> <20001005014028.A1055@glacier.fnational.com>
Message-ID: <002a01c02ef6$ee698860$766940d5@hagrid>

neil wrote:
> Yup.  I've attached a patch which I believe fixes some GC bugs in
> addition to making it simpler.

don't have the slightest idea how the GC stuff works,
but it sure looks right: just go ahead and check it in...

> > btw, the start of Resize looks a bit strange: should that
> > DECREF really be there?  should least be an XDECREF, or
> > am I missing something?
> > 
> >  if (v == NULL || !PyTuple_Check(v) || v->ob_refcnt != 1) {
> >   *pv = 0;
> >   Py_DECREF(v); /* <- really? what if v is NULL? */
> >   PyErr_BadInternalCall();
> >   return -1;
> >  }
> 
> I think your right.  Here's a fun little program:
> 
>     from _tkinter import _flatten
>     import random # don't ask me why
>     for x in xrange(10000):
>         print x
>         t = _flatten([(0,)*x]*x)
> 
> It gives:
> 
>     0
>     1
>     2
>     3
>     4
>     5
>     Segmentation fault

guido?

</F>



From jim@digicool.com  Thu Oct  5 19:10:42 2000
From: jim@digicool.com (Jim Fulton)
Date: Thu, 05 Oct 2000 14:10:42 -0400
Subject: [Python-Dev] Re: [medusa] select, signals, and "interrupted system call" (EINTR)
References: <39D74AFB.322E5187@digicool.com> <14807.35727.423642.721873@seattle.nightmare.com>
Message-ID: <39DCC422.90E4D0D5@digicool.com>

Sam Rushing wrote:
> 
> Jim Fulton writes:
>  > The asyncore main loop should check for this error in it's select
>  > call and the select module should make this error easier to check
>  > for.
> 
> It might go better into the event_loop function, which I think of as a
> more user-serviceable part.  [for example, the default loop vs. the
> one in medusa/event_loop.py that supports schedulable events]

Don't you think anyone using select on Unix would want this?
This isn't really an application-specific thing is it?

>  > I presume that this works in Python 1.6/2.0, but I
>  > haven't tried it yet?
>  >
>  > This depends on the structure of select.error values
>  > and requires that we get EINTR from somewhere. (What
>  > should the value be on NT?)
> 
> If it's a big problem, I guess we could use a different default
> event_loop() function for win32 vs. unix.

Or we could put this in the poll function and reraise the error on 
NT, as my change does.
 
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 aahz@pobox.com  Thu Oct  5 20:52:47 2000
From: aahz@pobox.com (aahz@pobox.com)
Date: Thu, 5 Oct 2000 12:52:47 -0700 (PDT)
Subject: [Python-Dev] forwarded message from aahz@panix.com
In-Reply-To: <200010051822.NAA14228@cj20424-a.reston1.va.home.com> from "Guido van Rossum" at Oct 05, 2000 01:22:49 PM
Message-ID: <200010051952.PAA05883@panix6.panix.com>

> [Aahz]
>> Someone just pointed out on c.l.py that we need an HTMLescape() function
>> that takes a string and converts special characters to entities.  I'm
>> not on python-dev, so could you please forward this and find out whether
>> I need to run a PEP?
> 
> Has someone pointed out yet that this is done by cgi.escape()?

Yeah, I missed that earlier.  But after thinking some more, there are a
fair number of browser-like bits of software that fail to render many of
the special characters correctly (e.g. trademark).  This is frequently
due to character set issues; entities almost always render correctly,
though.  Therefore a general translation routine is probably handy.

cgi.escape() only handles "&", "<", ">".  I'm not sure whether cgi.escape
ought to be expanded to handle all characters or a new routine should be
added.  Martin van Loewis suggested xml.sax.saxutils.escape(), but I
have zero familiarity with XML and am waiting for 2.0final.  Perhaps
this should be taken off-line?
-- 
                      --- Aahz (Copyright 2000 by aahz@pobox.com)

Androgynous poly kinky vanilla queer het    <*>     http://www.rahul.net/aahz/
Hugs and backrubs -- I break Rule 6

There's a difference between a person who gets shit zie doesn't
deserve and a person who gets more shit than zie deserves.  --Aahz


From skip@mojam.com (Skip Montanaro)  Thu Oct  5 20:54:56 2000
From: skip@mojam.com (Skip Montanaro) (Skip Montanaro)
Date: Thu, 5 Oct 2000 14:54:56 -0500 (CDT)
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src configure,1.157,1.158 configure.in,1.166,1.167
In-Reply-To: <200010051845.LAA16072@slayer.i.sourceforge.net>
References: <200010051845.LAA16072@slayer.i.sourceforge.net>
Message-ID: <14812.56464.380651.537610@beluga.mojam.com>

    Barry> Apparently, on SunOS 4.1.4_JL (and other?) OSes, -d on an empty
    Barry> string always returns true.  This closes SF bug #115392.

There was a big thread recently on the tramp mailing list (similar to efs
for remote file editing in Emacs, but uses ssh/scp instead) about trying to
find a portable way to test for the existence of a file.  After trying all
sorts of stuff, the final result was pretty ugly, as I recall.

-- 
Skip Montanaro (skip@mojam.com)
http://www.mojam.com/
http://www.musi-cal.com/


From guido@python.org  Thu Oct  5 22:07:29 2000
From: guido@python.org (Guido van Rossum)
Date: Thu, 05 Oct 2000 16:07:29 -0500
Subject: [Python-Dev] forwarded message from aahz@panix.com
In-Reply-To: Your message of "Thu, 05 Oct 2000 12:52:47 MST."
 <200010051952.PAA05883@panix6.panix.com>
References: <200010051952.PAA05883@panix6.panix.com>
Message-ID: <200010052107.QAA20988@cj20424-a.reston1.va.home.com>

> Yeah, I missed that earlier.  But after thinking some more, there are a
> fair number of browser-like bits of software that fail to render many of
> the special characters correctly (e.g. trademark).  This is frequently
> due to character set issues; entities almost always render correctly,
> though.  Therefore a general translation routine is probably handy.

But character set issues also make it impossible to provide such a
translation routine: the current party line is that the encoding of
8-bit strings is unknown and that only ASCII can be assumed.

> cgi.escape() only handles "&", "<", ">".  I'm not sure whether cgi.escape
> ought to be expanded to handle all characters or a new routine should be
> added.  Martin van Loewis suggested xml.sax.saxutils.escape(), but I
> have zero familiarity with XML and am waiting for 2.0final.  Perhaps
> this should be taken off-line?

xml.sax.saxutils.escape() is a generalization of cgi.escape() -- read
the source (Lib/xml/sax/saxutils.py).  It allows you to specify
additional things to be replaced by entities by passing in a
dictionary mapping chars (or strings) to entities.

If you know that you are dealing with Latin-1, you could use the table
in htmlentitydefs.py to construct a table.

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


From jeremy@beopen.com  Thu Oct  5 21:13:34 2000
From: jeremy@beopen.com (Jeremy Hylton)
Date: Thu, 5 Oct 2000 16:13:34 -0400 (EDT)
Subject: [Python-Dev] forwarded message from aahz@panix.com
In-Reply-To: <200010051952.PAA05883@panix6.panix.com>
References: <200010051822.NAA14228@cj20424-a.reston1.va.home.com>
 <200010051952.PAA05883@panix6.panix.com>
Message-ID: <14812.57582.25916.131290@bitdiddle.concentric.net>

>>>>> "AM" == aahz  <aahz@panix.com> writes:

  >> [Aahz]
  >>> Someone just pointed out on c.l.py that we need an HTMLescape()
  >>> function that takes a string and converts special characters to
  >>> entities.  I'm not on python-dev, so could you please forward
  >>> this and find out whether I need to run a PEP?
  >>
  >> Has someone pointed out yet that this is done by cgi.escape()?

  AM> Yeah, I missed that earlier.  But after thinking some more,
  AM> there are a fair number of browser-like bits of software that
  AM> fail to render many of the special characters correctly
  AM> (e.g. trademark).  This is frequently due to character set
  AM> issues; entities almost always render correctly, though.
  AM> Therefore a general translation routine is probably handy.

  AM> cgi.escape() only handles "&", "<", ">".  I'm not sure whether
  AM> cgi.escape ought to be expanded to handle all characters or a
  AM> new routine should be added.  Martin van Loewis suggested
  AM> xml.sax.saxutils.escape(), but I have zero familiarity with XML
  AM> and am waiting for 2.0final.  Perhaps this should be taken
  AM> off-line?

Perhaps we should take it to python-list -- or maybe we should form a
web-sig and work on it there.

There are definitely some tricky issues to work out.  I attempted to
work out some of the same issues for internationalization support in
Mailman's pipermail archives.

The escape function in cgi should stay minimal, because it deals with
the only truly essential characters.  If the browser interprets an
HTML page as iso-8859-1 ("Latin 1") then characters > chr(127) are
going to be rendered properly.  You can add an explicit meta tag to
the HTML page and the server will return the charset in the headers.

This seems quite a bit simpler than trying to escape all characters >
chr(127), except if you have to deal with old browsers that don't
support the charset specified by the HTTP header.

Jeremy


From thomas@xs4all.net  Thu Oct  5 22:40:22 2000
From: thomas@xs4all.net (Thomas Wouters)
Date: Thu, 5 Oct 2000 23:40:22 +0200
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src configure,1.157,1.158 configure.in,1.166,1.167
In-Reply-To: <200010051845.LAA16072@slayer.i.sourceforge.net>; from bwarsaw@users.sourceforge.net on Thu, Oct 05, 2000 at 11:45:55AM -0700
References: <200010051845.LAA16072@slayer.i.sourceforge.net>
Message-ID: <20001005234022.I12812@xs4all.nl>

On Thu, Oct 05, 2000 at 11:45:55AM -0700, Barry Warsaw wrote:
> Update of /cvsroot/python/python/dist/src
> In directory slayer.i.sourceforge.net:/tmp/cvs-serv14007

> Modified Files:
> 	configure configure.in 
> Log Message:
> Change all occurances of
> 
> 	test -d "$directory"
> to
> 	test ! -z "directory" -a -d "directory"

> Apparently, on SunOS 4.1.4_JL (and other?) OSes, -d on an empty string
> always returns true.  This closes SF bug #115392.

> --- 3103,3110 ----
>       USE_THREAD_MODULE="#"
>   else
> !     if test ! -z $with_threads -a -d $with_threads
>       then LDFLAGS="$LDFLAGS -L$with_threads"
>       fi
> !     if test ! -z $withval -a -d $withval
>       then LDFLAGS="$LDFLAGS -L$withval"
>       fi

Is this really going to work ? I always see 'portable' shell code do
something like

if [ "X${spam}" != "X" ] ...

instead of 'test -z', eventhough even BSDI test has -z. (The portable code
I'm talking about are mostly BSDI /etc/rc* scripts... BSDI's /bin/sh is
minimal, compared to modern day equivalents.) My /bin/sh-knowledge is
decidedly less impressive than my Python knowledge, but I thought something
like 

if test ! -z $withval -a -d $withval

where $withval is empty, would be parsed as

if test ! -z -a -d

which would be, uhm, wrong ? But like I said, I don't really know what I'm
talking about here, there could be another perfectly valid reason for BSDI
to use the roundabout way, instead of using -z.

-- 
Thomas Wouters <thomas@xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!


From jeremy@beopen.com  Thu Oct  5 23:12:09 2000
From: jeremy@beopen.com (Jeremy Hylton)
Date: Thu, 5 Oct 2000 18:12:09 -0400 (EDT)
Subject: [Python-Dev] Proposal -- makefile patches and scripts to generate python RPMs
In-Reply-To: <200010051833.NAA14356@cj20424-a.reston1.va.home.com>
References: <200010050744.JAA00782@loewis.home.cs.tu-berlin.de>
 <200010051833.NAA14356@cj20424-a.reston1.va.home.com>
Message-ID: <14812.64697.601359.920302@bitdiddle.concentric.net>

>>>>> "GvR" =3D=3D Guido van Rossum <guido@python.org> writes:

  GvR> Whatever the outcome of this discussion, this is too late for
  GvR> 2.0.  But I tend to side with Jeremy and Martin -- "explicit is
  GvR> better".  I do want Jeremy to check his RPM generation scripts
  GvR> in, so they can be improved in a truly open source project.
  GvR> (Maybe in Tools/rpm?)

I don't actually use a script to generate the RPM.  I wrote a .spec
file by hand and use it to generate the RPMs using the rpm command.
I could check in the spec file, which I would end up changing every
time we do a release -- to update the version number, change the
Setup.in patch, etc.  I should probably also include the patch file
along with the .spec file.

I also wrote a smal distutils setup script for 2.0b2, which I should
check in somewhere.  Not sure where...

BTW, I've attached the spec file below.  You can get it from the
.src.rpm on pythonlabs.com, but that's pretty inconvenient if you're
merely curious.

Jeremy

%define name BeOpen-Python
%define version 2.0b2
%define release 1
%define __prefix /usr/local

Summary: An interpreted, interactive, object-oriented programming langu=
age.
Name: %{name}
Version: %{version}
Release: %{release}
Copyright: Modified CNRI Open Source License
Group: Development/Languages
Source: %{name}-%{version}.tar.bz2
Source1: html-%{version}.tar.bz2
Patch0: %{name}-%{version}-Setup.patch
BuildRoot: /var/tmp/%{name}-%{version}-root
Prefix: %{__prefix}
URL: http://www.pythonlabs.com/
Vendor: BeOpen PythonLabs
Packager: Jeremy Hylton <jeremy@beopen.com>

%description
Python is an interpreted, interactive, object-oriented programming
language.  It incorporates modules, exceptions, dynamic typing, very hi=
gh
level dynamic data types, and classes. Python combines remarkable power=

with very clear syntax. It has interfaces to many system calls and
libraries, as well as to various window systems, and is extensible in C=
 or
C++. It is also usable as an extension language for applications that n=
eed
a programmable interface.  Finally, Python is portable: it runs on many=

brands of UNIX, on PCs under Windows, MS-DOS, and OS/2, and on the
Mac.

%changelog
* Thu Oct  5 2000 Jeremy Hylton <jeremy@beopen.com>
- added bin/python2.0 to files list (suggested by Martin v. L=F6wis)

* Tue Sep 26 2000 Jeremy Hylton <jeremy@beopen.com>
- updated for release 1 of 2.0b2
- use .bz2 version of Python source

* Tue Sep 12 2000 Jeremy Hylton <jeremy@beopen.com>
- Version 2 of 2.0b1
- Make the package relocatable.  Thanks to Suchandra Thapa.
- Exclude Tkinter from main RPM.  If it is in a separate RPM, it is
  easier to track Tk releases.

%prep
%setup -n Python-%{version}
%patch0=20
%setup -D -T -a 1 -n Python-%{version}
# This command drops the HTML files in the top-level build directory.
# That's not perfect, but it will do for now.

%build
./configure
make

%install
[ -d $RPM_BUILD_ROOT ] && rm -fr $RPM_BUILD_ROOT
mkdir -p $RPM_BUILD_ROOT%{__prefix}
make prefix=3D$RPM_BUILD_ROOT%{__prefix} install

%clean
rm -fr $RPM_BUILD_ROOT

%files
%defattr(-, root, root)
%{__prefix}/bin/python
%{__prefix}/bin/python2.0
%{__prefix}/man/man1/python.1
%doc Misc/README Misc/HYPE Misc/cheatsheet Misc/unicode.txt Misc/Portin=
g
%doc LICENSE Misc/ACKS Misc/BLURB.* Misc/HISTORY Misc/NEWS
%doc index.html modindex.html api dist doc ext inst lib mac ref tut ico=
ns

%dir %{__prefix}/include/python2.0
%{__prefix}/include/python2.0/*.h
%dir %{__prefix}/lib/python2.0/
%{__prefix}/lib/python2.0/*.py*
%{__prefix}/lib/python2.0/pdb.doc
%{__prefix}/lib/python2.0/profile.doc
%dir %{__prefix}/lib/python2.0/config
%{__prefix}/lib/python2.0/config/Makefile
%{__prefix}/lib/python2.0/config/Makefile.pre.in
%{__prefix}/lib/python2.0/config/Setup
%{__prefix}/lib/python2.0/config/Setup.config
%{__prefix}/lib/python2.0/config/Setup.local
%{__prefix}/lib/python2.0/config/config.c
%{__prefix}/lib/python2.0/config/config.c.in
%{__prefix}/lib/python2.0/config/install-sh
%{__prefix}/lib/python2.0/config/libpython2.0.a
%{__prefix}/lib/python2.0/config/makesetup
%{__prefix}/lib/python2.0/config/python.o
%dir %{__prefix}/lib/python2.0/curses
%{__prefix}/lib/python2.0/curses/*.py*
%dir %{__prefix}/lib/python2.0/distutils
%{__prefix}/lib/python2.0/distutils/*.py*
%{__prefix}/lib/python2.0/distutils/README
%dir %{__prefix}/lib/python2.0/distutils/command
%{__prefix}/lib/python2.0/distutils/command/*.py*
%{__prefix}/lib/python2.0/distutils/command/command_template
%dir %{__prefix}/lib/python2.0/encodings
%{__prefix}/lib/python2.0/encodings/*.py*
%dir %{__prefix}/lib/python2.0/lib-dynload
%dir %{__prefix}/lib/python2.0/lib-tk
%{__prefix}/lib/python2.0/lib-tk/*.py*
%{__prefix}/lib/python2.0/lib-dynload/_codecsmodule.so
%{__prefix}/lib/python2.0/lib-dynload/_cursesmodule.so
%{__prefix}/lib/python2.0/lib-dynload/_localemodule.so
%{__prefix}/lib/python2.0/lib-dynload/arraymodule.so
%{__prefix}/lib/python2.0/lib-dynload/binascii.so
%{__prefix}/lib/python2.0/lib-dynload/cPickle.so
%{__prefix}/lib/python2.0/lib-dynload/cStringIO.so
%{__prefix}/lib/python2.0/lib-dynload/cmathmodule.so
%{__prefix}/lib/python2.0/lib-dynload/errnomodule.so
%{__prefix}/lib/python2.0/lib-dynload/fcntlmodule.so
%{__prefix}/lib/python2.0/lib-dynload/gdbmmodule.so
%{__prefix}/lib/python2.0/lib-dynload/grpmodule.so
%{__prefix}/lib/python2.0/lib-dynload/linuxaudiodev.so
%{__prefix}/lib/python2.0/lib-dynload/mathmodule.so
%{__prefix}/lib/python2.0/lib-dynload/md5module.so
%{__prefix}/lib/python2.0/lib-dynload/mmapmodule.so
%{__prefix}/lib/python2.0/lib-dynload/newmodule.so
%{__prefix}/lib/python2.0/lib-dynload/operator.so
%{__prefix}/lib/python2.0/lib-dynload/parsermodule.so
%{__prefix}/lib/python2.0/lib-dynload/pwdmodule.so
%{__prefix}/lib/python2.0/lib-dynload/pyexpat.so
%{__prefix}/lib/python2.0/lib-dynload/readline.so
%{__prefix}/lib/python2.0/lib-dynload/resource.so
%{__prefix}/lib/python2.0/lib-dynload/rotormodule.so
%{__prefix}/lib/python2.0/lib-dynload/selectmodule.so
%{__prefix}/lib/python2.0/lib-dynload/shamodule.so
%{__prefix}/lib/python2.0/lib-dynload/_socketmodule.so
%{__prefix}/lib/python2.0/lib-dynload/stropmodule.so
%{__prefix}/lib/python2.0/lib-dynload/structmodule.so
%{__prefix}/lib/python2.0/lib-dynload/syslogmodule.so
%{__prefix}/lib/python2.0/lib-dynload/termios.so
%{__prefix}/lib/python2.0/lib-dynload/timemodule.so
%{__prefix}/lib/python2.0/lib-dynload/ucnhash.so
%{__prefix}/lib/python2.0/lib-dynload/unicodedata.so
%{__prefix}/lib/python2.0/lib-dynload/zlibmodule.so
%dir %{__prefix}/lib/python2.0/lib-old
%{__prefix}/lib/python2.0/lib-old/*.py*
%dir %{__prefix}/lib/python2.0/plat-linux2
%{__prefix}/lib/python2.0/plat-linux2/*.py*
%{__prefix}/lib/python2.0/plat-linux2/regen
%dir %{__prefix}/lib/python2.0/site-packages
%{__prefix}/lib/python2.0/site-packages/README
%dir %{__prefix}/lib/python2.0/test
%{__prefix}/lib/python2.0/test/*.py*
%{__prefix}/lib/python2.0/test/README
%{__prefix}/lib/python2.0/test/audiotest.au
%{__prefix}/lib/python2.0/test/greyrgb.uue
%{__prefix}/lib/python2.0/test/test.xml
%{__prefix}/lib/python2.0/test/testimg.uue
%{__prefix}/lib/python2.0/test/testimgr.uue
%{__prefix}/lib/python2.0/test/testrgb.uue
%dir %{__prefix}/lib/python2.0/test/output
%{__prefix}/lib/python2.0/test/output/test_*
%dir %{__prefix}/lib/python2.0/xml
%{__prefix}/lib/python2.0/xml/*.py*
%dir %{__prefix}/lib/python2.0/xml/dom
%{__prefix}/lib/python2.0/xml/dom/*.py*
%dir %{__prefix}/lib/python2.0/xml/sax
%{__prefix}/lib/python2.0/xml/sax/*.py*


From fdrake@beopen.com  Fri Oct  6 01:14:20 2000
From: fdrake@beopen.com (Fred L. Drake, Jr.)
Date: Thu, 5 Oct 2000 20:14:20 -0400 (EDT)
Subject: [Python-Dev] forwarded message from Gerald Pfeifer
Message-ID: <14813.6492.879919.445014@cj42289-a.reston1.va.home.com>

--uThC8vgBh0
Content-Type: text/plain; charset=us-ascii
Content-Description: message body and .signature
Content-Transfer-Encoding: 7bit


  I just got this message from the gcc-announce list.  We've seen bug
reports related to GCC 2.96 (which may or may not be the problem).  We
need to be aware that these releases are out there and can be a
problem.
  I've noticed that the version of GCC shipped with Mandrake 7.1 is
"gcc version 2.95.3 19991030 (prerelease)", which doesn't give my much
confidence either.  ;(


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member


--uThC8vgBh0
Content-Type: message/rfc822
Content-Description: forwarded message
Content-Transfer-Encoding: 7bit

Received: by ns1.beopen.com (mbox fdrake)
 (with Cubic Circle's cucipop (v1.31 1998/05/13) Thu Oct  5 17:12:18 2000)
X-From_: gcc-announce-return-24-fdrake=acm.org@gcc.gnu.org Thu Oct  5 17:07:40 2000
Return-Path: <gcc-announce-return-24-fdrake=acm.org@gcc.gnu.org>
Received: from mail.acm.org (mail.acm.org [199.222.69.4])
	by ns1.beopen.com (8.9.3/8.9.3) with ESMTP id RAA90031
	for <fdrake@beopen.com>; Thu, 5 Oct 2000 17:07:39 -0700 (PDT)
	(envelope-from gcc-announce-return-24-fdrake=acm.org@gcc.gnu.org)
Received: from sourceware.cygnus.com (sourceware.cygnus.com [205.180.83.71])
	by mail.acm.org (8.9.3/8.9.3) with SMTP id UAA45682
	for <fdrake@acm.org>; Thu, 5 Oct 2000 20:05:32 -0400
Received: (qmail 23247 invoked by alias); 6 Oct 2000 00:03:53 -0000
Mailing-List: contact gcc-announce-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:gcc-announce-unsubscribe-fdrake=acm.org@gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-announce/>
List-Post: <mailto:gcc-announce@gcc.gnu.org>
List-Help: <mailto:gcc-announce-help@gcc.gnu.org>
Delivered-To: mailing list gcc-announce@gcc.gnu.org
Delivered-To: moderator for gcc-announce@gcc.gnu.org
Received: (qmail 20621 invoked from network); 5 Oct 2000 23:58:16 -0000
Message-ID: <Pine.BSF.4.21.0010060152140.89168-100000@deneb.dbai.tuwien.ac.at>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
From: Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at>
Sender: gcc-announce-owner@gcc.gnu.org
To: gcc-announce@gcc.gnu.org
Subject: GCC 2.96
Date: Fri, 6 Oct 2000 01:58:11 +0200 (CEST)

It has come to our attention that some GNU/Linux distributions are
currently shipping with ``GCC 2.96''.

We would like to point out that GCC 2.96 is not a formal GCC release nor
will there ever be such a release.  Rather, GCC 2.96 has been the code-
name for our development branch that will eventually become GCC 3.0.

Current snapshots of GCC, and any version labeled 2.96, produce object
files that are not compatible with those produced by either GCC 2.95.2 or
the forthcoming GCC 3.0.  Therefore, programs built with these snapshots
will not be compatible with any official GCC release.  Actually, C and
Fortran code will probably be compatible, but code in other languages,
most notably C++ due to incompatibilities in symbol encoding (``mangling''),
the standard library and the application binary interface (ABI), is likely
to fail in some way.  Static linking against C++ libraries may make a
binary more portable, at the cost of increasing file size and memory use.

To avoid any confusion, we have bumped the version of our current
development branch to GCC 2.97.

Please note that both GCC 2.96 and 2.97 are development versions; we
do not recommend using them for production purposes.  Binaries built
using any version of GCC 2.96 or 2.97 will not be portable to systems
based on one of our regular releases.

If you encounter a bug in a compiler labeled 2.96, we suggest you
contact whoever supplied the compiler as we can not support 2.96
versions that were not issued by the GCC team.

Please see http://gcc.gnu.org/snapshots.html if you want to use our
latest snapshots.  We suggest you use 2.95.2 if you are uncertain.

The GCC Steering Committee <http://gcc.gnu.org/steering.html>



--uThC8vgBh0--



From thomas@xs4all.net  Fri Oct  6 01:29:11 2000
From: thomas@xs4all.net (Thomas Wouters)
Date: Fri, 6 Oct 2000 02:29:11 +0200
Subject: [Python-Dev] forwarded message from Gerald Pfeifer
In-Reply-To: <14813.6492.879919.445014@cj42289-a.reston1.va.home.com>; from fdrake@beopen.com on Thu, Oct 05, 2000 at 08:14:20PM -0400
References: <14813.6492.879919.445014@cj42289-a.reston1.va.home.com>
Message-ID: <20001006022910.J12812@xs4all.nl>

On Thu, Oct 05, 2000 at 08:14:20PM -0400, Fred L. Drake, Jr. wrote:

>   I just got this message from the gcc-announce list.  We've seen bug
> reports related to GCC 2.96 (which may or may not be the problem).  We
> need to be aware that these releases are out there and can be a
> problem.
>   I've noticed that the version of GCC shipped with Mandrake 7.1 is
> "gcc version 2.95.3 19991030 (prerelease)", which doesn't give my much
> confidence either.  ;(

The 'unstable' branch of Debian currently ships with:
gcc version 2.95.2 20000220 (Debian GNU/Linux)

and it seems to be working fine. I did notice a problem, but it was related
to glibc 2.1.94, not gcc: LONG_BIT was wrongly defined to 64. Tim's
sanity-check, which checks LONG_BIT against (SIZEOF_LONG * 8), would have
caught that one, but I found it on my machine before he checked in that fix
;) For me, that problem was caused by the /usr/include/bits/xopen_lim.h
include file:

/* Number of bits in a word of type ong int'.  */
#if LONG_MAX == 2147483647
# define LONG_BIT       32
#else
/* Safe assumption.  */
# define LONG_BIT       64
#endif

where LONG_MAX was not defined (yet). I fixed it 'manually' for more than
just Python by adding

#ifndef LONG_MAX
#define LONG_MAX 2147483647
#endif

above it. I had to laugh, though, when I saw that assuming longs had 64 bits
is considered 'a safe assumption'. I guess most people use 64 bit machines
nowadays ? :-) 

I'm not complaining about this, though. Woody (Debian's current unstable
tree) is bleeding edge, and I'm fully prepared to live with it. In fact, I
love it! But people testing out glibc 2.1.90+ should keep this in mind. I'm
also wondering where to send my bugreport, but I think I'll read some
documentation before I do that, first ;)

-- 
Thomas Wouters <thomas@xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!


From fdrake@beopen.com  Fri Oct  6 02:37:40 2000
From: fdrake@beopen.com (Fred L. Drake, Jr.)
Date: Thu, 5 Oct 2000 21:37:40 -0400 (EDT)
Subject: [Python-Dev] forwarded message from Gerald Pfeifer
In-Reply-To: <20001006022910.J12812@xs4all.nl>
References: <14813.6492.879919.445014@cj42289-a.reston1.va.home.com>
 <20001006022910.J12812@xs4all.nl>
Message-ID: <14813.11492.123197.791450@cj42289-a.reston1.va.home.com>

Thomas Wouters writes:
 > The 'unstable' branch of Debian currently ships with:
 > gcc version 2.95.2 20000220 (Debian GNU/Linux)
 > 
 > and it seems to be working fine. I did notice a problem, but it was related

  I understand this to be the latest "stable" version of GCC, and it
appearantly it has been accepted as such for a while now.

 > above it. I had to laugh, though, when I saw that assuming longs had 64 bits
 > is considered 'a safe assumption'. I guess most people use 64 bit machines
 > nowadays ? :-) 

  Hey, my machine is 4294967296 bits!  Forget those ancient 64 bit
machines!  ;-)

 > I'm not complaining about this, though. Woody (Debian's current unstable
 > tree) is bleeding edge, and I'm fully prepared to live with it. In fact, I
 > love it! But people testing out glibc 2.1.90+ should keep this in mind. I'm

  I'm less concerned about people who know they're deliberatly putting
themselves on the bleeding edge than the people that pick up the
latest version of some Linux distribution and find they have a buggy
compiler because the distribution builders weren't as careful as
perhaps they should have been.  Putting together a professional grade
Linux distro is still a very hard thing.
  There's no such thing as enough testing here!


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member



From MarkH@ActiveState.com  Fri Oct  6 04:52:13 2000
From: MarkH@ActiveState.com (Mark Hammond)
Date: Fri, 6 Oct 2000 14:52:13 +1100
Subject: [Python-Dev] RE: buffer overlow in PC/getpathp.c
In-Reply-To: <ECEPKNMJLHAPFFJHDOJBEEGADLAA.MarkH@ActiveState.com>
Message-ID: <ECEPKNMJLHAPFFJHDOJBIEHDDMAA.MarkH@ActiveState.com>

[Me, responding to Jeremy's request I look for potential buffer exploits on
Windows...]

> I will be happy to look into this.

And was :-)

If anyone has time over the next day or 2, any holes I either missed, or
added(!) in
http://sourceforge.net/patch/?func=detailpatch&patch_id=101801&group_id=547
0 would be appreciated!

Thanks,

Mark.



From thomas.heller@ion-tof.com  Fri Oct  6 08:20:56 2000
From: thomas.heller@ion-tof.com (Thomas Heller)
Date: Fri, 6 Oct 2000 09:20:56 +0200
Subject: [Python-Dev] Proposal -- makefile patches and scripts to generate python RPMs
References: <200010050744.JAA00782@loewis.home.cs.tu-berlin.de><200010051833.NAA14356@cj20424-a.reston1.va.home.com> <14812.64697.601359.920302@bitdiddle.concentric.net>
Message-ID: <003d01c02f65$fb409550$4500a8c0@thomasnotebook>

> I don't actually use a script to generate the RPM.  I wrote a .spec
> file by hand and use it to generate the RPMs using the rpm command.
> I could check in the spec file, which I would end up changing every
> time we do a release -- to update the version number, change the
> Setup.in patch, etc.  I should probably also include the patch file
> along with the .spec file.
> 
> I also wrote a smal distutils setup script for 2.0b2, which I should
> check in somewhere.  Not sure where...
> 
Could you post this script?

Thomas



From loewis@informatik.hu-berlin.de  Thu Oct  5 20:49:26 2000
From: loewis@informatik.hu-berlin.de (Martin von Loewis)
Date: Thu, 5 Oct 2000 21:49:26 +0200 (MET DST)
Subject: [Python-Dev] PEP 4: Deprecation of standard modules
Message-ID: <200010051949.VAA04764@pandora.informatik.hu-berlin.de>

I just finished a first draft of a PEP on deprecating (and eventually
removing) modules from the standard Python library; it is available
from

http://python.sourceforge.net/peps/pep-0004.html

If you have comments or suggestions on the proposed procedures, or the
wording of the text, please send me a message. According to the PEP
procedures (PEP 1), this is the preferred way of progressing this PEP
(rather than discussing it on these lists), at least initially.

Regards,
Martin



From loewis@informatik.hu-berlin.de  Fri Oct  6 13:39:05 2000
From: loewis@informatik.hu-berlin.de (Martin von Loewis)
Date: Fri, 6 Oct 2000 14:39:05 +0200 (MET DST)
Subject: [Python-Dev] htmllib.HTMLescape()
Message-ID: <200010061239.OAA13090@pandora.informatik.hu-berlin.de>

> The difficulty, I assume, lies in figuring out which encodings
> support what characters.

It's not that difficult to write a set of new codecs; with the module
below, I can do

>>> import xmlenc
>>> u'\u0416'.encode('latin-1-xml')
'&#x416;'
>>> unicode('X&#x245;Y','latin-1-xml')
u'X\u0245Y'

The difficulty is that the algorithm is not very efficient if there
are many unsupported characters in a string.

Regards,
Martin

# Module implementing a set of new encodings of the form <enc>-xml
# Copyright Martin v. L&ouml;wis
# It currently supports hex character references only

import codecs

class CodecWrapper:
    def __init__(self,encoder,decoder):
        self.encoder = encoder
        self.decoder = decoder

    def encode(self,input,errors='strict'):
        try:
            return self.encoder(input,"strict")
        except ValueError:
            l = len(input)
            if l==1:
                return "&#x%x;" % ord(input), 1
            s1,l1 = self.encode(input[:l/2])
            s2,l2 = self.encode(input[l/2:])
            return s1+s2,l1+l2

    def decode(self,input,errors='strict'):
        input = str(input) # might be buffer object
        pos = input.find("&#x")
        if pos == -1:
            return self.decoder(input,errors)
        r1,l1 = self.decode(input[:pos],errors)
        end = input.find(";",pos)
        try:
            if end==-1:
                raise ValueError # goto failure code below
            val = int(input[pos+3:end],16)
            r2,l2 = self.decode(input[end+1:],errors)
            return r1+unichr(val)+r2,l1+end-pos+l2
        except ValueError:
            # how to deal with errors in decode?
            r2,l2 = self.decode(input[pos+2:],errors)
            return r1+"&#x"+r2,l1+3+l2

    def mkreader(self):
        r = codecs.StreamReader()
        r.decode = self.decode
        r.encode = self.encode
        return r

    def mkwriter(self):
        r = codecs.StreamWriter()
        r.decode = self.decode
        r.encode = self.encode
        return r

def search_function(encoding):
    if not encoding.endswith("-xml"):
        return None
    enc,dec,reader,writer = codecs.lookup(encoding[:-4])
    c = CodecWrapper(enc,dec)
    return c.encode,c.decode,c.mkreader,c.mkwriter

codecs.register(search_function)


From jeremy@beopen.com  Fri Oct  6 15:54:03 2000
From: jeremy@beopen.com (Jeremy Hylton)
Date: Fri, 6 Oct 2000 10:54:03 -0400 (EDT)
Subject: [Python-Dev] Proposal -- makefile patches and scripts to generate python RPMs
In-Reply-To: <003d01c02f65$fb409550$4500a8c0@thomasnotebook>
References: <200010050744.JAA00782@loewis.home.cs.tu-berlin.de>
 <200010051833.NAA14356@cj20424-a.reston1.va.home.com>
 <14812.64697.601359.920302@bitdiddle.concentric.net>
 <003d01c02f65$fb409550$4500a8c0@thomasnotebook>
Message-ID: <14813.59275.350667.580400@bitdiddle.concentric.net>

--cQL1MOyU0I
Content-Type: text/plain; charset=us-ascii
Content-Description: message body text
Content-Transfer-Encoding: 7bit

Here is the setup script I used to build the Tk RPMs.  The name and
version part is a mess and I would welcome suggestions on how to fix
it.  The problem is that Tkinter gets built against a particular
version of Python and a particular version of Tcl/Tk.  I want the name
of the RPM to indiciate both versions, but didn't seem an obvious way
to accomplish it.  Thus, I put the Python version number in the name
and the Tcl/Tk version number in the version.  Otherwise, I think this
is pretty straightforward distutils stuff (although the documentation
was out of date last I checked).

I've attached three files.  I wrote setup.py and setup.cfg.  Distutils
created MANIFEST.

Jeremy


--cQL1MOyU0I
Content-Type: text/plain
Content-Disposition: inline;
	filename="setup.py"
Content-Transfer-Encoding: 7bit

#! /usr/bin/env python
"""Tkinter is the Python interface to the Tk GUI toolkit.  Tk offers
native look and feel on most major platforms, including Unix, Windows,
and Macintosh.  The Tkinter-2.0 RPM contains the Python C extension
module for Python 2.0.  The Python source files are distributed with
the main Python distribution."""

from distutils.core import setup, Extension

setup(name="Tkinter-2.0",
      version="8.0",
      description="Python interface to Tk GUI toolkit",
      author="Python development team",
      author_email="pythoneers@beopen.com",
      url="http://www.pythonlabs.com/products/python2.0/",
      licence="Modified CNRI Open Source License",
      
      ext_modules=[Extension("_tkinter",
                            ["src/_tkinter.c", "src/tkappinit.c"],
                            define_macros=[('WITH_APPINIT', None)],
                            library_dirs=["/usr/X11R6/lib"],
                            libraries=["tk8.0", "tcl8.0", "X11"],
                            )],

      long_description = __doc__
      )
                                         

--cQL1MOyU0I
Content-Type: text/plain
Content-Disposition: inline;
	filename="setup.cfg"
Content-Transfer-Encoding: 7bit

[bdist_rpm]
packager = Jeremy Hylton <jeremy@beopen.com>
vendor = BeOpen PythonLabs

--cQL1MOyU0I
Content-Type: text/plain
Content-Disposition: inline;
	filename="MANIFEST"
Content-Transfer-Encoding: 7bit

setup.py
src/_tkinter.c
src/tkappinit.c

--cQL1MOyU0I--


From jeremy@beopen.com  Fri Oct  6 20:11:43 2000
From: jeremy@beopen.com (Jeremy Hylton)
Date: Fri, 6 Oct 2000 15:11:43 -0400 (EDT)
Subject: [Python-Dev] linuxaudiodev module
Message-ID: <14814.9199.422989.273484@bitdiddle.concentric.net>

I just fixed a number of major bugs in the undocumented linuxaudiodev
module.  I ended up spending about an hour reading the excellent Open
Sound System (OSS) Programmer's Guide to figure out what the module
was trying to do and why it wasn't working on my Linux box.

After reading the module and the OSS guide, it is clear to me that we
need a complete re-write.  The module itself is just a wrapper around
a bunch of read, write, and ioctl calls.  It could all be implemented
in pure Python.

I propose we develop a Python module for Python 2.1 and call it
osslib.  There is nothing at all that is Linux-specific about the
interface being used.  The OSS guide mentions a plethora of platforms
that it supports.

In the interim, I have fixed some of the most egregious problems.  I
would appreciate it if Linux users could try out the fixes and the new
test case.  On my machine it still sounds awful, but at least the
sound can be heard.

Jeremy


From akuchlin@mems-exchange.org  Fri Oct  6 20:17:39 2000
From: akuchlin@mems-exchange.org (Andrew Kuchling)
Date: Fri, 6 Oct 2000 15:17:39 -0400
Subject: [Python-Dev] linuxaudiodev module
In-Reply-To: <14814.9199.422989.273484@bitdiddle.concentric.net>; from jeremy@beopen.com on Fri, Oct 06, 2000 at 03:11:43PM -0400
References: <14814.9199.422989.273484@bitdiddle.concentric.net>
Message-ID: <20001006151739.A31189@kronos.cnri.reston.va.us>

On Fri, Oct 06, 2000 at 03:11:43PM -0400, Jeremy Hylton wrote:
>After reading the module and the OSS guide, it is clear to me that we
>need a complete re-write.  The module itself is just a wrapper around
>a bunch of read, write, and ioctl calls.  It could all be implemented
>in pure Python.

So, is there any point in releasing linuxaudiodev at all, then, if it
needs a complete rewrite?

--amk



From DavidA@ActiveState.com  Fri Oct  6 20:39:21 2000
From: DavidA@ActiveState.com (David Ascher)
Date: Fri, 6 Oct 2000 12:39:21 -0700 (Pacific Daylight Time)
Subject: [Python-Dev] linuxaudiodev module
In-Reply-To: <14814.9199.422989.273484@bitdiddle.concentric.net>
Message-ID: <Pine.WNT.4.21.0010061238130.844-100000@loom>

> I propose we develop a Python module for Python 2.1 and call it
> osslib.  There is nothing at all that is Linux-specific about the
> interface being used.  The OSS guide mentions a plethora of platforms
> that it supports.

Have you evaluated http://net.indra.com/~tim/ossmodule/

?





From jeremy@beopen.com  Fri Oct  6 20:47:27 2000
From: jeremy@beopen.com (Jeremy Hylton)
Date: Fri, 6 Oct 2000 15:47:27 -0400 (EDT)
Subject: [Python-Dev] linuxaudiodev module
In-Reply-To: <20001006151739.A31189@kronos.cnri.reston.va.us>
References: <14814.9199.422989.273484@bitdiddle.concentric.net>
 <20001006151739.A31189@kronos.cnri.reston.va.us>
Message-ID: <14814.11343.988335.520786@bitdiddle.concentric.net>

>>>>> "AMK" == Andrew Kuchling <akuchlin@mems-exchange.org> writes:

  AMK> On Fri, Oct 06, 2000 at 03:11:43PM -0400, Jeremy Hylton wrote:
  >> After reading the module and the OSS guide, it is clear to me
  >> that we need a complete re-write.  The module itself is just a
  >> wrapper around a bunch of read, write, and ioctl calls.  It could
  >> all be implemented in pure Python.

  AMK> So, is there any point in releasing linuxaudiodev at all, then,
  AMK> if it needs a complete rewrite?

I would be include to chuck it, except that it also shipped with 1.6.
I would hestitate to deprecate it so far into the release process.

jeremy


From jeremy@beopen.com  Fri Oct  6 20:47:48 2000
From: jeremy@beopen.com (Jeremy Hylton)
Date: Fri, 6 Oct 2000 15:47:48 -0400 (EDT)
Subject: [Python-Dev] linuxaudiodev module
In-Reply-To: <Pine.WNT.4.21.0010061238130.844-100000@loom>
References: <14814.9199.422989.273484@bitdiddle.concentric.net>
 <Pine.WNT.4.21.0010061238130.844-100000@loom>
Message-ID: <14814.11364.360443.940965@bitdiddle.concentric.net>

I had no idea it existed.

Jeremy


From jeremy@beopen.com  Fri Oct  6 20:54:35 2000
From: jeremy@beopen.com (Jeremy Hylton)
Date: Fri, 6 Oct 2000 15:54:35 -0400 (EDT)
Subject: [Python-Dev] linuxaudiodev module
In-Reply-To: <Pine.WNT.4.21.0010061238130.844-100000@loom>
References: <14814.9199.422989.273484@bitdiddle.concentric.net>
 <Pine.WNT.4.21.0010061238130.844-100000@loom>
Message-ID: <14814.11771.731237.214646@bitdiddle.concentric.net>

>>>>> "DA" == David Ascher <DavidA@ActiveState.com> writes:

  DA> Have you evaluated http://net.indra.com/~tim/ossmodule/

Okay.  I took a quick look.  It's really old (July 1997).  It looks
like a more reasonable wrapping than linuxaudiodev, although I would
want to review it more carefully against the OSS programmer's guide.

I would prefer a pure Python solution, because the code would be
shorter and easier to read and maintain.  It may be, however, that the
ossmodule is still up-to-date; if so, it may be easier to use it than
to rewrite it.

Jeremy



From ping@lfw.org  Fri Oct  6 22:13:39 2000
From: ping@lfw.org (Ka-Ping Yee)
Date: Fri, 6 Oct 2000 16:13:39 -0500 (CDT)
Subject: [Python-Dev] linuxaudiodev module
In-Reply-To: <14814.9199.422989.273484@bitdiddle.concentric.net>
Message-ID: <Pine.LNX.4.10.10010061609370.9837-100000@server1.lfw.org>

On Fri, 6 Oct 2000, Jeremy Hylton wrote:
> After reading the module and the OSS guide, it is clear to me that we
> need a complete re-write.  The module itself is just a wrapper around
> a bunch of read, write, and ioctl calls.  It could all be implemented
> in pure Python.

True.  I think your osslib is a good idea.  I wanted to take on this
sort of project myself a few weeks ago but never had the time to really
get started.  From playing with the test script, i think all we care
about having in C is audioop (and that's just for ulaw conversion).
I would like to fix audioop so we can expect it to be present as a
standard module; then we can have a module written in Python that
provides uniform sound support for all platforms.

> On my machine it still sounds awful, but at least the
> sound can be heard.

It should not sound awful.  If it sounds too loud and scratchy, then
maybe you need to use audioop to convert from Sun .au (ulaw) to raw
samples first.  This was the case with the Spanish inquisition clip.


-- ?!ng



From jeremy@beopen.com  Fri Oct  6 23:28:57 2000
From: jeremy@beopen.com (Jeremy Hylton)
Date: Fri, 6 Oct 2000 18:28:57 -0400 (EDT)
Subject: [Python-Dev] linuxaudiodev module
In-Reply-To: <Pine.LNX.4.10.10010061609370.9837-100000@server1.lfw.org>
References: <14814.9199.422989.273484@bitdiddle.concentric.net>
 <Pine.LNX.4.10.10010061609370.9837-100000@server1.lfw.org>
Message-ID: <14814.21033.195290.728159@bitdiddle.concentric.net>

>>>>> "KPY" == Ka-Ping Yee <ping@lfw.org> writes:

  >> On my machine it still sounds awful, but at least the sound can
  >> be heard.

  KPY> It should not sound awful.  If it sounds too loud and scratchy,
  KPY> then maybe you need to use audioop to convert from Sun .au
  KPY> (ulaw) to raw samples first.  This was the case with the
  KPY> Spanish inquisition clip.

I don't think I know how to do that.  I tried using sox to convert
audiotest.au to audiotest.raw and it sounded just as bad on my
machine.  Perhaps I have my machine configured incorrectly, although
CDs and Real Audio sound fine.

Have you tried the new code, BTW?  Does the test work on your machine?

Jeremy


From tim_one@email.msn.com  Fri Oct  6 23:28:53 2000
From: tim_one@email.msn.com (Tim Peters)
Date: Fri, 6 Oct 2000 18:28:53 -0400
Subject: [Python-Dev] test_StringIO broken
Message-ID: <LNBBLJKPBEHFEDALKOLCCEAMHKAA.tim_one@email.msn.com>

test test_StringIO failed -- Writing: "'abcde'", expected: 'abcdefg'
1 test failed: test_StringIO

This on Win98SE, broke sometime late this afternoon (EDT).  Working
elsewhere?




From jeremy@beopen.com  Fri Oct  6 23:59:41 2000
From: jeremy@beopen.com (Jeremy Hylton)
Date: Fri, 6 Oct 2000 18:59:41 -0400 (EDT)
Subject: [Python-Dev] test_StringIO broken
In-Reply-To: <LNBBLJKPBEHFEDALKOLCCEAMHKAA.tim_one@email.msn.com>
References: <LNBBLJKPBEHFEDALKOLCCEAMHKAA.tim_one@email.msn.com>
Message-ID: <14814.22877.882280.651958@bitdiddle.concentric.net>

The test was changed in a number of ways, but whoever checked it in
didn't actually run the regression test!

Also, the last messsage I see printed is:
Failed to catch ValueError writing to closed StringIO.

This ain't a case of forgetting to generate new output.  This is just
plain wrong.

Jeremy


From thomas@xs4all.net  Fri Oct  6 23:56:08 2000
From: thomas@xs4all.net (Thomas Wouters)
Date: Sat, 7 Oct 2000 00:56:08 +0200
Subject: [Python-Dev] test_StringIO broken
In-Reply-To: <LNBBLJKPBEHFEDALKOLCCEAMHKAA.tim_one@email.msn.com>; from tim_one@email.msn.com on Fri, Oct 06, 2000 at 06:28:53PM -0400
References: <LNBBLJKPBEHFEDALKOLCCEAMHKAA.tim_one@email.msn.com>
Message-ID: <20001007005608.K12812@xs4all.nl>

On Fri, Oct 06, 2000 at 06:28:53PM -0400, Tim Peters wrote:
> test test_StringIO failed -- Writing: "'abcde'", expected: 'abcdefg'
> 1 test failed: test_StringIO

> This on Win98SE, broke sometime late this afternoon (EDT).  Working
> elsewhere?

No. Fails the same way on my Linux box. And the problem is probably that the
test was updated (two tests were uncommented) but the output file wasn't
updated. Jim Fulton did the checkin, so he looks like the right person to
fix it (and manually check that the generated output file is *correct*, of
course ! ;)

-- 
Thomas Wouters <thomas@xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!


From DavidA@ActiveState.com  Sat Oct  7 00:01:37 2000
From: DavidA@ActiveState.com (David Ascher)
Date: Fri, 6 Oct 2000 16:01:37 -0700 (Pacific Daylight Time)
Subject: [Python-Dev] linuxaudiodev module
In-Reply-To: <14814.11771.731237.214646@bitdiddle.concentric.net>
Message-ID: <Pine.WNT.4.21.0010061600590.844-100000@loom>

> Okay.  I took a quick look.  It's really old (July 1997).  It looks
> like a more reasonable wrapping than linuxaudiodev, although I would
> want to review it more carefully against the OSS programmer's guide.
> 
> I would prefer a pure Python solution, because the code would be
> shorter and easier to read and maintain.  It may be, however, that the
> ossmodule is still up-to-date; if so, it may be easier to use it than
> to rewrite it.

Absolutely.  I just remember some announcement about it.  I suspect that
what I remember is not that old, so it may make sense to do a little more
digging than I did in the archives...

--david



From thomas@xs4all.net  Fri Oct  6 23:58:19 2000
From: thomas@xs4all.net (Thomas Wouters)
Date: Sat, 7 Oct 2000 00:58:19 +0200
Subject: [Python-Dev] test_StringIO broken
In-Reply-To: <14814.22877.882280.651958@bitdiddle.concentric.net>; from jeremy@beopen.com on Fri, Oct 06, 2000 at 06:59:41PM -0400
References: <LNBBLJKPBEHFEDALKOLCCEAMHKAA.tim_one@email.msn.com> <14814.22877.882280.651958@bitdiddle.concentric.net>
Message-ID: <20001007005819.L12812@xs4all.nl>

On Fri, Oct 06, 2000 at 06:59:41PM -0400, Jeremy Hylton wrote:

> Also, the last messsage I see printed is:
> Failed to catch ValueError writing to closed StringIO.

> This ain't a case of forgetting to generate new output.  This is just
> plain wrong.

Hm, are you sure you re-built your modules before doing that ? The output
looks okay on my linux box, in any case. The last message is 'Caught
expected ValueError writing to closed StringIO: I/O operation on closed
file', for me. If you recompiled cStringIO, something odd is going on ;)

-- 
Thomas Wouters <thomas@xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!


From jeremy@beopen.com  Sat Oct  7 00:06:32 2000
From: jeremy@beopen.com (Jeremy Hylton)
Date: Fri, 6 Oct 2000 19:06:32 -0400 (EDT)
Subject: [Python-Dev] test_StringIO broken
In-Reply-To: <20001007005819.L12812@xs4all.nl>
References: <LNBBLJKPBEHFEDALKOLCCEAMHKAA.tim_one@email.msn.com>
 <14814.22877.882280.651958@bitdiddle.concentric.net>
 <20001007005819.L12812@xs4all.nl>
Message-ID: <14814.23288.490631.990498@bitdiddle.concentric.net>

>>>>> "TW" == Thomas Wouters <thomas@xs4all.net> writes:

  TW> On Fri, Oct 06, 2000 at 06:59:41PM -0400, Jeremy Hylton wrote:
  >> Also, the last messsage I see printed is: Failed to catch
  >> ValueError writing to closed StringIO.

  >> This ain't a case of forgetting to generate new output.  This is
  >> just plain wrong.

  TW> Hm, are you sure you re-built your modules before doing that ?

This is probably what went wrong for me.

Jeremy


From guido@python.org  Sat Oct  7 14:51:12 2000
From: guido@python.org (Guido van Rossum)
Date: Sat, 07 Oct 2000 08:51:12 -0500
Subject: [Python-Dev] Tcl and Unicode
In-Reply-To: Your message of "Fri, 06 Oct 2000 16:09:03 MST."
 <200010062309.QAA32052@slayer.i.sourceforge.net>
References: <200010062309.QAA32052@slayer.i.sourceforge.net>
Message-ID: <200010071351.IAA02962@cj20424-a.reston1.va.home.com>

> Fix for next iteration of SF bug 115690 (Unicode headaches in IDLE).  The
> parsing functions in support of auto-indent weren't expecting Unicode
> strings, but text.get() can now return them (although it remains muddy as
> to exactly when or why that can happen).  Fixed that with a Big Hammer.

I apologize, I should have explained when text.get() returns Unicode:

Any string returned from Tcl/Tk that contains a byte with the 8th bit
set is translated from UTF-8 into Unicode, unless the translation
fails (in which case the original raw 8-bit string is returned as a
fallback).

This *should* be correct because Tcl/Tk always uses UTF-8 internally.
(Even though it is "lenient" when receiving strings -- if a sequence
of characters has no valid Unicode representation, it appears to falls
back to Latin-1; I don't know the details of this algorithm.)

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


From tim_one@email.msn.com  Sat Oct  7 19:43:55 2000
From: tim_one@email.msn.com (Tim Peters)
Date: Sat, 7 Oct 2000 14:43:55 -0400
Subject: [Python-Dev] Tcl and Unicode
In-Reply-To: <200010071351.IAA02962@cj20424-a.reston1.va.home.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCMECEHKAA.tim_one@email.msn.com>

>> Fix for next iteration of SF bug 115690 (Unicode headaches in
>> IDLE). ...

[Guido]
> I apologize, I should have explained when text.get() returns Unicode:
>
> Any string returned from Tcl/Tk that contains a byte with the 8th bit
> set is translated from UTF-8 into Unicode, unless the translation
> fails (in which case the original raw 8-bit string is returned as a
> fallback).

Except that's *why* it was muddy <wink>:  in the specific case that popped
up in the bug, text.get() appeared to return a Unicode string of length 1
containing only a newline.  No high-bit byte appeared to be involved.
However, that was an illusion I didn't unmask until later.  All is clear
now.

> This *should* be correct because Tcl/Tk always uses UTF-8 internally.
> (Even though it is "lenient" when receiving strings -- if a sequence
> of characters has no valid Unicode representation, it appears to falls
> back to Latin-1; I don't know the details of this algorithm.)

Dunno, but wouldn't be surprised if they had a notion of default encoding,
and that it simply appears to be Latin-1 to us because American Windows uses
a superset of Latin-1.  If BeOpen would like to buy me a version of Chinese
Windows, happy to lend it to you <wink>.

as-american-as-they-come-ly y'rs  - tim




From guido@python.org  Sun Oct  8 02:41:11 2000
From: guido@python.org (Guido van Rossum)
Date: Sat, 07 Oct 2000 20:41:11 -0500
Subject: [Python-Dev] linuxaudiodev module
In-Reply-To: Your message of "Fri, 06 Oct 2000 18:28:57 -0400."
 <14814.21033.195290.728159@bitdiddle.concentric.net>
References: <14814.9199.422989.273484@bitdiddle.concentric.net> <Pine.LNX.4.10.10010061609370.9837-100000@server1.lfw.org>
 <14814.21033.195290.728159@bitdiddle.concentric.net>
Message-ID: <200010080141.UAA19858@cj20424-a.reston1.va.home.com>

I think I fixed the linuxaudio test -- see if it sounds reasonable
now!

The crux of the matter seemed to be that the last, optional argument
to setparameters(), meaning "emulate the format if the sound card
doesn't support it", is not supported right.  It suppresses the error
message, and the ioctl to set the format succeeds, but the emulation
doesn't work (at least not on my system, or on Jeremy's).

So I've used a subterfuge: assuming most sound cards support signed
16-bit native-endian format, I convert the data to that format, and
use the appropriate format code: AFMT_S16_LE for little-endian
machines, AFMT_S16_BE for big-endian machines.  I've only tested
little-endian.

I use the new sys.byteorder variable to determine the endianness.

I use the audioop module to do the conversion.  Much simpler than sox!
(Oh feeling of nostalgia...  I wrote several of the file format
handlers for sox, and fixed lots of bugs in it too...  I even started
the audio file formats FAQ, now maintained by Chris Bagwell, who also
took over sox...)

Downside: test_linuxaudiodev will now be skipped if you don't have the
audioop enabled in your Setup file.  But that's fixed easily.

By the way -- the checkin freeze for the release candidate should go
in just about now...

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


From tim_one@email.msn.com  Sun Oct  8 11:32:36 2000
From: tim_one@email.msn.com (Tim Peters)
Date: Sun, 8 Oct 2000 06:32:36 -0400
Subject: [Python-Dev] A standard lexer?
In-Reply-To: <00f201bfe475$d5e00c40$f2a6b5d4@hagrid>
Message-ID: <LNBBLJKPBEHFEDALKOLCAEDGHKAA.tim_one@email.msn.com>

Blast from the past!

[/F]
>         for phrase, action in lexicon:
>             p.append("(?:%s)(?P#%d)" % (phrase, len(p)))

[Tim]
> How about instead enhancing existing (?P<name>pattern) notation, to
> set a new match object attribute to name if & when pattern matches?
> Then arbitrary info associated with a named pattern can be gotten at
> via dicts via the pattern name, & the whole mess should be more
> readable.

[/F
 Sent: Sunday, July 02, 2000 6:35 PM]
> I just added "lastindex" and "lastgroup" attributes to the match object.
>
> "lastindex" is the integer index of the last matched capturing group,
> "lastgroup" the corresponding name (or None, if the group didn't have
> a name).  both attributes are None if no group were matched.

Reviewing this before 2.0 has been on my todo list for 3+ months, and
finally got to it.  Good show!  I converted some of my by-hand scanners to
use lastgroup, and like it a whole lot.  I know you understand why this is
Good, so here's a simple example of an "after" tokenizer for those who don't
(this one happens to tokenize REXX-like PARSE stmts):

import re
_token = re.compile(r"""
        (?P<space> \s+)
    |   (?P<var> [a-zA-Z_]\w*)
    |   (?P<dontcare> \.)
    |   (?P<number> \d+)
    |   (?P<punc> [-+=()])
    |   (?P<string> " [^"\\\n]* (?: \\. [^"\\\n]*)* "
        |           ' [^'\\\n]* (?: \\. [^'\\\n]*)* '
        )
""", re.VERBOSE).match
del re

(T_SPACE,
 T_VAR,
 T_DONTCARE,
 T_NUMBER,
 T_PUNC,
 T_STRING,
 T_EOF,
)           = range(7)

# For debug output.
_enum2name = ["T_SPACE",
              "T_VAR",
              "T_DONTCARE",
              "T_NUMBER",
              "T_PUNC",
              "T_STRING",
              "T_EOF",
             ]

_group2action = {
    "space":    (T_SPACE, None),
    "var":      (T_VAR, None),
    "dontcare": (T_DONTCARE, None),
    "number":   (T_NUMBER, int),
    "punc":     (T_PUNC, None),
    "string":   (T_STRING, eval),
}

def tokenize(s, tokeneater):
    i, n = 0, len(s)
    while i < n:
        m = _token(s, i)
        if not m:
            raise ParseError(s, i)
        group = m.lastgroup
        enum, action = _group2action[group]
        val = m.group(group)
        if action is not None:
            val = action(val)
        tokeneater(enum, val)
        i = m.end()
    tokeneater(T_EOF, None)

The tokenize function here used to be a mass of if/elif stmts trying to
figure out which group had matched.  Now it's all table-driven:  easier to
write, reuse & maintain, and quicker to boot.  +1.

the-aged-may-be-slow-but-they-never-forget<wink>-ly y'rs  - tim




From Fredrik Lundh" <effbot@telia.com  Sun Oct  8 12:04:50 2000
From: Fredrik Lundh" <effbot@telia.com (Fredrik Lundh)
Date: Sun, 8 Oct 2000 13:04:50 +0200
Subject: [Python-Dev] Tcl and Unicode
References: <LNBBLJKPBEHFEDALKOLCMECEHKAA.tim_one@email.msn.com>
Message-ID: <016b01c03117$a3cb6a80$766940d5@hagrid>

guido:
> > This *should* be correct because Tcl/Tk always uses UTF-8 internally.
> > (Even though it is "lenient" when receiving strings -- if a sequence
> > of characters has no valid Unicode representation, it appears to falls
> > back to Latin-1; I don't know the details of this algorithm.)

Tcl/Tk uses a 16-bit (UCS-2) unicode string type internally, but
their 8-bit strings use UTF-8.

When converting from external 8-bit strings to unicode, they
convert valid UTF-8 sequences to unicode characters just like
Python, but "a lead-byte not followed by enough trail-bytes
represents itself." (in other words, it's cast from an unsigned
char to an unsigned short).

And the chance that any reasonable Latin-1 string would contain
a UTF-8 lead bytes followed by the right number of UTF-8 trail
bytes is close to zero...

(in case anyone wonders, Python's codec thinks that "close
to zero" isn't good enough, so it raises an exception instead)

tim:
> Dunno, but wouldn't be surprised if they had a notion of default encoding,
> and that it simply appears to be Latin-1 to us because American Windows uses
> a superset of Latin-1.

They have a system encoding, but it's not used here -- it's just
that Latin-1 is a subset of Unicode...

</F>



From thomas@xs4all.net  Sun Oct  8 12:14:33 2000
From: thomas@xs4all.net (Thomas Wouters)
Date: Sun, 8 Oct 2000 13:14:33 +0200
Subject: [Python-Dev] Release candidate
Message-ID: <20001008131433.M12812@xs4all.nl>

Is there any chance we can get the 'release candidate' released on the SF
File Module thingy as well ? Mailman uses this for the betas, for instance,
and I think it would attract that bit more attention to it. I believe the
'release' gets listed on various SF pages that way.

-- 
Thomas Wouters <thomas@xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!


From barry@scottb.demon.co.uk  Sun Oct  8 15:36:45 2000
From: barry@scottb.demon.co.uk (Barry Scott)
Date: Sun, 8 Oct 2000 15:36:45 +0100
Subject: [Python-Dev] Python 2.0b2 note for Windows developers
In-Reply-To: <LNBBLJKPBEHFEDALKOLCCEILHIAA.tim_one@email.msn.com>
Message-ID: <000401c03135$2ebd4ec0$060210ac@private>

Tim,
	Two requests:

1. Can you ship the .PDB files for the debug images so devo's
   do not need to build the python sources to debug extensions.
   And Yes I know the .ZIP will be huge. If you want a
   compromise only include the .PDB for python20_d.dll.

2. Place the files into libs, pyd etc dirs. I had to extract
   the groups into the right places which is a bit tedious
   and error prone.

		BArry

> -----Original Message-----
> From: python-dev-admin@python.org [mailto:python-dev-admin@python.org]On
> Behalf Of Tim Peters
> Sent: 27 September 2000 23:40
> To: PythonDev; Python list
> Subject: [Python-Dev] Python 2.0b2 note for Windows developers
> 
> 
> Since most Python users on Windows don't have any use for them, I trimmed
> the Python 2.0b2 installer by leaving out the debug-build .lib, .pyd, .exe
> and .dll files.  If you want them, they're available in a separate zip
> archive; read the Windows Users notes at
> 
> http://www.pythonlabs.com/products/python2.0/download_python2.0b2.html
> 
> for info and a download link.  If you don't already know *why* you might
> want them, trust me:  you don't want them <wink>.
> 
> they-don't-even-make-good-paperweights-ly y'rs  - tim
> 
> 
> 
> _______________________________________________
> Python-Dev mailing list
> Python-Dev@python.org
> http://www.python.org/mailman/listinfo/python-dev
> 


From ping@lfw.org  Sun Oct  8 19:19:51 2000
From: ping@lfw.org (Ka-Ping Yee)
Date: Sun, 8 Oct 2000 11:19:51 -0700 (PDT)
Subject: [Python-Dev] linuxaudiodev module
In-Reply-To: <14814.21033.195290.728159@bitdiddle.concentric.net>
Message-ID: <Pine.LNX.4.10.10010081109230.454-100000@skuld.kingmanhall.org>

On Fri, 6 Oct 2000, Jeremy Hylton wrote:
> 
> Have you tried the new code, BTW?  Does the test work on your machine?

Works okay (i updated after Guido's last edit).  Sounds fine to me.

But it bugs me that some of the descriptions say "audio" and others say
"format".  This seems arbitrary -- is there a reason?

Excerpt of Modules/linuxaudiodev.c:
    {  8, »­­­­­AFMT_MU_LAW, "Logarithmic mu-law audio" },
    {  8, »­­­­­AFMT_A_LAW,  "Logarithmic A-law audio" },
    {  8,»­­­­­­AFMT_U8,     "Standard unsigned 8-bit audio" },
    {  8, »­­­­­AFMT_S8,     "Standard signed 8-bit audio" },
    { 16, »­­­­­AFMT_U16_BE, "Big-endian 16-bit unsigned format" },
    { 16, »­­­­­AFMT_U16_LE, "Little-endian 16-bit unsigned format" },
    { 16, »­­­­­AFMT_S16_BE, "Big-endian 16-bit signed format" },
    { 16, »­­­­­AFMT_S16_LE, "Little-endian 16-bit signed format" },

If you don't mind, i'd prefer something like:
    {  8, »­­­­­AFMT_MU_LAW, "logarithmic mu-law 8-bit audio" },
    {  8, »­­­­­AFMT_A_LAW,  "logarithmic A-law 8-bit audio" },
    {  8,»­­­­­­AFMT_U8,     "linear unsigned 8-bit audio" },
    {  8, »­­­­­AFMT_S8,     "linear signed 8-bit audio" },
    { 16, »­­­­­AFMT_U16_BE, "linear unsigned 16-bit big-endian audio" },
    { 16, »­­­­­AFMT_U16_LE, "linear unsigned 16-bit little-endian audio" },
    { 16, »­­­­­AFMT_S16_BE, "linear signed 16-bit big-endian audio" },
    { 16, »­­­­­AFMT_S16_LE, "linear signed 16-bit little-endian audio" },

The above conforms to:

    <format> <width> "audio"

    where <format> ::= "logarithmic" ("mu-law" | "A-law") |
                       "linear" ("unsigned" | "signed")

          <width> ::= "8-bit" | "16-bit" ("big-endian" | "little-endian")


-- ?!ng

"Simple, yet complex."
    -- Lenore Snell



From tim_one@email.msn.com  Sun Oct  8 20:28:55 2000
From: tim_one@email.msn.com (Tim Peters)
Date: Sun, 8 Oct 2000 15:28:55 -0400
Subject: [Python-Dev] Python 2.0b2 note for Windows developers
In-Reply-To: <000401c03135$2ebd4ec0$060210ac@private>
Message-ID: <LNBBLJKPBEHFEDALKOLCGEEEHKAA.tim_one@email.msn.com>

[Barry]
> 	Two requests:
>
> 1. Can you ship the .PDB files for the debug images so devo's
>    do not need to build the python sources to debug extensions.
>    And Yes I know the .ZIP will be huge. If you want a
>    compromise only include the .PDB for python20_d.dll.

Sure!  Most .pdb files are highly compressible, and the zip size hit isn't
anything to worry about.

> 2. Place the files into libs, pyd etc dirs. I had to extract
>    the groups into the right places which is a bit tedious
>    and error prone.

No.  If you want a directory structure that doesn't match the actual build
directory structure, I can't read your mind, and have no reason to believe
that the specific artificial structure you have in mind is of use to anyone
but you.  Don't be so helpless <wink>:  write a tiny Python script to move
the files where you want them after unpacking.  What I upload will be an
exact image of the build directory structure.  Most feedback I've gotten is
that people want exactly that, because they *want* to compile Python
themselves and just want to avoid jumping thru all the snaky hoops needed to
compile the 3rd-party subprojects (from _tkinter to zlib).

alphabetically y'rs  - tim




From guido@python.org  Sun Oct  8 21:52:54 2000
From: guido@python.org (Guido van Rossum)
Date: Sun, 08 Oct 2000 15:52:54 -0500
Subject: [Python-Dev] linuxaudiodev module
In-Reply-To: Your message of "Sun, 08 Oct 2000 11:19:51 MST."
 <Pine.LNX.4.10.10010081109230.454-100000@skuld.kingmanhall.org>
References: <Pine.LNX.4.10.10010081109230.454-100000@skuld.kingmanhall.org>
Message-ID: <200010082052.PAA27119@cj20424-a.reston1.va.home.com>

> But it bugs me that some of the descriptions say "audio" and others say
> "format".  This seems arbitrary -- is there a reason?

Okay, you're right.  (But there are sooooo many other things wrong
with the code still...  E.g. the bogus reference to "ctl". :-( )

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


From paul@prescod.net  Mon Oct  9 07:04:55 2000
From: paul@prescod.net (Paul Prescod)
Date: Sun, 08 Oct 2000 23:04:55 -0700
Subject: [Python-Dev] A standard lexer?
References: <LNBBLJKPBEHFEDALKOLCAEDGHKAA.tim_one@email.msn.com>
Message-ID: <39E16007.5F1DDF9A@prescod.net>

Tim Peters wrote:
> 
> ...
> 
> Reviewing this before 2.0 has been on my todo list for 3+ months, and
> finally got to it.  Good show!  I converted some of my by-hand scanners to
> use lastgroup, and like it a whole lot.  I know you understand why this is
> Good, so here's a simple example of an "after" tokenizer for those who don't
> (this one happens to tokenize REXX-like PARSE stmts):

Is there a standard technique for taking a regexp like this and applying
it to data fed in a little at a time? Other than buffering the data
forever? That's something else I would like in a "standard Python
lexer", if that's the goal.

-- 
 Paul Prescod - Not encumbered by corporate consensus
Simplicity does not precede complexity, but follows it. 
	- http://www.cs.yale.edu/homes/perlis-alan/quotes.html


From guido@beopen.com  Thu Oct  5 14:16:14 2000
From: guido@beopen.com (Guido van Rossum)
Date: Thu, 5 Oct 2000 09:16:14 -0400
Subject: [Python-Dev] htmllib.HTMLescape()
References: <200010042031.WAA17378@pandora.informatik.hu-berlin.de>
Message-ID: <000701c031f4$59507440$7aa41718@reston1.va.home.com>

Note that cgi.escape() does this too.

--Guido

----- Original Message ----- 
From: "Martin von Loewis" <loewis@informatik.hu-berlin.de>
To: <aahz@panix.com>
Cc: <python-dev@python.org>
Sent: Wednesday, October 04, 2000 4:31 PM
Subject: [Python-Dev] htmllib.HTMLescape()


> > Someone just pointed out on c.l.py that we need an HTMLescape()
> > function that takes a string and converts special characters to
> > entities.  I'm not on python-dev, so could you please forward this
> > and find out whether I need to run a PEP?
> 
> Doesn't xml.sax.saxutils.escape do what you want (together with
> htmlentitydefs)? I was going to say that this is quite a small change
> to warrant a PEP - but there are two obvious approaches (working from
> scratch, or working on top of xml.sax.saxutils.escape - perhaps
> modifying and relocating that function), so *some* design probably
> needs to be recorded in a PEP.
> 
> Regards,
> Martin
> 
> _______________________________________________
> Python-Dev mailing list
> Python-Dev@python.org
> http://www.python.org/mailman/listinfo/python-dev
> 



From loewis@informatik.hu-berlin.de  Mon Oct  9 15:01:10 2000
From: loewis@informatik.hu-berlin.de (Martin von Loewis)
Date: Mon, 9 Oct 2000 16:01:10 +0200 (MET DST)
Subject: [Python-Dev] htmllib.HTMLescape()
In-Reply-To: <000701c031f4$59507440$7aa41718@reston1.va.home.com>
 (guido@beopen.com)
References: <200010042031.WAA17378@pandora.informatik.hu-berlin.de> <000701c031f4$59507440$7aa41718@reston1.va.home.com>
Message-ID: <200010091401.QAA21515@pandora.informatik.hu-berlin.de>

> Note that cgi.escape() does this too.

Indeed. That justifies a PEP that proposes to concentrate the
functionality in one place, deprecating the other places.

One approach would be to enhance the codec facilites, so that
"string".encode("iso-entities") becomes possible - but that is already
in the middle of discussing the PEP.

Regards,
Martin


From jeremy@beopen.com  Mon Oct  9 15:35:48 2000
From: jeremy@beopen.com (Jeremy Hylton)
Date: Mon, 9 Oct 2000 10:35:48 -0400 (EDT)
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules zlibmodule.c,2.35,2.36
In-Reply-To: <200010091418.HAA08765@slayer.i.sourceforge.net>
References: <200010091418.HAA08765@slayer.i.sourceforge.net>
Message-ID: <14817.55236.288126.338665@bitdiddle.concentric.net>

Thanks.  I didn't get to it on Friday.

Jeremy


From trentm@ActiveState.com  Mon Oct  9 23:56:00 2000
From: trentm@ActiveState.com (Trent Mick)
Date: Mon, 9 Oct 2000 15:56:00 -0700
Subject: [Python-Dev] test_sre.py fails on Win64 because PyOS_CheckStack *never* fails
In-Reply-To: <000b01c02e4c$2ac63980$766940d5@hagrid>; from effbot@telia.com on Wed, Oct 04, 2000 at 11:43:41PM +0200
References: <20001004141737.A16659@ActiveState.com> <000b01c02e4c$2ac63980$766940d5@hagrid>
Message-ID: <20001009155600.A27929@ActiveState.com>

[Trent notes that PyOS_CheckStack never fails on Win64 hence test_[s]re.py
    fail on the overflow checks]

[Fredrik gives me a simple test C program to test PyOS_CHeckStack
    independently (The test program is included at the bottom of this
    email.)]

SOrry I took so long to reply to this but I spent a little bit of time
playing with PyOS_CheckStack on Win32 and Win64 and I am now just frustrated.
Here is what I found:

- The simple test program shows that PyOS_CheckStack will fire as intended
  on both Win32 and Win64 with either Visual C's default optimization OR no
  optimization.
- The simple test program will *not* fire as intended with the '-O2'
  optimization which Python *does* use for pythonrun.c (where
  PyOS_CheckStack lives). So, likely the '-O2' optimization will
  optimize-away the _alloca() call. Fine. But why then does it *not* get
  optimized away when pythonrun.c is compiled? Does the context around other
  code in the same file affect that optimization?
- When I apply this patch to _sre.c on *Win32* (basically the same test as
  the test file that Fredrik gave me to try) the "callme(0)" call *never*
  returns -- infinite loop. Note that this happens on the Release *and* Debug
  builds so nothing is being optimized away.

***************
*** 560,565 ****
--- 560,569 ----
  }
  #endif

+
+
+ void callme(int i);
+
  LOCAL(int)
  SRE_MATCH(SRE_STATE* state, SRE_CODE* pattern, int level)
  {
***************
*** 578,583 ****
--- 582,588 ----
      TRACE(("|%p|%p|ENTER %d\n", pattern, ptr, level));

  #if defined(USE_STACKCHECK)
+     callme(0);
      if (level % 10 == 0 && PyOS_CheckStack())
          return SRE_ERROR_RECURSION_LIMIT;
  #endif
***************
*** 2337,2340 ****
--- 2342,2357 ----
      Py_InitModule("_" MODULE, _functions);
  }

+ void callme(int i)
+ {
+     char buf[100000];
+     if (PyOS_CheckStack())
+         return;
+     printf("%d\n", i);
+     memset(buf, 0, sizeof buf);
+     callme(i+1);
+ }
+
+
+
  #endif /* !defined(SRE_RECURSIVE) */

- I am not smart enough and/or (you decide :) do not have the inclination to
  figure this out (i.e. start looking at assembly code) just so _sre can use
  stack checking instead of the existing RECURSION_LIMIT framework (albeit
  the limited general usefullness of this) on Win64 so that test_sre.py can
  pass.

  Would it be alright for me to apply:


*** python/dist/src/Include/pythonrun.h       Sat Sep 16 09:31:31 2000
--- python/dist/src/Include/pythonrun.h  Sun Oct  8 10:20:02 2000
***************
*** 88,94 ****
     to a 8k margin. */
  #define PYOS_STACK_MARGIN 2048

! #if defined(WIN32) && defined(_MSC_VER)
  /* Enable stack checking under Microsoft C */
  #define USE_STACKCHECK
  #endif
--- 88,94 ----
     to a 8k margin. */
  #define PYOS_STACK_MARGIN 2048

! #if defined(WIN32) && !defined(MS_WIN64) && defined(_MSC_VER)
  /* Enable stack checking under Microsoft C */
  #define USE_STACKCHECK
  #endif


  to disable stack checking on Win64 until Win64 become more mainstream and
  others can bang away at this? The important thing, I would think, is
  getting the test suite passing for Python 2.0.


------- test file mentioned above --------------------------------
#include <malloc.h>
#include <excpt.h>

int __inline
PyOS_CheckStack()
{
    __try {
        _alloca(100000);
        return 0;
    } __except (EXCEPTION_EXECUTE_HANDLER) {
        /* just ignore all errors */
    }
    return 1;
}

void
callme(int i)
{
    char buf[100000];
    if (PyOS_CheckStack())
        return;
    printf("%d\n", i);
    memset(buf, 0, sizeof buf);
    callme(i+1);
}

int
main()
{
    callme(0);
}
-----------------------------------------------------


-- 
Trent Mick
TrentM@ActiveState.com


From jeremy@beopen.com  Tue Oct 10 01:26:27 2000
From: jeremy@beopen.com (Jeremy Hylton)
Date: Mon, 9 Oct 2000 20:26:27 -0400 (EDT)
Subject: [Python-Dev] Pre-release copies of the 2.0c1 source tarball
Message-ID: <14818.25139.747635.586267@bitdiddle.concentric.net>

I have placed pre-release copies of the 2.0 release candidate 1 source
tarballs at ftp://python.beopen.com/pub/python/2.0c1/.  We reserve the
right two change these without notice prior to the official release
:-).

Jeremy


From nas@arctrix.com  Mon Oct  9 20:06:08 2000
From: nas@arctrix.com (Neil Schemenauer)
Date: Mon, 9 Oct 2000 12:06:08 -0700
Subject: [Python-Dev] test_import failing
Message-ID: <20001009120608.A13588@glacier.fnational.com>

I assume the CVS sources are basicly the same as 2.0c1.  Anyhow,
test_import is failing on my Debian machine.  The script is
creating "@test.py" and then trying to import it.  "." is not in
sys.path for some reason.

  Neil


From jeremy@beopen.com  Tue Oct 10 03:17:31 2000
From: jeremy@beopen.com (Jeremy Hylton)
Date: Mon, 9 Oct 2000 22:17:31 -0400 (EDT)
Subject: [Python-Dev] Re: test_import failing
In-Reply-To: <20001009120608.A13588@glacier.fnational.com>
References: <20001009120608.A13588@glacier.fnational.com>
Message-ID: <14818.31803.227516.852814@bitdiddle.concentric.net>

I assume that you are running the test some way other than using 
"make test."  It seems that make test executes python this way --
PYTHONPATH= ./python
-- which causes the current directory to be added to the path.
If you run python without having the current directory on your path
test_import file fail.

Unless you are having a different problem, this isn't important enough
to fix in 2.0c1, although it seems good to fix for 2.0 final.

Jeremy

PS We have left GC turned on by default in 2.0c1 and plan to do the
same for 2.0 final.



From fdrake@beopen.com  Tue Oct 10 03:09:34 2000
From: fdrake@beopen.com (Fred L. Drake, Jr.)
Date: Mon, 9 Oct 2000 22:09:34 -0400 (EDT)
Subject: [Python-Dev] test_import failing
In-Reply-To: <20001009120608.A13588@glacier.fnational.com>
References: <20001009120608.A13588@glacier.fnational.com>
Message-ID: <14818.31326.292172.223405@cj42289-a.reston1.va.home.com>

Neil Schemenauer writes:
 > I assume the CVS sources are basicly the same as 2.0c1.  Anyhow,
 > test_import is failing on my Debian machine.  The script is
 > creating "@test.py" and then trying to import it.  "." is not in
 > sys.path for some reason.

  Jeremy & I finally figured this out.  "make test" runs python with
PYTHONPATH set to '' (an empty string).  This is decidedly different
from running with PYTHONPATH unset (I consider this a bug that should
be fixed in 2.1).
  The empty string is interpreted as the current directory (as
expected), so running "make test" adds the current directory to
sys.path, but running the regression test (test_import or regrtest) as
a script does not.
  We decided not to fix this now, since it's too late to be sure it's
the right change, and adjusting the test case also means a very late
change.  So whoever runs the tests is responsible for making sure the
current directory is on sys.path.  (*Really* bogus!)


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member



From fdrake@beopen.com  Tue Oct 10 03:20:11 2000
From: fdrake@beopen.com (Fred L. Drake, Jr.)
Date: Mon, 9 Oct 2000 22:20:11 -0400 (EDT)
Subject: [Python-Dev] Re: test_import failing
In-Reply-To: <14818.31803.227516.852814@bitdiddle.concentric.net>
References: <20001009120608.A13588@glacier.fnational.com>
 <14818.31803.227516.852814@bitdiddle.concentric.net>
Message-ID: <14818.31963.385267.336885@cj42289-a.reston1.va.home.com>

Jeremy Hylton writes:
 > Unless you are having a different problem, this isn't important enough
 > to fix in 2.0c1, although it seems good to fix for 2.0 final.

  And it's questionable how many bugs are hiding here as well.  I
count two:

  - test_import.py assumes the current directory is on the path; this
    is just plain fragile, and should explicitly pick the directory
    off of test_support.TESTFN, and add it to sys.path for the
    duration of the test (which does indeed fix this bug)

  - Modules/getpath.c interprets an empty definition of $PYTHONPATH as
    adding '' to sys.path, where I assert it should not add anything
    to sys.path.  Everywhere else I've recall seeing an environment
    variable used as a data source, the test is done like this:

    char *cp = getenv("VARIABLE");
    if (cp != NULL && cp[0] != '\0') {
        ...
    }

    (with some spelling variations).


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member



From Jeremy Hylton <jeremy@beopen.com>  Tue Oct 10 07:52:48 2000
From: Jeremy Hylton <jeremy@beopen.com> (Jeremy Hylton)
Date: Mon, 9 Oct 2000 23:52:48 -0700 (PDT)
Subject: [Python-Dev] Python 2.0 release candidate 1
Message-ID: <200010100652.XAA74600@python.beopen.com>

Python 2.0c1 is released.  The BeOpen PythonLabs and our cast of
SourceForge volunteers have fixed many bugs since the beta releases
last month.  Please pick up the new release at

    http://www.pythonlabs.com/products/python2.0/

There's a tarball, a Windows installer, RedHat RPMs, online
documentation, and a long list of fixed bugs.

The final release of Python 2.0 will be next week.  We would
appreciate feedback on the release candidate in order to fix any
remaining bugs before the final release.  Confirmation of build and
test success on less common platforms is also helpful.n

All major reported bugs have been fixed in the release candidate.  We
do not plan to make any changes between now and the final release,
except to fix bugs reported in the next week.  We encourage potential
users of Python 2.0 to try the release candidate with their programs
and report any remaining bugs.

To report a new bug, use the SourceForge bug tracker
http://sourceforge.net/bugs/?func=addbug&group_id=5470

Python 2.0 has many new features, including the following:

  - Augmented assignment, e.g. x += 1
  - List comprehensions, e.g. [x**2 for x in range(10)]
  - Extended import statement, e.g. import Module as Name
  - Extended print statement, e.g. print >> file, "Hello"
  - Collection of cyclical garbage

For a fuller discussion of the changes in Python 2.0, please see the
article "What's New in Python 2.0" by Andrew Kuchling and Moshe Zadke:
http://starship.python.net/crew/amk/python/writing/new-python/

-- Jeremy Hylton <http://www.python.org/~jeremy/>



From tismer@appliedbiometrics.com  Tue Oct 10 11:33:36 2000
From: tismer@appliedbiometrics.com (Christian Tismer)
Date: Tue, 10 Oct 2000 13:33:36 +0300
Subject: [Python-Dev] Stackless Python 1.2 + Continuations 0.9
Message-ID: <39E2F080.86ED1DA3@appliedbiometrics.com>

ANNOUNCING:

               Stackless Python 1.2
           A Python Implementation That
             Does Not Use The C Stack

               * plus the real toy *

              Continuation Module 0.9
        Continuations as First Class Objects
            with support for MicroThreads

What is it?
A plugin-replacement for core Python.
It should run any program which runs under Python 1.5.2 .
But it does not need space on the C stack.

For further info, see the new site at 
   
              http://www.stackless.com

You might also want to join the mailing list at

     http://starship.python.net/mailman/listinfo/stackless

Major changes in this release:
Extra reference counting reduces continuation frame creation
Better exception handling avoids cycles.

Next to come:
- A port to Python 2.0 will be the first thing to do.
- Long-term project is a complete redesign and
  rewrite for inclusion with Python 2.1

ciao - Christian Tismer / Mission Impossible 5oftware Team

<P><A HREF="http://www.tismer.com/research/stackless/">Stackless
Python 1.2 + Continuations 0.9</A> - a version of Python 1.5.2 that
does not need space on the C stack, first-class callable
continuation objects for Python, and Microthread-support. 
(10-Oct-2000)
</P>

-- 
http://www.python.org/mailman/listinfo/python-list


From guido@python.org  Tue Oct 10 14:04:39 2000
From: guido@python.org (Guido van Rossum)
Date: Tue, 10 Oct 2000 08:04:39 -0500
Subject: [Python-Dev] test_import failing
In-Reply-To: Your message of "Mon, 09 Oct 2000 22:09:34 -0400."
 <14818.31326.292172.223405@cj42289-a.reston1.va.home.com>
References: <20001009120608.A13588@glacier.fnational.com>
 <14818.31326.292172.223405@cj42289-a.reston1.va.home.com>
Message-ID: <200010101304.IAA13010@cj20424-a.reston1.va.home.com>

> Neil Schemenauer writes:
>  > I assume the CVS sources are basicly the same as 2.0c1.  Anyhow,
>  > test_import is failing on my Debian machine.  The script is
>  > creating "@test.py" and then trying to import it.  "." is not in
>  > sys.path for some reason.
> 
>   Jeremy & I finally figured this out.  "make test" runs python with
> PYTHONPATH set to '' (an empty string).  This is decidedly different
> from running with PYTHONPATH unset (I consider this a bug that should
> be fixed in 2.1).
>   The empty string is interpreted as the current directory (as
> expected), so running "make test" adds the current directory to
> sys.path, but running the regression test (test_import or regrtest) as
> a script does not.
>   We decided not to fix this now, since it's too late to be sure it's
> the right change, and adjusting the test case also means a very late
> change.  So whoever runs the tests is responsible for making sure the
> current directory is on sys.path.  (*Really* bogus!)

Proper fix, which I will check in momentarily: put

    import sys
    sys.path.insert(0, os.curdir)

in front of test_import.py; and add

    del sys.path[0]

to the end.

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


From guido@python.org  Tue Oct 10 14:06:54 2000
From: guido@python.org (Guido van Rossum)
Date: Tue, 10 Oct 2000 08:06:54 -0500
Subject: [Python-Dev] Re: test_import failing
In-Reply-To: Your message of "Mon, 09 Oct 2000 22:20:11 -0400."
 <14818.31963.385267.336885@cj42289-a.reston1.va.home.com>
References: <20001009120608.A13588@glacier.fnational.com> <14818.31803.227516.852814@bitdiddle.concentric.net>
 <14818.31963.385267.336885@cj42289-a.reston1.va.home.com>
Message-ID: <200010101306.IAA13031@cj20424-a.reston1.va.home.com>

>   And it's questionable how many bugs are hiding here as well.  I
> count two:
> 
>   - test_import.py assumes the current directory is on the path; this
>     is just plain fragile, and should explicitly pick the directory
>     off of test_support.TESTFN, and add it to sys.path for the
>     duration of the test (which does indeed fix this bug)

I'll fix this.

>   - Modules/getpath.c interprets an empty definition of $PYTHONPATH as
>     adding '' to sys.path, where I assert it should not add anything
>     to sys.path.  Everywhere else I've recall seeing an environment
>     variable used as a data source, the test is done like this:
> 
>     char *cp = getenv("VARIABLE");
>     if (cp != NULL && cp[0] != '\0') {
>         ...
>     }
> 
>     (with some spelling variations).

Agreed, but please *don't fix this in 2.0!*

Who knows how many other hidden bugs (in 3rd party code) this will
trigger...

OK to fix it after 2.0final is released.

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


From mal@lemburg.com  Tue Oct 10 13:58:09 2000
From: mal@lemburg.com (M.-A. Lemburg)
Date: Tue, 10 Oct 2000 14:58:09 +0200
Subject: [Python-Dev] LICENSE file in Python 2.0c1
Message-ID: <39E31261.166F1601@lemburg.com>

I've just had a glance at the releas candidate 1. The file LICENSE
has grown somewhat, but not as much as I feared... looking
at the contents I find the following as only reference to the
CNRI license (which holds all the surprises we talked about in
the early beta stages):

"""
CNRI OPEN SOURCE LICENSE AGREEMENT
----------------------------------

Python 1.6 is made available subject to the terms and conditions in
CNRI's License Agreement.  This Agreement together with Python 1.6 may
be located on the Internet using the following unique, persistent
identifier (known as a handle): 1895.22/1012.  This Agreement may also
be obtained from a proxy server on the Internet using the following
URL: http://hdl.handle.net/1895.22/1012.
"""

Such a note is nice and short, but not legally binding and 
confusing since it is not clear whether the "handle" for the
document will always return the same license text or if it
will return a license text at all.

It would be more appropriate to include the original CNRI license
text, IMHO. Or is there some hidden motivation behind using the
handle ?

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/


From thomas.heller@ion-tof.com  Tue Oct 10 14:06:05 2000
From: thomas.heller@ion-tof.com (Thomas Heller)
Date: Tue, 10 Oct 2000 15:06:05 +0200
Subject: [Python-Dev] distutils and bdist_wininst confusion: clarification
Message-ID: <01be01c032ba$dc889ba0$4500a8c0@thomasnotebook>

There has been some confusion about distutils, especially the
bdist_wininst command.
I hope I can clarify these things with this post.

1. The current Distutils version 1.0, which is also
   included in the Python 2.0 release candidate is perfectly
   usable apart from one bug:
   You should create windows installers (by running
   'setup.py bdist_wininst' or 'setup.py bdist --formats=wininst')
   ONLY with an external zip utility (info-zip would do).
   Using the zipfile module results in corrupted installations
   (all files are created with zero length).
   Details about the cause for this can be found in the patch
   I posted to SF.


2. I submitted a patch to SF
   http://sourceforge.net/patch/?func=detailpatch&patch_id=101844&group_id=5470
   which corrects this bug.
   Normally I would have checked this code in immediately,
   because it is in _my_ code, and that's what my checkin rights
   are for ;-).
   I did not because I did not want to interfere with the release process of
   python 2.0 rc 1.


3. How does bdist_wininst work?
   bdist_wininst creates a self-extracting zipfile from two
   components: a stub program (wininst.exe) plus a zip-file
   containing the code to be distributed. Because I did not
   liked wininst.exe as binary file checked in into CVS,
   the actual bytes of this exe are included base64-encoded
   in the bdist_wininst.py module as string. I'm not sure
   whether this is a wise design or not, but that is a different
   topic.
   The downside of this design is that when the source to 
   wininst.exe changes, it must be recompiled, and bdist_wininst.py
   must be regenerated. The context-diffs for bdist_wininst.py
   are so very large.


4. To understand the patch, you should know the following:
   Distutils is a separate toplevel module in the repository
   on sourceforge. Parts of this repository are symbolically
   linked somewhere into the python tree. Thus, this patch must
   be applied to the distutils _module_ in the repository.

   Distutils directory structure is as follows:

   distutils
     dd
     distutils
       command
     doc
       dist
       inst
     examples
       sample1
       sample2
       sample3
     misc
     test
     text

   Relevant part of python directory structure:

   python
     dist
       src
         Lib
           distutils
             command

   The source code for wininst.exe is in CVS in the distutils/misc
   directory.
   The patch I posted to SF does not include the compiled
   wininst.exe, neither does it include the (regenerated)
   bdist_wininst.py module.

5. If nobody objects, I will check in the changes I made tomorrow, recompile
   the exe, regenerate the bdist_wininst.py, and everything should be
   fine again.
   Greg will then hopefully, when he is back, increase the distutils version
   number to 1.0.1 (or whatever) and this version will then be delivered with
   python 2.0 final.

Sorry for the confusion.

Cheers,

Thomas





From guido@python.org  Tue Oct 10 15:36:57 2000
From: guido@python.org (Guido van Rossum)
Date: Tue, 10 Oct 2000 09:36:57 -0500
Subject: [Python-Dev] LICENSE file in Python 2.0c1
In-Reply-To: Your message of "Tue, 10 Oct 2000 14:58:09 +0200."
 <39E31261.166F1601@lemburg.com>
References: <39E31261.166F1601@lemburg.com>
Message-ID: <200010101436.JAA13237@cj20424-a.reston1.va.home.com>

> I've just had a glance at the releas candidate 1. The file LICENSE
> has grown somewhat, but not as much as I feared...

Since when?  It hasn't changed since it was first released, for 2.0b1.

> looking
> at the contents I find the following as only reference to the
> CNRI license (which holds all the surprises we talked about in
> the early beta stages):
> 
> """
> CNRI OPEN SOURCE LICENSE AGREEMENT
> ----------------------------------
> 
> Python 1.6 is made available subject to the terms and conditions in
> CNRI's License Agreement.  This Agreement together with Python 1.6 may
> be located on the Internet using the following unique, persistent
> identifier (known as a handle): 1895.22/1012.  This Agreement may also
> be obtained from a proxy server on the Internet using the following
> URL: http://hdl.handle.net/1895.22/1012.
> """
> 
> Such a note is nice and short, but not legally binding and 
> confusing since it is not clear whether the "handle" for the
> document will always return the same license text or if it
> will return a license text at all.

Why do you say it's not legally binding?  The CNRI license explicitly
allows you to use this exact text instead of including the whole CNRI
license.

> It would be more appropriate to include the original CNRI license
> text, IMHO. Or is there some hidden motivation behind using the
> handle ?

I was just trying to save space.  ActivePython does the same thing as
far as I remember.

BTW, I haven't heard from CNRI in two weeks, but the last thing I
heard from them was that their lawyers had talked to Stallman's lawyer
and that they were optimistic about a successful resolution.

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


From guido@python.org  Tue Oct 10 15:41:50 2000
From: guido@python.org (Guido van Rossum)
Date: Tue, 10 Oct 2000 09:41:50 -0500
Subject: [Python-Dev] distutils and bdist_wininst confusion: clarification
In-Reply-To: Your message of "Tue, 10 Oct 2000 15:06:05 +0200."
 <01be01c032ba$dc889ba0$4500a8c0@thomasnotebook>
References: <01be01c032ba$dc889ba0$4500a8c0@thomasnotebook>
Message-ID: <200010101441.JAA13276@cj20424-a.reston1.va.home.com>

Thomas, thanks for the explanation.  I agree that you can check in the
changes yourself as you proposed.

There's one issue I still don't understand (not having the time to
read the full distutils docs): how does a typical Windows developer
decide whether to use an external zip utility or the zipfile module?

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


From thomas.heller@ion-tof.com  Tue Oct 10 14:58:32 2000
From: thomas.heller@ion-tof.com (Thomas Heller)
Date: Tue, 10 Oct 2000 15:58:32 +0200
Subject: [Python-Dev] distutils and bdist_wininst confusion: clarification
References: <01be01c032ba$dc889ba0$4500a8c0@thomasnotebook>  <200010101441.JAA13276@cj20424-a.reston1.va.home.com>
Message-ID: <020001c032c2$3060fa40$4500a8c0@thomasnotebook>

> Thomas, thanks for the explanation.  I agree that you can check in the
> changes yourself as you proposed.
> 
> There's one issue I still don't understand (not having the time to
> read the full distutils docs): how does a typical Windows developer
> decide whether to use an external zip utility or the zipfile module?
I'm afraid it is not documented.

Distutils first tries to spawn an external zip program,
then tries the zipfile module, if nothing is found,
a warning is issued.

So, the windows developer currently _must_ install zip.exe
somewhere in the path. (As often, the default is wrong,
because a zip utility is not included in windows).

Thomas



From mal@lemburg.com  Tue Oct 10 15:03:14 2000
From: mal@lemburg.com (M.-A. Lemburg)
Date: Tue, 10 Oct 2000 16:03:14 +0200
Subject: [Python-Dev] LICENSE file in Python 2.0c1
References: <39E31261.166F1601@lemburg.com> <200010101436.JAA13237@cj20424-a.reston1.va.home.com>
Message-ID: <39E321A2.2BD99E35@lemburg.com>

Guido van Rossum wrote:
> 
> > I've just had a glance at the releas candidate 1. The file LICENSE
> > has grown somewhat, but not as much as I feared...
> 
> Since when?  It hasn't changed since it was first released, for 2.0b1.

Since the old 1.5.2 LICENSE file.
 
> > looking
> > at the contents I find the following as only reference to the
> > CNRI license (which holds all the surprises we talked about in
> > the early beta stages):
> >
> > """
> > CNRI OPEN SOURCE LICENSE AGREEMENT
> > ----------------------------------
> >
> > Python 1.6 is made available subject to the terms and conditions in
> > CNRI's License Agreement.  This Agreement together with Python 1.6 may
> > be located on the Internet using the following unique, persistent
> > identifier (known as a handle): 1895.22/1012.  This Agreement may also
> > be obtained from a proxy server on the Internet using the following
> > URL: http://hdl.handle.net/1895.22/1012.
> > """
> >
> > Such a note is nice and short, but not legally binding and
> > confusing since it is not clear whether the "handle" for the
> > document will always return the same license text or if it
> > will return a license text at all.
> 
> Why do you say it's not legally binding?  The CNRI license explicitly
> allows you to use this exact text instead of including the whole CNRI
> license.

Sure, but not including the verbatim text will produce an
unpleasent feeling of not being sure about the completeness
of the license text.

<nitpicker-suite>

In a law suit the above construct would
certainly not hold, since URLs only describe the location of
information and don't hold any information about the validity
or origin of it. The situation would be a little better if CNRI
had provided a PGP signature or fingerprint of the license,
since this is (in some countries) a legally accepted way of
determining those two criteria.

Just a side note: the URL given for the license results in a 
redirect to a different URL -
http://www.handle.net/python_licenses/python1.6_9-5-00.html
(note the date !): this doesn't really give the impression of
persistent unchangeable information.

</nitpicker-suite>

Not that there's much to fear about... but why add any extra areas
of uncertainty ?

> > It would be more appropriate to include the original CNRI license
> > text, IMHO. Or is there some hidden motivation behind using the
> > handle ?
> 
> I was just trying to save space.  ActivePython does the same thing as
> far as I remember.

Space?... the download is 3.9 Megs ;-)
 
> BTW, I haven't heard from CNRI in two weeks, but the last thing I
> heard from them was that their lawyers had talked to Stallman's lawyer
> and that they were optimistic about a successful resolution.

Great ! This would be really good news indeed :-)

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/


From just@letterror.com  Tue Oct 10 16:47:00 2000
From: just@letterror.com (Just van Rossum)
Date: Tue, 10 Oct 2000 16:47:00 +0100
Subject: [Python-Dev] Re: [Stackless] Stackless Python 1.2 + Continuations 0.9
In-Reply-To: <39E2F080.86ED1DA3@appliedbiometrics.com>
Message-ID: <l03102806b608e84fd7de@[193.78.237.153]>

In response to the new release of Stackless Python (see
http://www.stackless.com/), here's a new stackless binary for MacPython
1.5.2:

  http://starship.python.net/~just/MacStacklessPython.sit.hqx

(The archive contains a replacement for the PythonCore shared library)

Just




From guido@python.org  Tue Oct 10 16:50:07 2000
From: guido@python.org (Guido van Rossum)
Date: Tue, 10 Oct 2000 10:50:07 -0500
Subject: [Python-Dev] LICENSE file in Python 2.0c1
In-Reply-To: Your message of "Tue, 10 Oct 2000 16:03:14 +0200."
 <39E321A2.2BD99E35@lemburg.com>
References: <39E31261.166F1601@lemburg.com> <200010101436.JAA13237@cj20424-a.reston1.va.home.com>
 <39E321A2.2BD99E35@lemburg.com>
Message-ID: <200010101550.KAA18130@cj20424-a.reston1.va.home.com>

> > > Such a note is nice and short, but not legally binding and
> > > confusing since it is not clear whether the "handle" for the
> > > document will always return the same license text or if it
> > > will return a license text at all.
> > 
> > Why do you say it's not legally binding?  The CNRI license explicitly
> > allows you to use this exact text instead of including the whole CNRI
> > license.
> 
> Sure, but not including the verbatim text will produce an
> unpleasent feeling of not being sure about the completeness
> of the license text.
> 
> <nitpicker-suite>
> 
> In a law suit the above construct would
> certainly not hold, since URLs only describe the location of
> information and don't hold any information about the validity
> or origin of it. The situation would be a little better if CNRI
> had provided a PGP signature or fingerprint of the license,
> since this is (in some countries) a legally accepted way of
> determining those two criteria.
> 
> Just a side note: the URL given for the license results in a 
> redirect to a different URL -
> http://www.handle.net/python_licenses/python1.6_9-5-00.html
> (note the date !): this doesn't really give the impression of
> persistent unchangeable information.
> 
> </nitpicker-suite>

Funny...  I agree that's not very confidence-inspiring.  CNRI always
advertises handles as better than URLs for long-term persistent
documents, but it's clear that they didn't think of this!  Or maybe
(warning: fake conspiracy theory ahead :-) they intend to change the
license terms after the fact...

> Not that there's much to fear about... but why add any extra areas
> of uncertainty ?

Agreed.  I'll add the full text back in.

> > I was just trying to save space.  ActivePython does the same thing as
> > far as I remember.
> 
> Space?... the download is 3.9 Megs ;-)

I meant less text for the reader to wade through.  But you've
convinced me already.

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


From bjorn@roguewave.com  Tue Oct 10 19:35:15 2000
From: bjorn@roguewave.com (Bjorn Pettersen)
Date: Tue, 10 Oct 2000 12:35:15 -0600
Subject: [Python-Dev] Re: Python 2.0 release candidate 1
References: <200010100652.XAA74600@python.beopen.com>
Message-ID: <39E36163.33291FAB@roguewave.com>

Are there any instructions on how to build this for Win64/itanium
anywhere?

-- bjorn

Jeremy Hylton wrote:
> 
> Python 2.0c1 is released.  The BeOpen PythonLabs and our cast of
> SourceForge volunteers have fixed many bugs since the beta releases
> last month.  Please pick up the new release at
> 
>     http://www.pythonlabs.com/products/python2.0/
> 
> There's a tarball, a Windows installer, RedHat RPMs, online
> documentation, and a long list of fixed bugs.
> 
> The final release of Python 2.0 will be next week.  We would
> appreciate feedback on the release candidate in order to fix any
> remaining bugs before the final release.  Confirmation of build and
> test success on less common platforms is also helpful.n
> 
> All major reported bugs have been fixed in the release candidate.  We
> do not plan to make any changes between now and the final release,
> except to fix bugs reported in the next week.  We encourage potential
> users of Python 2.0 to try the release candidate with their programs
> and report any remaining bugs.
> 
> To report a new bug, use the SourceForge bug tracker
> http://sourceforge.net/bugs/?func=addbug&group_id=5470
> 
> Python 2.0 has many new features, including the following:
> 
>   - Augmented assignment, e.g. x += 1
>   - List comprehensions, e.g. [x**2 for x in range(10)]
>   - Extended import statement, e.g. import Module as Name
>   - Extended print statement, e.g. print >> file, "Hello"
>   - Collection of cyclical garbage
> 
> For a fuller discussion of the changes in Python 2.0, please see the
> article "What's New in Python 2.0" by Andrew Kuchling and Moshe Zadke:
> http://starship.python.net/crew/amk/python/writing/new-python/
> 
> -- Jeremy Hylton <http://www.python.org/~jeremy/>
> 
> --
> http://www.python.org/mailman/listinfo/python-list


From trentm@ActiveState.com  Tue Oct 10 20:51:55 2000
From: trentm@ActiveState.com (Trent Mick)
Date: Tue, 10 Oct 2000 12:51:55 -0700
Subject: Building for Win64 (was: Re: [Python-Dev] Re: Python 2.0 release candidate 1)
In-Reply-To: <39E36163.33291FAB@roguewave.com>; from bjorn@roguewave.com on Tue, Oct 10, 2000 at 12:35:15PM -0600
References: <200010100652.XAA74600@python.beopen.com> <39E36163.33291FAB@roguewave.com>
Message-ID: <20001010125155.B3221@ActiveState.com>

On Tue, Oct 10, 2000 at 12:35:15PM -0600, Bjorn Pettersen wrote:
> Are there any instructions on how to build this for Win64/itanium
> anywhere?
> 

Um... not really.  I did/am doing the Win64 port but I have not really given
the information required to build it, which, I agree, kind of sucks. I have
not done so because:

  - the Python build system on Windows uses DevStudio project files
  - AFAIK there is no DevStudio yet for Win64 (if there were, building Python
    would be trivial, just setup a new configuration in DevStudio)
  - I am currently using a cross-compiler for Win64 provided by Intel (as
    part of a contract that ActiveState has to port Python to Win64 and other
    OSes for the IA-64 platform). I don't know if there is a publicly
    available compiler for Win64 (I haven't looked).
  - My method for building for Win64 involves:
    (1) exporting Win32 build makefile from the Python *.dsp files from
        within DevStudio.
    (2) running a hack script of my own to convert those to makefile to ones
        that will build for Win64 (these makefiles are extremely specific to
        my system, i.e. it is a hack)
    (3) run those makefiles

I *could* checkin this hack script of mine and provide some documentation in
Python's standard readme, if the other python-dev'ers would be ammenable to
this. [Note: my files would be isolated to one directory, say PCbuild/win64.]
As I said, I have not done this because I expected to just wait until
DevStudio for Win64 came on the scene and then the build system for it would
fit in smoothly to the current .dsp's.

I would rather not become a separate provider of the Win64 build scripts
because I don't want to support them outside of Python's mechanisms (i.e.
through SourceForge).  In other words, I'll check them into the Python core
if others think that that is okay, otherwise  I am afraid the answer is
"please wait until DevStudio for Win64 comes along".

Trent

-- 
Trent Mick
TrentM@ActiveState.com


From bjorn@roguewave.com  Tue Oct 10 21:24:00 2000
From: bjorn@roguewave.com (Bjorn Pettersen)
Date: Tue, 10 Oct 2000 14:24:00 -0600
Subject: Building for Win64 (was: Re: [Python-Dev] Re: Python 2.0 release
 candidate 1)
References: <200010100652.XAA74600@python.beopen.com> <39E36163.33291FAB@roguewave.com> <20001010125155.B3221@ActiveState.com>
Message-ID: <39E37AE0.C7380FFD@roguewave.com>

To answer some of your questions:

- there is no win64 devstudio (and I haven't found a way of getting the
current devstudio to use the new compiler)
- Intel does have a native compiler for win64 (don't use it, see below).
- If you look in ia64xdevsdk\bin\win64 there is a cl.exe which is the
Microsoft compiler. It works MUCH better. It's also binary compatible
with the Intel ecl compiler, and they didn't have any problems with us
switching.

My main interest is in having a python version that runs on the itanium
box with socket support (they included socket support in sdk2 didn't
they?) I.e. no need to provide a build mechanism for my needs if you can
refer me to an executable ;-)

-- bjorn

Trent Mick wrote:
> 
> On Tue, Oct 10, 2000 at 12:35:15PM -0600, Bjorn Pettersen wrote:
> > Are there any instructions on how to build this for Win64/itanium
> > anywhere?
> >
> 
> Um... not really.  I did/am doing the Win64 port but I have not really given
> the information required to build it, which, I agree, kind of sucks. I have
> not done so because:
> 
>   - the Python build system on Windows uses DevStudio project files
>   - AFAIK there is no DevStudio yet for Win64 (if there were, building Python
>     would be trivial, just setup a new configuration in DevStudio)
>   - I am currently using a cross-compiler for Win64 provided by Intel (as
>     part of a contract that ActiveState has to port Python to Win64 and other
>     OSes for the IA-64 platform). I don't know if there is a publicly
>     available compiler for Win64 (I haven't looked).
>   - My method for building for Win64 involves:
>     (1) exporting Win32 build makefile from the Python *.dsp files from
>         within DevStudio.
>     (2) running a hack script of my own to convert those to makefile to ones
>         that will build for Win64 (these makefiles are extremely specific to
>         my system, i.e. it is a hack)
>     (3) run those makefiles
> 
> I *could* checkin this hack script of mine and provide some documentation in
> Python's standard readme, if the other python-dev'ers would be ammenable to
> this. [Note: my files would be isolated to one directory, say PCbuild/win64.]
> As I said, I have not done this because I expected to just wait until
> DevStudio for Win64 came on the scene and then the build system for it would
> fit in smoothly to the current .dsp's.
> 
> I would rather not become a separate provider of the Win64 build scripts
> because I don't want to support them outside of Python's mechanisms (i.e.
> through SourceForge).  In other words, I'll check them into the Python core
> if others think that that is okay, otherwise  I am afraid the answer is
> "please wait until DevStudio for Win64 comes along".
> 
> Trent
> 
> --
> Trent Mick
> TrentM@ActiveState.com


From trentm@ActiveState.com  Tue Oct 10 21:20:42 2000
From: trentm@ActiveState.com (Trent Mick)
Date: Tue, 10 Oct 2000 13:20:42 -0700
Subject: [Python-Dev] Monterey (64-bit AIX) screws up the poll() implementation, I think
Message-ID: <20001010132042.B22561@ActiveState.com>

test_poll.py currently fails on Monterey (64-bit AIX) because of a difference
in the system poll() function as compared to Linux.

On Linux (and as required by the Signle Unix Specification:
http://www.opengroup.org/onlinepubs/007908799/xsh/poll.html) if you "poll()"
a bogus file descriptor you get a POLLNVAL return value in the 'revents'
field of the structure sent to poll(). This is tested like so in
test_poll.py:

    # returns NVAL for invalid file descriptor
    FD = 42
    try:
        os.close(FD)
    except OSError:
        pass
    p = select.poll()
    p.register(FD)
    r = p.poll()
    assert r[0] == (FD, select.POLLNVAL)

Monterey decided to return -1 instead. [Aside: However, 'revents's type is
"short" so the Python interface to poll() (using PyInt_FromLong) actually
interprets that as -32768 instead.]

Questions:
1. Can anybody offer an opinion if this is Python's or Monterey's problem?

2. Can anybody tell me where I can browse the POSIX spec to see if this
   breaks POSIX compliance as well?

3. Could someone (Vladimir?) run this test program on a normal AIX box and
   tell me what the output is (does the return value == POLLNVAL?)?

----------------------------------------------------------------------
#include <stdio.h>
#include <poll.h>

#define NFDS 1

int main(void)
{
    struct pollfd ufds[NFDS];
    int pollResult;

    printf("hello\n");

    /* poll for any event on a bogus file descriptor */
    ufds[0].fd = 42;
    ufds[0].events = POLLIN | POLLPRI | POLLOUT;
    pollResult = poll(ufds, NFDS, -1);

    if (pollResult != 1) {
        printf("*** poll result was %d, I expected 1.\n", pollResult);
    }

    printf("ufds[0].revents = %hd\n", ufds[0].revents);
    printf("POLLNVAL = %ld\n", POLLNVAL);

    return 0;
}
----------------------------------------------------------------------


Thanks,
Trent

-- 
Trent Mick
TrentM@ActiveState.com


From trentm@ActiveState.com  Tue Oct 10 21:30:03 2000
From: trentm@ActiveState.com (Trent Mick)
Date: Tue, 10 Oct 2000 13:30:03 -0700
Subject: Building for Win64 (was: Re: [Python-Dev] Re: Python 2.0 release candidate 1)
In-Reply-To: <39E37AE0.C7380FFD@roguewave.com>; from bjorn@roguewave.com on Tue, Oct 10, 2000 at 02:24:00PM -0600
References: <200010100652.XAA74600@python.beopen.com> <39E36163.33291FAB@roguewave.com> <20001010125155.B3221@ActiveState.com> <39E37AE0.C7380FFD@roguewave.com>
Message-ID: <20001010133003.C22561@ActiveState.com>

On Tue, Oct 10, 2000 at 02:24:00PM -0600, Bjorn Pettersen wrote:
> - If you look in ia64xdevsdk\bin\win64 there is a cl.exe which is the
> Microsoft compiler. It works MUCH better. It's also binary compatible
> with the Intel ecl compiler, and they didn't have any problems with us
> switching.

Yes, I knew that that was there. I remember either some earlier problem with
it or some recommnedation to use the ecl.exe one. Anyway, ecl has worked for
me well enough, I just haven't tried the one in Win64/.

 
> My main interest is in having a python version that runs on the itanium
> box with socket support (they included socket support in sdk2 didn't
> they?) I.e. no need to provide a build mechanism for my needs if you can
> refer me to an executable ;-)

Well, Python's test_socket runs on my Win64 box so yes, socket support is
there. As far as referring you to an exe, I would rather not go down that
distribution road in preference to checking in my build scripts.

Trent


-- 
Trent Mick
TrentM@ActiveState.com


From mal@lemburg.com  Tue Oct 10 21:37:30 2000
From: mal@lemburg.com (M.-A. Lemburg)
Date: Tue, 10 Oct 2000 22:37:30 +0200
Subject: [Python-Dev] -Wall output for the Python 2.0c1
Message-ID: <39E37E0A.90176759@lemburg.com>

FYI, Here's what gcc -Wall gives on Linux:

ceval.c: In function `eval_code2':
ceval.c:345: warning: `v' might be used uninitialized in this function
ceval.c:346: warning: `w' might be used uninitialized in this function
ceval.c:347: warning: `u' might be used uninitialized in this function
ceval.c:348: warning: `t' might be used uninitialized in this function
errors.c: In function `PyErr_Format':
errors.c:409: warning: value computed is not used
errors.c:415: warning: value computed is not used

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/


From mal@lemburg.com  Tue Oct 10 21:45:00 2000
From: mal@lemburg.com (M.-A. Lemburg)
Date: Tue, 10 Oct 2000 22:45:00 +0200
Subject: [Python-Dev] What will happen to cycle GC in the 2.0 final ?
Message-ID: <39E37FCC.9925555A@lemburg.com>

It was mentioned early in the beta phase that cycle GC would be
enabled only during the beta cycle and disabled in the final.

Is this still true ?

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/


From tim_one@email.msn.com  Tue Oct 10 21:47:06 2000
From: tim_one@email.msn.com (Tim Peters)
Date: Tue, 10 Oct 2000 16:47:06 -0400
Subject: [Python-Dev] Monterey (64-bit AIX) screws up the poll() implementation, I think
In-Reply-To: <20001010132042.B22561@ActiveState.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCAEKLHKAA.tim_one@email.msn.com>

[Trent Mick]
> test_poll.py currently fails on Monterey (64-bit AIX) because of
> a difference in the system poll() function as compared to Linux.
>
> On Linux (and as required by the Signle Unix Specification:
> http://www.opengroup.org/onlinepubs/007908799/xsh/poll.html) if
> you "poll()" a bogus file descriptor you get a POLLNVAL return value in
> the 'revents' field of the structure sent to poll().
> ...
> Monterey decided to return -1 instead. [Aside: However, 'revents's type is
> "short" so the Python interface to poll() (using PyInt_FromLong) actually
> interprets that as -32768 instead.]
>
> Questions:
> 1. Can anybody offer an opinion if this is Python's or Monterey's
>    problem?

Both.  "Another day, another incompatible flavor of Unix(tm)."  In the early
days, Guido actually hoped he could get away without a massive hack like
autoconf <wink>.

> 2. Can anybody tell me where I can browse the POSIX spec to see if this
>    breaks POSIX compliance as well?

Nowhere:  ISO/ANSI stds are generally never available online.  They get the
bulk of their money from selling standards.

    http://webstore.ansi.org/

is a good place to buy.  There are about 20 POSIX-related stds documents;
the C API spec is US$245.00.  You may get a cheaper answer on comp.unix.aix,
of course.

may-be-worth-more-than-$245-to-weed-out-the-wrong-answers-though-ly y'rs
    - tim




From tim_one@email.msn.com  Tue Oct 10 21:58:54 2000
From: tim_one@email.msn.com (Tim Peters)
Date: Tue, 10 Oct 2000 16:58:54 -0400
Subject: [Python-Dev] What will happen to cycle GC in the 2.0 final ?
In-Reply-To: <39E37FCC.9925555A@lemburg.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCAEKNHKAA.tim_one@email.msn.com>

[M.-A. Lemburg]
> It was mentioned early in the beta phase that cycle GC would be
> enabled only during the beta cycle and disabled in the final.
>
> Is this still true ?

No, and it probably never was <wink>:  the intent of enabling gc during the
betas was to determine *whether* to enable it for the final release.  The
beta experience with gc was very good:  a few subtle problems were
uncovered, and Neil fixed them quickly.  It should probably get a ton of
performance testing that never happened, but then so should have all of
2.0 -- no particular reason to pick on gc alone for that.

full-cycle-ahead-ly y'rs  - tim




From fdrake@beopen.com  Tue Oct 10 22:13:47 2000
From: fdrake@beopen.com (Fred L. Drake, Jr.)
Date: Tue, 10 Oct 2000 17:13:47 -0400 (EDT)
Subject: [Python-Dev] -Wall output for the Python 2.0c1
In-Reply-To: <39E37E0A.90176759@lemburg.com>
References: <39E37E0A.90176759@lemburg.com>
Message-ID: <14819.34443.951260.635718@cj42289-a.reston1.va.home.com>

M.-A. Lemburg writes:
 > ceval.c: In function `eval_code2':
 > ceval.c:345: warning: `v' might be used uninitialized in this function
 > ceval.c:346: warning: `w' might be used uninitialized in this function
 > ceval.c:347: warning: `u' might be used uninitialized in this function
 > ceval.c:348: warning: `t' might be used uninitialized in this function

  These would be a real tedium to fix, and I'm not convinced the loss
of clarity is worth it.  From looking at the code in the DUP_TOPX
code, I'm led to think that the compiler just isn't smart enough (it
should figure out that oparg won't change before the second case
statement, and figure it out more carefully.  I'll bet *that* would
remove these warnings and still right in all cases.

 > errors.c: In function `PyErr_Format':
 > errors.c:409: warning: value computed is not used
 > errors.c:415: warning: value computed is not used

  Fixed.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member



From guido@python.org  Wed Oct 11 00:16:42 2000
From: guido@python.org (Guido van Rossum)
Date: Tue, 10 Oct 2000 18:16:42 -0500
Subject: [Python-Dev] pythonlabs.com website down -- 2.0c1 still available!
Message-ID: <200010102316.SAA20071@cj20424-a.reston1.va.home.com>

We're experiencing a serious problem with the pythonlabs.com website.
Unfortunately the site is down with no estimated time for when it will
be back up.  Our bestest brains are working on the problem!

In the mean time, the Python 2.0c1 source tree can be downloaded from
this address:

    http://www.beopen.com/products/python2.0/BeOpen-Python-2.0c1.tar.gz

The Windows installer is here:

    http://www.beopen.com/products/python2.0/BeOpen-Python-2.0c1.exe

And the 2.0c1 documentation is still here (on-line browseable and
downloadable):

    http://www.python.org/doc/2.0c1/

If the outage lasts for more than a day, we'll find another place to
hold the full distribution.

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


From tim_one@email.msn.com  Tue Oct 10 23:47:19 2000
From: tim_one@email.msn.com (Tim Peters)
Date: Tue, 10 Oct 2000 18:47:19 -0400
Subject: [Python-Dev] -Wall output for the Python 2.0c1
In-Reply-To: <14819.34443.951260.635718@cj42289-a.reston1.va.home.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCMELAHKAA.tim_one@email.msn.com>

[MAL]
> ceval.c: In function `eval_code2':
> ceval.c:345: warning: `v' might be used uninitialized in this function
> ceval.c:346: warning: `w' might be used uninitialized in this function
> ceval.c:347: warning: `u' might be used uninitialized in this function
> ceval.c:348: warning: `t' might be used uninitialized in this function

[Fred]
>   These would be a real tedium to fix, and I'm not convinced the loss
> of clarity is worth it.

I'll take this one.  It looks easy to fix, and to my eye doing *everything*
needed for oparg == 5 in a single block (ditto for 4, 3, 2, 1 in their own
blocks) would be much clearer than the current distributed trickiness
(faster, too -- the code now is branching more than computing).

> From looking at the code in the DUP_TOPX code, I'm led to think that
> the compiler just isn't smart enough (it should figure out that oparg
> won't change before the second case statement, and figure it out more
> carefully.  I'll bet *that* would remove these warnings and still right
> in all cases.

I agree, except that it wasn't trivial for *me* to decide the compiler was
being stupid.  Code that's obviously correct is better than code that's not
obviously wrong.

>> errors.c: In function `PyErr_Format':
>> errors.c:409: warning: value computed is not used
>> errors.c:415: warning: value computed is not used

Thanks!

>   Fixed.

Thanks!




From thomas@xs4all.net  Tue Oct 10 23:49:37 2000
From: thomas@xs4all.net (Thomas Wouters)
Date: Wed, 11 Oct 2000 00:49:37 +0200
Subject: [Python-Dev] -Wall output for the Python 2.0c1
In-Reply-To: <14819.34443.951260.635718@cj42289-a.reston1.va.home.com>; from fdrake@beopen.com on Tue, Oct 10, 2000 at 05:13:47PM -0400
References: <39E37E0A.90176759@lemburg.com> <14819.34443.951260.635718@cj42289-a.reston1.va.home.com>
Message-ID: <20001011004937.Q12812@xs4all.nl>

On Tue, Oct 10, 2000 at 05:13:47PM -0400, Fred L. Drake, Jr. wrote:

> M.-A. Lemburg writes:
>  > ceval.c: In function `eval_code2':
>  > ceval.c:345: warning: `v' might be used uninitialized in this function
>  > ceval.c:346: warning: `w' might be used uninitialized in this function
>  > ceval.c:347: warning: `u' might be used uninitialized in this function
>  > ceval.c:348: warning: `t' might be used uninitialized in this function

>   These would be a real tedium to fix, and I'm not convinced the loss
> of clarity is worth it.  From looking at the code in the DUP_TOPX
> code, I'm led to think that the compiler just isn't smart enough (it
> should figure out that oparg won't change before the second case
> statement, and figure it out more carefully.  I'll bet *that* would
> remove these warnings and still right in all cases.

Well, I'm certain I compiled my code (which included DUP_TOPX) with -Wall
sometime before, and I didn't get those warnings then. Probably depends on
the version of gcc. As a colleague of mine would say, "insert clue" (into
gcc, that is ;)

-- 
Thomas Wouters <thomas@xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!


From guido@python.org  Wed Oct 11 00:57:38 2000
From: guido@python.org (Guido van Rossum)
Date: Tue, 10 Oct 2000 18:57:38 -0500
Subject: [Python-Dev] Re: pythonlabs.com website down -- 2.0c1 still available!
In-Reply-To: Your message of "Tue, 10 Oct 2000 18:16:42 EST."
 <200010102316.SAA20071@cj20424-a.reston1.va.home.com>
References: <200010102316.SAA20071@cj20424-a.reston1.va.home.com>
Message-ID: <200010102357.SAA20163@cj20424-a.reston1.va.home.com>

I wrote:
> We're experiencing a serious problem with the pythonlabs.com website.
> Unfortunately the site is down with no estimated time for when it will
> be back up.  Our bestest brains are working on the problem!

With the help of Digital Creations' bestest brain, Jim Fulton, the
site is back up in record time.  We'll try not to break it again, Jim!
And thanks to Digital Creations for helping us out on such a short
notice.

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


From fdrake@beopen.com  Wed Oct 11 01:57:11 2000
From: fdrake@beopen.com (Fred L. Drake, Jr.)
Date: Tue, 10 Oct 2000 20:57:11 -0400 (EDT)
Subject: [Python-Dev] -Wall output for the Python 2.0c1
In-Reply-To: <20001011004937.Q12812@xs4all.nl>
References: <39E37E0A.90176759@lemburg.com>
 <14819.34443.951260.635718@cj42289-a.reston1.va.home.com>
 <20001011004937.Q12812@xs4all.nl>
Message-ID: <14819.47847.268859.42306@cj42289-a.reston1.va.home.com>

Thomas Wouters writes:
 > Well, I'm certain I compiled my code (which included DUP_TOPX) with -Wall
 > sometime before, and I didn't get those warnings then. Probably depends on
 > the version of gcc. As a colleague of mine would say, "insert clue" (into
 > gcc, that is ;)

  This is very reasonable.  I don't think we'll give you too many
demerits for this.  ;)


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member



From tim_one@email.msn.com  Wed Oct 11 05:40:41 2000
From: tim_one@email.msn.com (Tim Peters)
Date: Wed, 11 Oct 2000 00:40:41 -0400
Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison)
In-Reply-To: <slrn8u73ug.8jj.hzhu@rock.localdomain>
Message-ID: <LNBBLJKPBEHFEDALKOLCKELGHKAA.tim_one@email.msn.com>

We need a glibc expert!  Anyone qualify?

[Huaiyu Zhu]
> ...
> This is very likely to be a 2.0 bug.

Or a 1.5.2 bug.  I have to keep saying this stuff is a platform-dependent
crap shoot, because it is (I too prefer that Python underflow silently by
default, though).

> Just to make sure, I have used freshly downloaded source code of
> both 1.5.2 and 2.0b2, then

> ./configure
> make
> ./python
>
> from math import *
> exp(-746)
>
> I got 0.0 from 1.5.2 but OverflowError: math range error from 2.0b2.
>
> The file mathmodule.c has quite some differences between the two versions,
> mostly related to the ANSIfication.  I'm not sure where the problem is.

It's not in mathmodule.c.

> I haven't tried the 2.0c1 yet, as the site is not available.  Can
> other Unix users confirm this behavior?

I went over to Guido's and forced him to try it.  He sees the same behavior:
after building 1.5.2 and some flavor of 2.0 w/ the same gcc and libraries,
1.5.2 Python silently returns 0 and (some flavor of) 2.0 raises
OverflowError.

But there is no code in Python that accounts for the difference.  Running it
under the debugger, the platform exp leaves errno at 0 under 1.5.2 but sets
errno to ERANGE (34) under 2.0.  Since the platform exp was the only
conceivable cause for this difference, it's not surprising that the debugger
confirmed that the platform exp is in fact the cause.

So the remaining question is why the same exp from the same library has
different errno behavior depending on which version of Python it's called
from.  *That* one we couldn't answer, after a fruitless time digging thru
the Byzantine glibc source code trying to reverse engineer it.  Their exp
*can* display different error behavior at runtime depending on several
obscure things, but they're too obscure to relate back clearly to anything
Python is doing.

The 2.0 behavior (set errno to ERANGE on exp underflow) appears to be what
the glibc exp author believes POSIX mandates, and is one of their exp's
possible runtime behaviors, and your own little C program (which you posted
earlier) suggests that's the default behavior under gcc + glibc.  So
presumably 1.5.2 config was such as to inhibit the default behavior.
However, nobody changed this on purpose, so it smells like an unintended
side effect of some other (currently unknown) config change.

I don't know what to do next.  I can't pursue it myself, and you've seen
from the lack of replies to your posts that I'm the only who'll even listen
to you <wink>.  Guido suggests that one big change in 2.0 is that we're
including a lot more std headers than we used to.  It could well be that one
of those #defines some God-forsaken preprocessor symbol one of whose five
meanings (documented or not) is "use POSIX-conformant libm error reporting",
but which someone #include'd in 2.0 to make (who knows?) sockets work right
on some other flavor of Unix.  Don't know.  Unix config is a mess, and so is
glibc.  Best hope now is for someone intimately familiar with glibc
internals to jump in and own this.

staring-at-the-python-source-remains-pointless-for-this-one-ly y'rs  - tim




From huaiyu_zhu@yahoo.com  Wed Oct 11 09:12:37 2000
From: huaiyu_zhu@yahoo.com (Huaiyu Zhu)
Date: Wed, 11 Oct 2000 01:12:37 -0700 (PDT)
Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich
 comparison)
In-Reply-To: <LNBBLJKPBEHFEDALKOLCKELGHKAA.tim_one@email.msn.com>
Message-ID: <Pine.LNX.4.10.10010110044370.25593-100000@rock.localdomain>

[Tim Peters]

> We need a glibc expert!  Anyone qualify?

If there is none here, maybe someone cares to ask in some gcc or gnu news
groups?

> The 2.0 behavior (set errno to ERANGE on exp underflow) appears to be what
> the glibc exp author believes POSIX mandates, and is one of their exp's
> possible runtime behaviors, and your own little C program (which you posted
> earlier) suggests that's the default behavior under gcc + glibc.  So
> presumably 1.5.2 config was such as to inhibit the default behavior.
> However, nobody changed this on purpose, so it smells like an unintended
> side effect of some other (currently unknown) config change.

So can we set a flag to explicitly discount ERANGE?  There are only 19 lines
in the source code that contain ERANGE, and 8 lines containing math_error.
All the latter are in Modules/{c,}mathmodule.c.  Could we just add an ifdef
IEEE754 on these 8 lines?  This would go a long way to aleviate this problem
before we find a perfect solution, if there is one.

> I don't know what to do next.  I can't pursue it myself, and you've seen
> from the lack of replies to your posts that I'm the only who'll even listen
> to you <wink>.  Guido suggests that one big change in 2.0 is that we're
> including a lot more std headers than we used to.  It could well be that one
> of those #defines some God-forsaken preprocessor symbol one of whose five
> meanings (documented or not) is "use POSIX-conformant libm error reporting",
> but which someone #include'd in 2.0 to make (who knows?) sockets work right
> on some other flavor of Unix.  Don't know.  Unix config is a mess, and so is
> glibc.  Best hope now is for someone intimately familiar with glibc
> internals to jump in and own this.

I'm not interested in where this comes from - the only thing that matters is
that it worked in 1.5.2 and breaks in 2.0.  Whether the 1.5.2 behavior was
intended or not, it's not a bug.  The 2.0 behavior is a bug.  If Posix
conflicts with IEEE floating point arithmetic, then confirming to Posix in
this regard is a bug.

I would suggest the next thing to do is to introduce an IEEE754 flag and let
those who do not like it to voice their opinions.  Since this is the same
behavior as 1.5.2 I doubt any running code would be broken by this.

Huaiyu



From thomas@xs4all.net  Wed Oct 11 09:26:14 2000
From: thomas@xs4all.net (Thomas Wouters)
Date: Wed, 11 Oct 2000 10:26:14 +0200
Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison)
In-Reply-To: <LNBBLJKPBEHFEDALKOLCKELGHKAA.tim_one@email.msn.com>; from tim_one@email.msn.com on Wed, Oct 11, 2000 at 12:40:41AM -0400
References: <slrn8u73ug.8jj.hzhu@rock.localdomain> <LNBBLJKPBEHFEDALKOLCKELGHKAA.tim_one@email.msn.com>
Message-ID: <20001011102614.R12812@xs4all.nl>

On Wed, Oct 11, 2000 at 12:40:41AM -0400, Tim Peters wrote:
> We need a glibc expert!  Anyone qualify?

No, at least not me ;)

> So the remaining question is why the same exp from the same library has
> different errno behavior depending on which version of Python it's called
> from.  *That* one we couldn't answer, after a fruitless time digging thru
> the Byzantine glibc source code trying to reverse engineer it.  Their exp
> *can* display different error behavior at runtime depending on several
> obscure things, but they're too obscure to relate back clearly to anything
> Python is doing.

Well, I've seen & heard about compilers doing slightly different things
depending on ANSI or K&R style C, so perhaps the presence of ANSI C
definitions triggered this. I sincerely doubt it, though, but you never
know, and it's fairly easy to test.

> I don't know what to do next.  I can't pursue it myself, and you've seen
> from the lack of replies to your posts that I'm the only who'll even listen
> to you <wink>.  Guido suggests that one big change in 2.0 is that we're
> including a lot more std headers than we used to.  It could well be that one
> of those #defines some God-forsaken preprocessor symbol one of whose five
> meanings (documented or not) is "use POSIX-conformant libm error reporting",
> but which someone #include'd in 2.0 to make (who knows?) sockets work right
> on some other flavor of Unix.  Don't know.  Unix config is a mess, and so is
> glibc.  Best hope now is for someone intimately familiar with glibc
> internals to jump in and own this.

Actually, there was some activity to define the right combination of
_GNU_SOURCE, _POSIX_SOURCE, _XOPEN_SOURCE, _BSD_SOURCE, et al, but I'm not
sure what the end result was. If any #define changes the behaviour of glibc,
these would definately be it ! A simple test might be to compile 1.5.2 with
the config.h from 2.0, and manually add whatever _*_SOURCE defines aren't in
1.5.2. (They reside in Python.h and config.h, currently.) I'll see if I can
reproduce it on the glibc almost-2.2 (that is, glibc-2.1.94) systems here,
and do some of the above tests.

Computers-suck-ly y'rs,
-- 
Thomas Wouters <thomas@xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!


From thomas@xs4all.net  Wed Oct 11 09:31:49 2000
From: thomas@xs4all.net (Thomas Wouters)
Date: Wed, 11 Oct 2000 10:31:49 +0200
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Python ceval.c,2.207,2.208
In-Reply-To: <200010110704.AAA12861@slayer.i.sourceforge.net>; from tim_one@users.sourceforge.net on Wed, Oct 11, 2000 at 12:04:52AM -0700
References: <200010110704.AAA12861@slayer.i.sourceforge.net>
Message-ID: <20001011103148.S12812@xs4all.nl>

On Wed, Oct 11, 2000 at 12:04:52AM -0700, Tim Peters wrote:

>   			default:
>   				fprintf(stderr, "Invalid argument to DUP_TOPX: %d!\n", oparg);

Hm, this fprintf is stray debugging code, added because I wasn't sure that a
SystemError wouldn't crash the interpreter, given that the stack is utterly
fu*d up at this point and we don't know what the compiler thinks is the
stack size or block size here. (The snippet doesn't show it, but it also
raises a SystemError.) Is it okay if I remove/comment this fprintf() before
2.0 final ?

(At least it didn't say "awoogah, stray debugging code detected, this
machine will self-destruct in 10 seconds" :-)

Another-day-another-demerit<wink>-ly y'rs,
-- 
Thomas Wouters <thomas@xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!


From tim_one@email.msn.com  Wed Oct 11 10:52:59 2000
From: tim_one@email.msn.com (Tim Peters)
Date: Wed, 11 Oct 2000 05:52:59 -0400
Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison)
In-Reply-To: <Pine.LNX.4.10.10010110044370.25593-100000@rock.localdomain>
Message-ID: <LNBBLJKPBEHFEDALKOLCOELMHKAA.tim_one@email.msn.com>

[Huaiyu Zhu]
> ...
> So can we set a flag to explicitly discount ERANGE?  There are
> only 19 lines in the source code that contain ERANGE, and 8 lines
> containing math_error.
> All the latter are in Modules/{c,}mathmodule.c.  Could we just
> add an ifdef IEEE754 on these 8 lines?  This would go a long way to
> aleviate this problem before we find a perfect solution, if there
> is one.

That would stop the exception on exp() underflow, which is what you're
concerned about.  It would also stop exceptions on exp() overflow, and on
underflow and overflow for all other math functions too.  I doubt Guido will
ever let Python ignore overflow by default, #ifdef'ed or not.  A semantic
change that jarring certainly won't happen for 2.0 (which is just a week
away).

> ...
> I'm not interested in where this comes from - the only thing that
> matters is that it worked in 1.5.2 and breaks in 2.0.

The behavior of underflowing exp() is hardly the only thing that matters,
although it's becoming clear it may be the only thing you care about <0.9
wink>.  I would like to change that too for 2.0, but give a thought to the
other consequences.  If some change to the Python config screwed up
exp(-1000) for you, what else is going wrong?  You're not going to get an
answer to that until we know exactly "where this comes from".

> Whether the 1.5.2 behavior was> intended or not, it's not a bug.  The
> 2.0 behavior is a bug.  If Posix conflicts with IEEE floating point
> arithmetic, then confirming to Posix in this regard is a bug.

POSIX doesn't conflict w/ 754 here, as 754 is silent on the matter of errno,
as is POSIX on 754 issues.  It was Python's decision (not POSIX's) to raise
an exception when errno gets set.  Python wasn't designed to support 754,
and makes no claim to support any part of it, so conformance to 754 may be
presented as a feature request, but trying to beat Python over the head with
it won't work:  there's no bug here, in the strong sense that no documented
(or even intended!) behavior has changed.  What happened is that one
platform accident got changed to a different platform accident.  You
certainly get sympathy for that, but not enough to buy radical last-minute
changes.

> I would suggest the next thing to do is to introduce an IEEE754
> flag and let those who do not like it to voice their opinions.

Nothing like that will happen without a PEP first.  I would like to see
*serious* 754 support myself, but that depends too on many platform experts
contributing real work (if everyone ran WinTel, I could do it myself
<wink>).

> Since this is the same behavior as 1.5.2 I doubt any running code would be
> broken by this.

Ignoring ERANGE entirely is not at all the same behavior as 1.5.2, and
current code certainly relies on detecting overflows in math functions.  It
would also break code on platforms that were setting errno to ERANGE all
along on underflow (as POSIX appears to require, and ANSI C doesn't appear
to forbid; I don't know of such a platform for sure offhand, but to judge
from their manpages, HPUX looks like one).

In no case can you expect to see overflow ignored in 2.0.

I want to know where this comes from, so we have *some* handle on what other
surprises may be lurking.

If no progress is made on determining the true cause over the next few days,
I'll hack mathmodule.c to ignore ERANGE in the specific case the result
returned is a zero (which would "fix" your exp underflow problem without
stopping overflow detection).  Since this will break code on any platform
where errno was set to ERANGE on underflow in 1.5.2, I'll need to have a
long discussion w/ Guido first.  I *believe* that much is actually sellable
for 2.0, because it moves Python in a direction I know he likes regardless
of whether he ever becomes a 754 True Believer.

like-herding-cats-indeed-ly y'rs  - tim




From tim_one@email.msn.com  Wed Oct 11 11:02:05 2000
From: tim_one@email.msn.com (Tim Peters)
Date: Wed, 11 Oct 2000 06:02:05 -0400
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Python ceval.c,2.207,2.208
In-Reply-To: <20001011103148.S12812@xs4all.nl>
Message-ID: <LNBBLJKPBEHFEDALKOLCMELNHKAA.tim_one@email.msn.com>

> >   			default:
> >   				fprintf(stderr, "Invalid argument
> to DUP_TOPX: %d!\n", oparg);

[Thomas Wouters]
> Hm, this fprintf is stray debugging code, added because I wasn't
> sure that a SystemError wouldn't crash the interpreter, given that the
> stack is utterly fu*d up at this point and we don't know what the
> compiler thinks is the stack size or block size here. (The snippet
> doesn't show it, but it also raises a SystemError.) Is it okay if I
> remove/comment this fprintf() before 2.0 final ?

Suggest replacing it with:

    assert(!"Invalid argument to DUP_TOPX");

Then there's no cost in release mode, but we have a useful check in debug
mode.  ("assert(!string)" is a handy C debugging idiom more people should
know about!  It's semantically the same as assert(0) (i.e. will fail if ever
reached), but unlike using a comment, using a string gets a useful msg
displayed if it ever does fail).

> (At least it didn't say "awoogah, stray debugging code detected, this
> machine will self-destruct in 10 seconds" :-)

Beats "Unto the root this day a brother is born" <wink -- a famous "can't
happen" msg that, of course, got displayed, many years ago in a different
project -- except the original was in Latin!>.

> Another-day-another-demerit<wink>-ly y'rs,

That's a funny thing about working on Python:  collect 5 demerits and you
can exchange them for 1 brownie point!  If you're not leaving crap behind,
you're not eating enough Python code.

continuous-recoding-is-as-effective-as-it-is-rare-ly y'rs  - tim




From guido@python.org  Wed Oct 11 15:39:06 2000
From: guido@python.org (Guido van Rossum)
Date: Wed, 11 Oct 2000 09:39:06 -0500
Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison)
In-Reply-To: Your message of "Wed, 11 Oct 2000 05:52:59 -0400."
 <LNBBLJKPBEHFEDALKOLCOELMHKAA.tim_one@email.msn.com>
References: <LNBBLJKPBEHFEDALKOLCOELMHKAA.tim_one@email.msn.com>
Message-ID: <200010111439.JAA02783@cj20424-a.reston1.va.home.com>

Incidentally, math.exp(800) returns inf in 1.5, and raises
OverflowError in 2.0.  So at least it's consistent.

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


From Moshe Zadka <moshez@math.huji.ac.il>  Wed Oct 11 13:38:21 2000
From: Moshe Zadka <moshez@math.huji.ac.il> (Moshe Zadka)
Date: Wed, 11 Oct 2000 15:38:21 +0300 (IDT)
Subject: [Python-Dev] OS Dependant Bugs
Message-ID: <Pine.GSO.4.10.10010111534170.7162-100000@sundial>

Many of the sourceforge bugs are platform dependant. Unfortunately, it is
impossible, from the main bugs page, to see which are platform dependant,
and which platform the occur on.

I suggest that, until SF supports it properly, each bug report we enter
will have an optional [Platform] in front, if it seems to be platform
dependant. 

Any opinions? Anyone thinks submitting an SF request to add this field
is foolish?

--
Moshe Zadka <moshez@math.huji.ac.il>
There is no IGLU cabal.
http://advogato.org/person/moshez



From guido@python.org  Wed Oct 11 15:41:47 2000
From: guido@python.org (Guido van Rossum)
Date: Wed, 11 Oct 2000 09:41:47 -0500
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Python ceval.c,2.207,2.208
In-Reply-To: Your message of "Wed, 11 Oct 2000 06:02:05 -0400."
 <LNBBLJKPBEHFEDALKOLCMELNHKAA.tim_one@email.msn.com>
References: <LNBBLJKPBEHFEDALKOLCMELNHKAA.tim_one@email.msn.com>
Message-ID: <200010111441.JAA02813@cj20424-a.reston1.va.home.com>

> Suggest replacing it with:
> 
>     assert(!"Invalid argument to DUP_TOPX");

Actually, I would recommend

	Py_FatalError("Invalid argument to DUP_TOPX")

It's not quite the same since it also triggers in release mode.  If,
as Thomas says, this should never happen and can only be caused by
garbled bytecode, a fatal error is proper rather than a SystemError.

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


From Moshe Zadka <moshez@math.huji.ac.il>  Wed Oct 11 13:41:27 2000
From: Moshe Zadka <moshez@math.huji.ac.il> (Moshe Zadka)
Date: Wed, 11 Oct 2000 15:41:27 +0300 (IDT)
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Python
 ceval.c,2.207,2.208
In-Reply-To: <200010111441.JAA02813@cj20424-a.reston1.va.home.com>
Message-ID: <Pine.GSO.4.10.10010111539440.7162-100000@sundial>

On Wed, 11 Oct 2000, Guido van Rossum wrote:

> 	Py_FatalError("Invalid argument to DUP_TOPX")
> 
> It's not quite the same since it also triggers in release mode.  If,
> as Thomas says, this should never happen and can only be caused by
> garbled bytecode, a fatal error is proper rather than a SystemError.

Can't user Python code, fiddling around with bytecode, produce garbled
bytecode? In that case, it seems  even better to raise an exception.

Unless I misunderstand the discussion completely.

jumping-to-discussions-in-the-middle-ly y'rs, Z.

--
Moshe Zadka <moshez@math.huji.ac.il>
There is no IGLU cabal.
http://advogato.org/person/moshez



From fdrake@beopen.com  Wed Oct 11 14:42:57 2000
From: fdrake@beopen.com (Fred L. Drake, Jr.)
Date: Wed, 11 Oct 2000 09:42:57 -0400 (EDT)
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Python ceval.c,2.207,2.208
In-Reply-To: <200010110704.AAA12861@slayer.i.sourceforge.net>
References: <200010110704.AAA12861@slayer.i.sourceforge.net>
Message-ID: <14820.28257.836222.958973@cj42289-a.reston1.va.home.com>

Tim Peters writes:
 > Update of /cvsroot/python/python/dist/src/Python
 > Attempt to fix bogus gcc -Wall warnings reported by Marc-Andre Lemburg,
 > by making the DUP_TOPX code utterly straightforward.  This also gets rid
 > of all normal-case internal DUP_TOPX if/branches, and allows replacing one
 > POP() with TOP() in each case, so is a good idea regardless.

Tim,
  There's still one left:

gcc -Wall -O2 -Wstrict-prototypes -I../../Python/../Include -I.. -DHAVE_CONFIG_H   -c -o ceval.o ../../Python/ceval.c
../../Python/ceval.c: In function `eval_code2':
../../Python/ceval.c:346: warning: `w' might be used uninitialized in
this function

  Cruising through this code, it looks like the problem might be in
the PRINT_NEWLINE case:

		case PRINT_NEWLINE:
			if (stream == NULL || stream == Py_None) {
				w = PySys_GetObject("stdout");
				if (w == NULL)
					PyErr_SetString(PyExc_RuntimeError,
							"lost sys.stdout");
			}
			if (w != NULL) {
	/* If PRINT_NEWLINE is the opcode, w might not be initialized
         * here (I think), since I don't see it initialize before the
         * switch.  Since we can't initialize it to NULL with the case
         * (doing so would break the PRINT_NEWLINE_TO case), it would
         * have to be initialized before the main loop is entered.
         */
				err = PyFile_WriteString("\n", w);
				if (err == 0)
					PyFile_SoftSpace(w, 0);
			}
			Py_XDECREF(stream);
			stream = NULL;
			break;

  Ok.... yep, initializing that seems to work.
  I'll check in the fix for this one after I've run the regression test.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member



From guido@python.org  Wed Oct 11 15:54:14 2000
From: guido@python.org (Guido van Rossum)
Date: Wed, 11 Oct 2000 09:54:14 -0500
Subject: [Python-Dev] OS Dependant Bugs
In-Reply-To: Your message of "Wed, 11 Oct 2000 15:38:21 +0300."
 <Pine.GSO.4.10.10010111534170.7162-100000@sundial>
References: <Pine.GSO.4.10.10010111534170.7162-100000@sundial>
Message-ID: <200010111454.JAA03006@cj20424-a.reston1.va.home.com>

> Many of the sourceforge bugs are platform dependant. Unfortunately, it is
> impossible, from the main bugs page, to see which are platform dependant,
> and which platform the occur on.
> 
> I suggest that, until SF supports it properly, each bug report we enter
> will have an optional [Platform] in front, if it seems to be platform
> dependant. 
> 
> Any opinions? Anyone thinks submitting an SF request to add this field
> is foolish?

I think it's sufficient (actually better) if the platform name is
mentioned in the summary.  Note that you can edit the summary of
existing bug reports.

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



From guido@python.org  Wed Oct 11 15:54:54 2000
From: guido@python.org (Guido van Rossum)
Date: Wed, 11 Oct 2000 09:54:54 -0500
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Python ceval.c,2.207,2.208
In-Reply-To: Your message of "Wed, 11 Oct 2000 15:41:27 +0300."
 <Pine.GSO.4.10.10010111539440.7162-100000@sundial>
References: <Pine.GSO.4.10.10010111539440.7162-100000@sundial>
Message-ID: <200010111454.JAA03020@cj20424-a.reston1.va.home.com>

> Can't user Python code, fiddling around with bytecode, produce garbled
> bytecode? In that case, it seems  even better to raise an exception.

Yes, they can produce garbled bytecode, and if that is detected, it's
not safe to proceed.  So a fatal error is the right thing.

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


From Moshe Zadka <moshez@math.huji.ac.il>  Wed Oct 11 13:56:17 2000
From: Moshe Zadka <moshez@math.huji.ac.il> (Moshe Zadka)
Date: Wed, 11 Oct 2000 15:56:17 +0300 (IDT)
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Python
 ceval.c,2.207,2.208
In-Reply-To: <200010111454.JAA03020@cj20424-a.reston1.va.home.com>
Message-ID: <Pine.GSO.4.10.10010111555020.7162-100000@sundial>

On Wed, 11 Oct 2000, Guido van Rossum wrote:

> > Can't user Python code, fiddling around with bytecode, produce garbled
> > bytecode? In that case, it seems  even better to raise an exception.
> 
> Yes, they can produce garbled bytecode, and if that is detected, it's
> not safe to proceed.  So a fatal error is the right thing.

The problem with letting Python code cause fatal errors is that it makes
restricted execution much more difficult. Well, something to think about
for 2.1...

--
Moshe Zadka <moshez@math.huji.ac.il>
There is no IGLU cabal.
http://advogato.org/person/moshez



From akuchlin@mems-exchange.org  Wed Oct 11 14:56:50 2000
From: akuchlin@mems-exchange.org (Andrew Kuchling)
Date: Wed, 11 Oct 2000 09:56:50 -0400
Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison)
In-Reply-To: <20001011102614.R12812@xs4all.nl>; from thomas@xs4all.net on Wed, Oct 11, 2000 at 10:26:14AM +0200
References: <slrn8u73ug.8jj.hzhu@rock.localdomain> <LNBBLJKPBEHFEDALKOLCKELGHKAA.tim_one@email.msn.com> <20001011102614.R12812@xs4all.nl>
Message-ID: <20001011095650.A17931@kronos.cnri.reston.va.us>

On Wed, Oct 11, 2000 at 10:26:14AM +0200, Thomas Wouters wrote:
>Actually, there was some activity to define the right combination of
>_GNU_SOURCE, _POSIX_SOURCE, _XOPEN_SOURCE, _BSD_SOURCE, et al, but I'm not
>sure what the end result was. If any #define changes the behaviour of glibc,
>these would definately be it ! A simple test might be to compile 1.5.2 with

That seems the likely cause.  Another faint possibility might be
threading, since 2.0 automatically uses threads but 1.5.2 needs to
have them enabled. (Perhaps Tim remembered this and supplied
--with-thread to the 1.5.2 configure script.)

--amk



From guido@python.org  Wed Oct 11 16:03:00 2000
From: guido@python.org (Guido van Rossum)
Date: Wed, 11 Oct 2000 10:03:00 -0500
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Python ceval.c,2.207,2.208
In-Reply-To: Your message of "Wed, 11 Oct 2000 15:56:17 +0300."
 <Pine.GSO.4.10.10010111555020.7162-100000@sundial>
References: <Pine.GSO.4.10.10010111555020.7162-100000@sundial>
Message-ID: <200010111503.KAA03123@cj20424-a.reston1.va.home.com>

> > > Can't user Python code, fiddling around with bytecode, produce garbled
> > > bytecode? In that case, it seems  even better to raise an exception.
> > 
> > Yes, they can produce garbled bytecode, and if that is detected, it's
> > not safe to proceed.  So a fatal error is the right thing.
> 
> The problem with letting Python code cause fatal errors is that it makes
> restricted execution much more difficult. Well, something to think about
> for 2.1...

Huh?  In restricted execution you shouldn't be allowed to mess with
bytecode!

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


From guido@python.org  Wed Oct 11 16:25:32 2000
From: guido@python.org (Guido van Rossum)
Date: Wed, 11 Oct 2000 10:25:32 -0500
Subject: [Python-Dev] Re: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison)
In-Reply-To: Your message of "Wed, 11 Oct 2000 09:56:50 -0400."
 <20001011095650.A17931@kronos.cnri.reston.va.us>
References: <slrn8u73ug.8jj.hzhu@rock.localdomain> <LNBBLJKPBEHFEDALKOLCKELGHKAA.tim_one@email.msn.com> <20001011102614.R12812@xs4all.nl>
 <20001011095650.A17931@kronos.cnri.reston.va.us>
Message-ID: <200010111525.KAA03324@cj20424-a.reston1.va.home.com>

Bingo!

1.5.2 links with -lieee while 2.0 doesn't.  Removing -lieee from the
1.5.2 link line makes is raise OverflowError too.  Adding it to the
2.0 link line makes it return 0.0 for exp(-1000) and inf for
exp(1000).

Next question: what changed in the configure script, and why?

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


From thomas@xs4all.net  Wed Oct 11 15:24:37 2000
From: thomas@xs4all.net (Thomas Wouters)
Date: Wed, 11 Oct 2000 16:24:37 +0200
Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison)
In-Reply-To: <20001011102614.R12812@xs4all.nl>; from thomas@xs4all.net on Wed, Oct 11, 2000 at 10:26:14AM +0200
References: <slrn8u73ug.8jj.hzhu@rock.localdomain> <LNBBLJKPBEHFEDALKOLCKELGHKAA.tim_one@email.msn.com> <20001011102614.R12812@xs4all.nl>
Message-ID: <20001011162436.T12812@xs4all.nl>

On Wed, Oct 11, 2000 at 10:26:14AM +0200, Thomas Wouters wrote:

[ Py2.0 mathmodule behaves differently when doing math.exp(-1000) and such ]

> Actually, there was some activity to define the right combination of
> _GNU_SOURCE, _POSIX_SOURCE, _XOPEN_SOURCE, _BSD_SOURCE, et al, but I'm not
> sure what the end result was. If any #define changes the behaviour of glibc,
> these would definately be it ! A simple test might be to compile 1.5.2 with
> the config.h from 2.0, and manually add whatever _*_SOURCE defines aren't in
> 1.5.2. (They reside in Python.h and config.h, currently.) I'll see if I can
> reproduce it on the glibc almost-2.2 (that is, glibc-2.1.94) systems here,
> and do some of the above tests.

Well, that was no success. I do see the difference between 1.5.2 and 2.0,
but *damned* if I can figure out where it comes from. It doesn't seem to be
any of the properly placed defines, and it doesn't seem to be the changes in
mathmodule itself. Not autoconf, either. What I did:

old tree (stock Python 1.5.2): math.exp(-1000) returns 0.0
new tree (current CVS): math.exp(-1000) raises OverflowError

(No difference between threads enabled and disabled.)

Use new config.h in old tree: math.exp(-1000) returned 0.0

Add _GNU_SOURCE and _XOPEN_SOURCE definitions (respectively 1 and 500, just
like new Python.h does) to Python.h in old tree: math.exp(-1000) returns 0.0

Copy mathmodule.c and mymath.h from old tree to new tree: math.exp(-1000)
raises OverflowError

Copy new mathmodule.c to old tree (adding an 'include math.h' because the
old Python.h isn't doing that): math.exp(-1000) returns 0.0

Copy config.h and Python.h from new tree to old one (removing the include of
unicodestring.h and codecs.h, and including mymalloc.h rather than pymem.h
to make it compile): math.exp(-1000) returns 0.0

So, as far as I can tell, it's not related to any code in mathmodule.c
itself, nor any defines in config.h or Python.h. mymath.h isn't used either,
as far as I can tell it only contains stuff for broken math stuff on obscure
platforms. Sounds like time for that glibc expert right about now ;-P

-- 
Thomas Wouters <thomas@xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!


From akuchlin@mems-exchange.org  Wed Oct 11 15:32:23 2000
From: akuchlin@mems-exchange.org (Andrew Kuchling)
Date: Wed, 11 Oct 2000 10:32:23 -0400
Subject: [Python-Dev] Re: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison)
In-Reply-To: <200010111525.KAA03324@cj20424-a.reston1.va.home.com>; from guido@python.org on Wed, Oct 11, 2000 at 10:25:32AM -0500
References: <slrn8u73ug.8jj.hzhu@rock.localdomain> <LNBBLJKPBEHFEDALKOLCKELGHKAA.tim_one@email.msn.com> <20001011102614.R12812@xs4all.nl> <20001011095650.A17931@kronos.cnri.reston.va.us> <200010111525.KAA03324@cj20424-a.reston1.va.home.com>
Message-ID: <20001011103223.C17931@kronos.cnri.reston.va.us>

On Wed, Oct 11, 2000 at 10:25:32AM -0500, Guido van Rossum wrote:
>1.5.2 links with -lieee while 2.0 doesn't.  
>Next question: what changed in the configure script, and why?

The patch from revisions 1.138 to 1.139 of configure.in is:

853c1139,1142
< AC_CHECK_LIB(ieee, __fpu_control)
---
> AC_CHECK_FUNC(__fpu_control,
>   [],
>   [AC_CHECK_LIB(ieee, __fpu_control)
> ])

The check-in comment is "Only link with -lieee when it's necessary".
If it only checks for -lieee when the __fpu_control function is
defined, perhaps the function disappeared in glibc 2.1.

--amk


From thomas@xs4all.net  Wed Oct 11 15:32:45 2000
From: thomas@xs4all.net (Thomas Wouters)
Date: Wed, 11 Oct 2000 16:32:45 +0200
Subject: [Python-Dev] Re: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison)
In-Reply-To: <200010111525.KAA03324@cj20424-a.reston1.va.home.com>; from guido@python.org on Wed, Oct 11, 2000 at 10:25:32AM -0500
References: <slrn8u73ug.8jj.hzhu@rock.localdomain> <LNBBLJKPBEHFEDALKOLCKELGHKAA.tim_one@email.msn.com> <20001011102614.R12812@xs4all.nl> <20001011095650.A17931@kronos.cnri.reston.va.us> <200010111525.KAA03324@cj20424-a.reston1.va.home.com>
Message-ID: <20001011163244.U12812@xs4all.nl>

On Wed, Oct 11, 2000 at 10:25:32AM -0500, Guido van Rossum wrote:

> 1.5.2 links with -lieee while 2.0 doesn't.  Removing -lieee from the
> 1.5.2 link line makes is raise OverflowError too.  Adding it to the
> 2.0 link line makes it return 0.0 for exp(-1000) and inf for
> exp(1000).

Ack, that's the one thing I didn't check: link libraries ;-P

> Next question: what changed in the configure script, and why?

Well, that's easy. 

Old configure.in:

# Linux requires this for correct f.p. operations
AC_CHECK_LIB(ieee, __fpu_control)

New configure.in:

# Linux requires this for correct f.p. operations
AC_CHECK_FUNC(__fpu_control,
  [],
  [AC_CHECK_LIB(ieee, __fpu_control)
])

I remember the patch that did this, on SF. It was titled "don't link with
-lieee if it isn't necessary" or something. Not sure what it would break,
but mayhaps declaring -lieee necessary on glibc systems is the right fix ?

(For the non-autoconf readers among us: the first snippet writes a test
program to see if the function '__fpu_control' exists when linking with
-lieee in addition to $LIBS, and if so, adds -lieee to $LIBS. The second
snippet writes a test program to see if the function '__fpu_control' exists
with the current collection of $LIBS. If it doesn't, it tries it again with
-lieee, and adds -lieee to $LIBS if it finds it then.)

Pesonally, I think the patch should just be reversed... The comment above
the check certainly could be read as 'Linux requires -lieee for correct f.p.
operations', and perhaps that's how it was meant.

-- 
Thomas Wouters <thomas@xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!


From skip@mojam.com (Skip Montanaro)  Wed Oct 11 17:31:48 2000
From: skip@mojam.com (Skip Montanaro) (Skip Montanaro)
Date: Wed, 11 Oct 2000 11:31:48 -0500 (CDT)
Subject: [Python-Dev] -Wall output for the Python 2.0c1
In-Reply-To: <LNBBLJKPBEHFEDALKOLCMELAHKAA.tim_one@email.msn.com>
References: <14819.34443.951260.635718@cj42289-a.reston1.va.home.com>
 <LNBBLJKPBEHFEDALKOLCMELAHKAA.tim_one@email.msn.com>
Message-ID: <14820.38388.827883.710489@beluga.mojam.com>

    Tim> I'll take this one.  It looks easy to fix ...

Seems to me like a patch that ought to wait until after 2.0final.  It's
definitely not a show-stopping bug...

Skip


From thomas@xs4all.net  Wed Oct 11 19:04:31 2000
From: thomas@xs4all.net (Thomas Wouters)
Date: Wed, 11 Oct 2000 20:04:31 +0200
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Python ceval.c,2.207,2.208
In-Reply-To: <200010111503.KAA03123@cj20424-a.reston1.va.home.com>; from guido@python.org on Wed, Oct 11, 2000 at 10:03:00AM -0500
References: <Pine.GSO.4.10.10010111555020.7162-100000@sundial> <200010111503.KAA03123@cj20424-a.reston1.va.home.com>
Message-ID: <20001011200431.V12812@xs4all.nl>

On Wed, Oct 11, 2000 at 10:03:00AM -0500, Guido van Rossum wrote:

> > > > Can't user Python code, fiddling around with bytecode, produce garbled
> > > > bytecode? In that case, it seems  even better to raise an exception.

> > > Yes, they can produce garbled bytecode, and if that is detected, it's
> > > not safe to proceed.  So a fatal error is the right thing.

> > The problem with letting Python code cause fatal errors is that it makes
> > restricted execution much more difficult. Well, something to think about
> > for 2.1...

> Huh?  In restricted execution you shouldn't be allowed to mess with
> bytecode!

Well, I can see what Moshe means. You get a code object passed in, say, an
untrusted pickle or some such. You want to execute it, but you don't want it
to ruin your life. Causing the entire program to quit could be considered
'ruining'. On the other hand, if you can hand-tweak bytecode streams in that
degree, you can f** up a lot more. On the one foot, though, most of the
calls to Py_FatalError (as far as I can see) deal with initialization
failures, or structures to which tweaked bytecode would not have access. On
the other foot, it's probably possible to tweak bytecode to *get* access to
those structures, or at least structures that don't like being dereferenced
or DECREF'd. And there's probably more to consider, but I haven't got any
public appendages left, and there might be children listening ;)

All in all, Guido's probably right... If something like this happens, you
don't want to continue. If the argument to DUP_TOPX is something other than
what compile.c generates (between 1 and 5, inclusive, that is) something
strange is going on internally. Better to quit now than delete
c:\command.com by 'accident'. If people can do this to code being run in
restricted environments, they can probably do worse things, too!

Now I just need an OK from Jeremy, as the maitre d', and I'll check it in.

-- 
Thomas Wouters <thomas@xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!


From guido@python.org  Wed Oct 11 22:19:28 2000
From: guido@python.org (Guido van Rossum)
Date: Wed, 11 Oct 2000 16:19:28 -0500
Subject: [Python-Dev] Re: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison)
In-Reply-To: Your message of "Wed, 11 Oct 2000 16:32:45 +0200."
 <20001011163244.U12812@xs4all.nl>
References: <slrn8u73ug.8jj.hzhu@rock.localdomain> <LNBBLJKPBEHFEDALKOLCKELGHKAA.tim_one@email.msn.com> <20001011102614.R12812@xs4all.nl> <20001011095650.A17931@kronos.cnri.reston.va.us> <200010111525.KAA03324@cj20424-a.reston1.va.home.com>
 <20001011163244.U12812@xs4all.nl>
Message-ID: <200010112119.QAA03651@cj20424-a.reston1.va.home.com>

Thanks for digging deeper into this.

> Pesonally, I think the patch should just be reversed... The comment above
> the check certainly could be read as 'Linux requires -lieee for correct f.p.
> operations', and perhaps that's how it was meant.

No, the configure patch is right.  Tim will check in a change that
treats ERANGE with a return value of 0.0 as underflow (returning 0.0,
not raising OverflowError).

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


From tim_one@email.msn.com  Wed Oct 11 22:02:16 2000
From: tim_one@email.msn.com (Tim Peters)
Date: Wed, 11 Oct 2000 17:02:16 -0400
Subject: [Python-Dev] -Wall output for the Python 2.0c1
In-Reply-To: <14820.38388.827883.710489@beluga.mojam.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCAENEHKAA.tim_one@email.msn.com>

[Tim]
> I'll take this one [wngs putatively due to DUP_TOPX].  It looks easy
> to fix ...

[Skip Montanaro]
> Seems to me like a patch that ought to wait until after 2.0final.  It's
> definitely not a show-stopping bug...

Would have been a more interesting argument had you posted this before the
patch was checked in <wink>.

But wngs are non-negotiable with me anyway.  This example turned out to be a
good one for showing why:  the bogus wngs covered up a legitimate
"uninitialized vrbl" complaint (see Fred's later discovery and following
checkin).  I've simply got zero tolerance for wngs or for failures in the
std test suite.  My view is warped by prior experience, though:  the last 6
years, I worked on projects where the compilers were fiddled to treat
warnings as fatal errors.  So while this may have looked like a harmless
batch of wngs to you, as far as I was concerned Python couldn't even be
compiled anymore <0.7 wink>.

extremism-in-defense-of-simple-best-practice-may-or-may-not-be-
    vice-but-it's-sure-effective-over-the-long-term-ly y'rs  - tim




From skip@mojam.com (Skip Montanaro)  Wed Oct 11 22:07:42 2000
From: skip@mojam.com (Skip Montanaro) (Skip Montanaro)
Date: Wed, 11 Oct 2000 16:07:42 -0500 (CDT)
Subject: [Python-Dev] -Wall output for the Python 2.0c1
In-Reply-To: <LNBBLJKPBEHFEDALKOLCAENEHKAA.tim_one@email.msn.com>
References: <14820.38388.827883.710489@beluga.mojam.com>
 <LNBBLJKPBEHFEDALKOLCAENEHKAA.tim_one@email.msn.com>
Message-ID: <14820.54942.114086.773609@beluga.mojam.com>

    Tim> [Tim]
    >> I'll take this one [wngs putatively due to DUP_TOPX].  It looks easy
    >> to fix ...

    Tim> [Skip Montanaro]
    >> Seems to me like a patch that ought to wait until after 2.0final.
    >> It's definitely not a show-stopping bug...

    Tim> Would have been a more interesting argument had you posted this
    Tim> before the patch was checked in <wink>.

Agreed, but I posted as soon as I saw it.  Can't help it if I can't keep up
with all the flurry of activity.

    Tim> So while this may have looked like a harmless batch of wngs to you,
    Tim> as far as I was concerned Python couldn't even be compiled anymore
    Tim> <0.7 wink>.

I accept your explanation. ;-)

S


From jack@oratrix.nl  Wed Oct 11 22:10:36 2000
From: jack@oratrix.nl (Jack Jansen)
Date: Wed, 11 Oct 2000 23:10:36 +0200
Subject: [Python-Dev] test_StringIO failing on the Mac
Message-ID: <20001011211041.96D2BE266F@oratrix.oratrix.nl>

I have one remaining problem (at least, as far as I'm aware:-) with
2.0c1 on the Mac: test_StringIO fails.

The reason is that the test_StringIO output file was generated on
Unix, and hence it uses the unix form of string.letters (a-zA-Z),
whereas the Mac version of string.letters has far more values.

As this isn't what the test is about in the first place, shall I fix
the test?
--
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/ ++++


From tim_one@email.msn.com  Wed Oct 11 22:14:17 2000
From: tim_one@email.msn.com (Tim Peters)
Date: Wed, 11 Oct 2000 17:14:17 -0400
Subject: [Python-Dev] test_StringIO failing on the Mac
In-Reply-To: <20001011211041.96D2BE266F@oratrix.oratrix.nl>
Message-ID: <LNBBLJKPBEHFEDALKOLCIENFHKAA.tim_one@email.msn.com>

[Jack Jansen]
> I have one remaining problem (at least, as far as I'm aware:-) with
> 2.0c1 on the Mac: test_StringIO fails.
> 
> The reason is that the test_StringIO output file was generated on
> Unix, and hence it uses the unix form of string.letters (a-zA-Z),
> whereas the Mac version of string.letters has far more values.
> 
> As this isn't what the test is about in the first place, shall I fix
> the test?

+1 from me on making the test portable.




From jeremy@beopen.com  Thu Oct 12 00:06:56 2000
From: jeremy@beopen.com (Jeremy Hylton)
Date: Wed, 11 Oct 2000 19:06:56 -0400 (EDT)
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Python ceval.c,2.207,2.208
In-Reply-To: <20001011200431.V12812@xs4all.nl>
References: <Pine.GSO.4.10.10010111555020.7162-100000@sundial>
 <200010111503.KAA03123@cj20424-a.reston1.va.home.com>
 <20001011200431.V12812@xs4all.nl>
Message-ID: <14820.62096.15085.749912@bitdiddle.concentric.net>

>>>>> "TW" == Thomas Wouters <thomas@xs4all.net> writes:

  [Moshe:]
  >> > The problem with letting Python code cause fatal errors is that
  >> > it makes restricted execution much more difficult. Well,
  >> > something to think about for 2.1...

  [Guido:]
  >> Huh?  In restricted execution you shouldn't be allowed to mess
  >> with bytecode!

  TW> Well, I can see what Moshe means. You get a code object passed
  TW> in, say, an untrusted pickle or some such. You want to execute
  TW> it, but you don't want it to ruin your life. Causing the entire
  TW> program to quit could be considered 'ruining'. On the other
  TW> hand, if you can hand-tweak bytecode streams in that degree, you
  TW> can f** up a lot more.

Damn straight!  If you're using restricted execution mode and
accepting bytecode objects that weren't produced by a trusted Python
compiler, you're nuts.  I am not aware of any effort made to protect
the Python VM from attack via malicious bytecode.

  TW> Now I just need an OK from Jeremy, as the maitre d', and I'll
  TW> check it in.

Your table is ready.  A checkin message will be accepted as gratuity. 

Jeremy


From jeremy@beopen.com  Thu Oct 12 00:12:15 2000
From: jeremy@beopen.com (Jeremy Hylton)
Date: Wed, 11 Oct 2000 19:12:15 -0400 (EDT)
Subject: [Python-Dev] Re: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison)
In-Reply-To: <200010112119.QAA03651@cj20424-a.reston1.va.home.com>
References: <slrn8u73ug.8jj.hzhu@rock.localdomain>
 <LNBBLJKPBEHFEDALKOLCKELGHKAA.tim_one@email.msn.com>
 <20001011102614.R12812@xs4all.nl>
 <20001011095650.A17931@kronos.cnri.reston.va.us>
 <200010111525.KAA03324@cj20424-a.reston1.va.home.com>
 <20001011163244.U12812@xs4all.nl>
 <200010112119.QAA03651@cj20424-a.reston1.va.home.com>
Message-ID: <14820.62415.873159.533077@bitdiddle.concentric.net>

I checked in the patch that removed the -lieee link in some cases.  I
don't remember the details off the top of my head, but I can go
digging in the SF patch logs if it's important.  As I recall, someone
reported problems on a platform (HPUX?) where link with ieee caused
problems.  I didn't have access to the platform in question.  So I
applied the patch on a Linux box and ran the regression test; it
reported no errors, so I assumed the patch fixed some other platform
and did mine no harm.

At the moment, I would assume that the patch still helps some other
platform but might not be right on Linux.  On the other hand, it
sounds like Tim has a patch that will cause Linux to do the right
thing.

It's hard to say much about what should or should not happen since
neither the language reference nor the regression tests specifies much
about what should happen with fp.

Jeremy



From thomas@xs4all.net  Thu Oct 12 00:15:21 2000
From: thomas@xs4all.net (Thomas Wouters)
Date: Thu, 12 Oct 2000 01:15:21 +0200
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules dlmodule.c,2.14,2.15
In-Reply-To: <200010112144.OAA20776@slayer.i.sourceforge.net>; from fdrake@users.sourceforge.net on Wed, Oct 11, 2000 at 02:44:05PM -0700
References: <200010112144.OAA20776@slayer.i.sourceforge.net>
Message-ID: <20001012011521.X12812@xs4all.nl>

On Wed, Oct 11, 2000 at 02:44:05PM -0700, Fred L. Drake wrote:
> Update of /cvsroot/python/python/dist/src/Modules
> In directory slayer.i.sourceforge.net:/tmp/cvs-serv20717
> 
> Modified Files:
> 	dlmodule.c 
> Log Message:
> 
> Remove one more gcc -Wall warning.

To note, if gcc didn't inherit at least *some* of C's original philosophy of
'the programmer always knows what [s]he is doing', gcc would yell bloody
murder at this code. The 'func' function pointer is used to point to symbols
loaded from arbitrary shared objects, and the dlmodule has no way of knowing
howmany arguments the function expects, or even if it isn't more than 10
(which would result in the function grabbing garbage off the stack, on most
architectures, I think.) While on the ANSIfication spree, I ran screaming
and hid under my bed after reading this code ;)

Is anyone using the dlmodule anymore ? Is it really useful ? Is this
*really* how loading and calling arbitrary shared objects should be done ? :P

>   {
>   	PyObject *name;
> ! 	long (*func)(long, long, long, long, long,
> !                      long, long, long, long, long);
>   	long alist[10];
>   	long res;

Idle-and-post-2.0-talk-ly y'rs,
-- 
Thomas Wouters <thomas@xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!


From huaiyu_zhu@yahoo.com  Thu Oct 12 00:33:08 2000
From: huaiyu_zhu@yahoo.com (Huaiyu Zhu)
Date: Wed, 11 Oct 2000 16:33:08 -0700 (PDT)
Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich
 comparison)
In-Reply-To: <LNBBLJKPBEHFEDALKOLCOELMHKAA.tim_one@email.msn.com>
Message-ID: <Pine.LNX.4.10.10010111510270.3131-100000@rocket.knowledgetrack.com>

On the issue of whether Python should ignore over/underflow on IEEE-enabled
platforms: 

[Tim Peters]
> That would stop the exception on exp() underflow, which is what you're
> concerned about.  It would also stop exceptions on exp() overflow, and on
> underflow and overflow for all other math functions too.  I doubt Guido will
> ever let Python ignore overflow by default, #ifdef'ed or not.  A semantic
> change that jarring certainly won't happen for 2.0 (which is just a week
> away).

It can be argued that on IEEE enabled systems the proper thing to do for
overflow is simply return Inf.  Raising exception is WRONG.  See below.

[Guido van Rossum]
> Incidentally, math.exp(800) returns inf in 1.5, and raises
> OverflowError in 2.0.  So at least it's consistent.

That is not consistent at all.  Suppose I'm plotting the curve f(x) where
x include some singular points of f.  In the first case the plot works with
some portion of the curve clipped.  In the second case it bombs.  

[Tim Peters] 
> Nothing like that will happen without a PEP first.  I would like to see
> *serious* 754 support myself, but that depends too on many platform experts
> contributing real work (if everyone ran WinTel, I could do it myself
> <wink>).

[Guido van Rossum]
> Bingo!
> 
> 1.5.2 links with -lieee while 2.0 doesn't.  Removing -lieee from the
> 1.5.2 link line makes is raise OverflowError too.  Adding it to the
> 2.0 link line makes it return 0.0 for exp(-1000) and inf for
> exp(1000).

If using ieee is as simple as setting such a flag, there is no reason at all
not to use it.  Here are some more examples:

Suppose you have done hours of computation on a problem.  Just as you are
about to get the result, you get an exception.  Why?  Because the residual
error is too close to zero.

Suppose you want to plot the curve of Gausian distribution.  Oops, it fails.
Because beyond a certain region the value is near zero.

With these kinds of problems, vectorized numerical calculation becomes
nearly impossible.  How do you work in such an environment?  You have to
wrap every calculation in a try/except structure, and whenever there is an
exception, you have to revert to elementwise operations.  In practice this
simply means Python would not be suitable for numerical work at all.

What about the other way round?  No problem.  It is easy to write functions
like isNaN, isInf, etc.  With these one can raise exceptions in any place
one want.  It is even possible to raise exceptions if a matrix is singular
to a certain precision, etc.

The key point to observe here is that most numerical work involve more than
one element.  Some of them may be out of mahcine bounds but the whole thing
could still be quite meaningful.  Vice versa it is also quite possible that
all elements are within bounds while the whole thing is meaningless.  The
language should never take over or subvert decisions based on numerical
analysis.

[Tim Peters] 
> Ignoring ERANGE entirely is not at all the same behavior as 1.5.2, and
> current code certainly relies on detecting overflows in math functions. 

As Guido observed ERANGE is not generated with ieee, even for overflow.  So
it is the same behavior as 1.5.2.  Besides, no correct numerical code should
depend on exceptions like this unless the machine is incapable of handling
Inf and NaN.

Even in the cases where you do want to detect overflow, it is still wrong to
use exceptions.  Here's an example: x*log(x) approaches 0 as x approaches 0.
If x==0 then log(x)==-Inf but 0*-Inf==NaN, not what one would want.  But
exception is the wrong tool to hangle this, because if x is an array, some
of its element may be zero but other's may not.  The right way to do it is
something like

def entropy(probability):
  p = max(probability, 1e-323)
  return p*log(p)

[Tim Peters]
> In no case can you expect to see overflow ignored in 2.0.

You are proposing a dramatic change from the behavior of 1.5.2.  This looks
like to me to need a PEP and a big debate.  It would break a LOT of
numerical computations.

[Thomas Wouters]
> I remember the patch that did this, on SF. It was titled "don't link with
> -lieee if it isn't necessary" or something. Not sure what it would break,
> but mayhaps declaring -lieee necessary on glibc systems is the right fix ?
>
> (For the non-autoconf readers among us: the first snippet writes a test
> program to see if the function '__fpu_control' exists when linking with
> -lieee in addition to $LIBS, and if so, adds -lieee to $LIBS. The second
> snippet writes a test program to see if the function '__fpu_control'
> exists with the current collection of $LIBS. If it doesn't, it tries it
> again with -lieee,
>
> Pesonally, I think the patch should just be reversed... The comment above
> the check certainly could be read as 'Linux requires -lieee for correct
> f.p. operations', and perhaps that's how it was meant.

The patch as described seems to be based on flawed thinking.  The numbers
Inf and NaN are always necessary.  The -lieee could only be unnecessary if
the behavior is the same as IEEE.  Obviously it isn't.  So I second Thomas's
suggestion. 

[Tim Peters]
> If no progress is made on determining the true cause over the next few days,
> I'll hack mathmodule.c to ignore ERANGE in the specific case the result
> returned is a zero (which would "fix" your exp underflow problem without
> stopping overflow detection).  Since this will break code on any platform
> where errno was set to ERANGE on underflow in 1.5.2, I'll need to have a
> long discussion w/ Guido first.  I *believe* that much is actually sellable
> for 2.0, because it moves Python in a direction I know he likes regardless
> of whether he ever becomes a 754 True Believer.

[Guido van Rossum]
> No, the configure patch is right.  Tim will check in a change that
> treats ERANGE with a return value of 0.0 as underflow (returning 0.0,
> not raising OverflowError).

What is the reason to do this?  It looks like intetionally subverting ieee
even when it is available.  I thought Tim meant that only logistical
problems prevent using ieee.

If you do choose this route, please please please ignore ERANGE entirely,
whether return value is zero or not.

The only possible way that ERANGE could be useful at all is if it could be
set independently for each element of an array, and if it behave as a
warning instead of an exception, ie.  the calculation would continue if it
is not caught.  Well, then, Inf and NaN serve this purpose perfectly.

It is very reasonable to set errno in glibc for this; it is completely
unreasonable to raise an exception in Python, because exceptions cannot be
set to individual elements and they cannot be ignored.


Huaiyu
-- 
Huaiyu Zhu                       hzhu@users.sourceforge.net
Matrix for Python Project        http://MatPy.sourceforge.net 




From dubois@users.sourceforge.net  Thu Oct 12 01:04:51 2000
From: dubois@users.sourceforge.net (Paul F. Dubois)
Date: Wed, 11 Oct 2000 17:04:51 -0700
Subject: [Python-Dev] RE: [Numpy-discussion] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison)
In-Reply-To: <Pine.LNX.4.10.10010111510270.3131-100000@rocket.knowledgetrack.com>
Message-ID: <ADEOIFHFONCLEEPKCACCGEFHCBAA.pauldubois@home.com>

I don't have time to follow in detail this thread about changed behavior
between versions. These observations are based on working with hundreds of
code authors. I offer them as is.

a. Nobody runs a serious numeric calculation without setting
underflow-to-zero, in the hardware. You can't even afford the cost of
software checks. Unfortunately there is no portable way to do that that I
know of.

b. Some people use Inf but most people want the code to STOP so they can
find out where the INFS started. Otherwise, two hours later you have big
arrays of Infs and no idea how it happened. Likewise sqrt(-1.) needs to
stop, not put a zero and keep going.








From guido@python.org  Thu Oct 12 02:45:30 2000
From: guido@python.org (Guido van Rossum)
Date: Wed, 11 Oct 2000 20:45:30 -0500
Subject: [Python-Dev] RE: [Numpy-discussion] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison)
In-Reply-To: Your message of "Wed, 11 Oct 2000 17:04:51 MST."
 <ADEOIFHFONCLEEPKCACCGEFHCBAA.pauldubois@home.com>
References: <ADEOIFHFONCLEEPKCACCGEFHCBAA.pauldubois@home.com>
Message-ID: <200010120145.UAA02030@cj20424-a.reston1.va.home.com>

> I don't have time to follow in detail this thread about changed behavior
> between versions. These observations are based on working with hundreds of
> code authors. I offer them as is.
> 
> a. Nobody runs a serious numeric calculation without setting
> underflow-to-zero, in the hardware. You can't even afford the cost of
> software checks. Unfortunately there is no portable way to do that that I
> know of.
> 
> b. Some people use Inf but most people want the code to STOP so they can
> find out where the INFS started. Otherwise, two hours later you have big
> arrays of Infs and no idea how it happened. Likewise sqrt(-1.) needs to
> stop, not put a zero and keep going.

Thanks, Paul!  This behavior has always been what I wanted Python to
do (even though it's not always what Python did, depending on the
platform) and also what Tim's proposed patch will implement for the
specific case of math.exp() (and other math functions that may
underflow or overflow), on most reasonable platforms.

There are still lots of places where the platform gives Python no
choice of creating NaN and Inf, and because there's no
platform-independent way to test for these, they are hard to avoid in
some cases; but eventually, Tim will find a way to root them out.  And
for people like Huaiyu, who want to see Inf, there will (eventually)
be a way to select this as a run-time option; and ditto for whoever
might want underflow to raise an exception.

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


From huaiyu_zhu@yahoo.com  Thu Oct 12 03:22:54 2000
From: huaiyu_zhu@yahoo.com (Huaiyu Zhu)
Date: Wed, 11 Oct 2000 19:22:54 -0700 (PDT)
Subject: [Python-Dev] RE: [Numpy-discussion] RE: Possible bug (was Re:
 numpy, overflow, inf, ieee, and rich comparison)
In-Reply-To: <200010120145.UAA02030@cj20424-a.reston1.va.home.com>
Message-ID: <Pine.LNX.4.10.10010111833510.3385-100000@rocket.knowledgetrack.com>

[Paul Dubois]
> > 
> > a. Nobody runs a serious numeric calculation without setting
> > underflow-to-zero, in the hardware. You can't even afford the cost of
> > software checks. Unfortunately there is no portable way to do that that I
> > know of.

Amen.

> > 
> > b. Some people use Inf but most people want the code to STOP so they can
> > find out where the INFS started. Otherwise, two hours later you have big
> > arrays of Infs and no idea how it happened. Likewise sqrt(-1.) needs to
> > stop, not put a zero and keep going.

$ /usr/bin/python
Python 1.5.2 (#1, Sep 17 1999, 20:15:36)  [GCC egcs-2.91.66 19990314/Linux
(egcs- on linux-i386
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> from math import *
>>> exp(777)
inf
>>> exp(-777)
0.0
>>> sqrt(-1)
Traceback (innermost last):
  File "<stdin>", line 1, in ?
OverflowError: math range error

This was sane behavior.  Are we saying that Python 2.0 has invented
something better than IEEE 754?

[Guido van Rossum]

> Thanks, Paul!  This behavior has always been what I wanted Python to
> do (even though it's not always what Python did, depending on the
> platform) and also what Tim's proposed patch will implement for the
> specific case of math.exp() (and other math functions that may
> underflow or overflow), on most reasonable platforms.

Guido, with due respect to your decisions on Python issues, I simply have to
fight this one.  It is one thing to accomodate for naive users, but it is
another to dumb down every one else.

Case 1.  Someone writes a flawed numerical routine.  Two hours later he
finds his array filled with Inf and NaN.

Case 2.  Someone writes a perfect numerical routine.  Two hours later he
gets an exception, because the error is near zero.

Solution for case 1.  Use better algorithm.  Use better error control.
Raise exceptions when error is too large.  These are proper solutions.  
They are easy and efficient to implement.  They are needed anyway - If
something's wrong, you want to raise exceptions far earlier than Inf,
certainly before you get arrays filled with elements like 1e300.

Solution for case 2.  Almost impossible.  The division between under- and
over-flow is artificial.  What about 1/x or similar functions?  The only way
to work on such a platform is to abandon vectorized computation.

> There are still lots of places where the platform gives Python no
> choice of creating NaN and Inf, and because there's no
> platform-independent way to test for these, they are hard to avoid in
> some cases; but eventually, Tim will find a way to root them out.  And
> for people like Huaiyu, who want to see Inf, there will (eventually)
> be a way to select this as a run-time option; and ditto for whoever
> might want underflow to raise an exception.

I can understand that exceptions are the only available choices if IEEE is
not available.  But is there a compelling reason that Python should behave
"better" than IEEE when it's in fact available?

If the reason is to protect naive users, I can think of several responses:

1. For people doing one-off interactive work, returning Inf is in fact more
   informative. 

2. For users iterative numerical computations, they need to be educated
   about error control.  Otherwise they won't get corrent results anyway.

3. For really serious work, we could provide good numerical modules so that
   they don't need to write themselves.  To make this happen fast the fewer
   debacles like this one the better.

Case in point: Someone asked for regession modules two weeks ago.  I was
trying to convert my old matlab programs, which only took a few hours.  But
I wasted a week of (spare) time fighting for some mysterious "overflow".
Turns out that a Guassian is near zero when it's far from center, and Python
does not like it.

In practice, Inf may be generated more often as a proper value than by
mistake.

This is not an issue about whether someone "prefers" Inf or exception.  It
is about whether there is a choice to do proper computation.  Returning Inf
does not prevent someone to raise exception.  Raising exception
automatically prevents perfect algorithms to work properly.

As Kevin has volunteered to help with IEEE implementation and made a plan,
is there a strong reason to drop IEEE for Linux in 2.0?  If there is
insufficient time to carry out his plan, wouldn't it be prudent to keep
things as they were in 1.5.2?

Huaiyu



From tim_one@email.msn.com  Thu Oct 12 03:44:20 2000
From: tim_one@email.msn.com (Tim Peters)
Date: Wed, 11 Oct 2000 22:44:20 -0400
Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison)
In-Reply-To: <Pine.LNX.4.10.10010111510270.3131-100000@rocket.knowledgetrack.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCKENNHKAA.tim_one@email.msn.com>

[Huaiyu Zhu]
> On the issue of whether Python should ignore over/underflow on
> IEEE-enabled platforms:
>
> It can be argued that on IEEE enabled systems the proper thing to do for
> overflow is simply return Inf.  Raising exception is WRONG.  See below.

Python was not designed with IEEE-754 in mind, and *anything* that happens
wrt Infs, NaNs, and all other 754 features in Python is purely an accident
that can and does vary wildly across platforms.  And, as you've discovered
in this case, can vary wildly also across even a single library, depending
on config options.  We cannot consider this to be a bug since Python has had
no *intended* behavior whatsoever wrt 754 gimmicks.  We can and do consider
gripes about these accidents to be feature requests.

[Guido]
> Incidentally, math.exp(800) returns inf in 1.5, and raises
> OverflowError in 2.0.  So at least it's consistent.

[Huaiyu]
> That is not consistent at all.

Please read with an assumption of good faith.  Guido was pointing out that--
all in the specific case of gcc+glibc on Linux (these don't hold on other
platforms) --exp(800) returning Inf in 1.5 and OverflowError in 2.0 is
consistent *with* that exp(-800) returns 0 in 1.5 and raises an exception in
2.0.  He's right; indeed, he is in part agreeing with you.

[Guido
> 1.5.2 links with -lieee while 2.0 doesn't.  Removing -lieee from the
> 1.5.2 link line makes is raise OverflowError too.  Adding it to the
> 2.0 link line makes it return 0.0 for exp(-1000) and inf for
> exp(1000).

[Huaiyu]
> If using ieee is as simple as setting such a flag, there is no
> reason at all not to use it.

The patch to stop setting -lieee was contributed by a Python user who
claimed it fixed bugs on *their* platform.  That's "the reason".  We don't
want to screw them either.

> Here are some more examples:
> ...

I understand that 754 semantics can be invaluable.  So does Guido.  There's
no argument about that.  But Python doesn't yet support them, and wishing it
did doesn't make it so.  If linking with -lieee happens to give you the
semantics you want on your platform today, you're welcome to build with that
switch.  It appears to be a bad choice for *most* Python users, though (more
below), so we don't want to do it in the std 2.0 distro.

> ...
> In practice this simply means Python would not be suitable for numerical
> work at all.

Your biggest obstacle in getting Python support for 754 will in fact be
opposition from number-crunchers.  I've been slinging fp for 21 years, 15 of
those writing compilers and math libraries for "supercomputer" vendors.  754
is a Very Good Thing, but is Evil in subset form (see Kahan's (justified!)
vilification of Java on this point); ironically, 754 is hardest to sell to
those who could benefit from it the most.

> What about the other way round?  No problem.  It is easy to write
> functions like isNaN, isInf, etc.

It's easy for a platform expert to write such functions for their specific
platform of expertise, but it's impossible to write them in a portable way
before C99 is implemented (C99 requires that library suppliers provide them,
rendering the question moot).

> ...
> The language should never take over or subvert decisions based on
> numerical analysis.

Which is why a subset of 754 is evil.  754 requires that the user be able to
*choose* whether or not, e.g., overflow signals an exception.  Your crusade
to insist that it never raise an exception is as least as bad (I think it's
much worse) as Python's most common accidental behavior (where overflow from
libm usually raises an exception).  One size does not fit all.

[Tim]
> Ignoring ERANGE entirely is not at all the same behavior as 1.5.2, and
> current code certainly relies on detecting overflows in math functions.

[Huaiyu]
> As Guido observed ERANGE is not generated with ieee, even for
> overflow.  So it is the same behavior as 1.5.2.

You've got a bit of a case of tunnel vision here, Huaiyu.  Yes, in the
specific case of gcc+glibc+Linux, ignoring ERANGE returned from exp() is
what 1.5.2 acted like.  But you have not proposed to ignore it merely from
ERANGE returned from exp() in the specific case of gcc+glibc+Linux.  This
code runs on many dozens of platforms, and, e.g., as I suggested before, it
looks like HPUX has always set errno on both overflow and underflow.  MS
Windows sets it on overflow but not underflow.  Etc.  We have to worry about
the effects on all platforms.

> Besides, no correct numerical code should depend on exceptions like
> this unless the machine is incapable of handling Inf and NaN.

Nonsense.  754 provides the option to raise an exception on overflow, or
not, at the user's discretion, precisely because exceptions are sometimes
more appropriate than Infs of NaNs.  Kahan himself isn't happy with Infs and
NaNs because they're too often too gross a clue (see his writings on
"presubstitution" for a more useful approach).

[Tim]
> In no case can you expect to see overflow ignored in 2.0.

[Huaiyu]
> You are proposing a dramatic change from the behavior of 1.5.2.
> This looks like to me to need a PEP and a big debate.  It would break
> a LOT of numerical computations.

I personally doubt that, but realize it may be true.  That's why he have
beta releases.  So far yours is the only feedback we've heard (thanks!), and
as a result we're going to change 2.0 to stop griping about underflow, and
do so in a way that will actually work across all platforms.  We're probably
going to break some HPUX programs as a result; but they were relying on
accidents too.

[Guido]
> No, the configure patch is right.  Tim will check in a change that
> treats ERANGE with a return value of 0.0 as underflow (returning 0.0,
> not raising OverflowError).

[Huaiyu]
> What is the reason to do this?  It looks like intetionally subverting
> ieee even when it is available.  I thought Tim meant that only logistical
> problems prevent using ieee.

Python does not support 754 today.  Period.  I would like it to, but not in
any half-assed, still platform-dependent, still random crap-shoot, still
random subset of 754 features, still rigidly inflexible, way.  When it does
support it, Guido & I will argue that it should enable (what 754 calls) the
overflow, divide-by-0 and invalid operation exceptions by default, and
disable the underflow and inexact exceptions by default.  This ensures that,
under the default, an infinity or NaN can never be created from
non-exceptional inputs without triggering an exception. Not only is that
best for newbies, you'll find it's the *only* scheme for a default that can
be sold to working number-crunchers (been there, done that, at Kendall
Square Research).  It also matches Guido's original, pre-754, *intent* for
how Python numerics should work by default (it is, e.g., no accident that
Python has always had an OverflowError exception but never an UnderflowError
one).

And that corresponds to the change Guido says <wink> I'm going to make in
mathmodule.c:  suppress complaints about underflow, but let complaints about
overflow go through.  This is not a solution, it's a step on a path towards
a solution.  The next step (which will not happen for 2.0!) is to provide an
explicit way to, from Python, disable overflow checking, and that's simply
part of providing the control and inquiry functions mandated by 754.  Then
code that would rather deal with Infs than exceptions can, at its explicit
discretion.

> If you do choose this route, please please please ignore ERANGE entirely,
> whether return value is zero or not.

It should be clear that isn't going to happen.  I realize that triggering
overflow is going to piss you off, but you have to realize that not
triggering overflow is going to piss more people off, and *especially* your
fellow number-crunchers.  Short of serious 754 support, picking "a winner"
is the best we can do for now.  You have the -lieee flag on your platform du
jour if you can't bear it.

[Paul Dubois]
> I don't have time to follow in detail this thread about changed behavior
> between versions.

What makes you think we do <0.5 wink>?

> These observations are based on working with hundreds of code authors. I
> offer them as is.

FWIW, they exactly match my observations from 15 years on the HW vendor
side.

> a. Nobody runs a serious numeric calculation without setting underflow-to-
> zero, in the hardware. You can't even afford the cost of software checks.
> Unfortunately there is no portable way to do that that I know of.

C allows libm implementations a lot of discretion in whether to set errno to
ERANGE in case of underflow.  The change we're going to make is to ignore
ERANGE in case of underflow, ensuring that math.* functions will *stop*
raising underflow exceptions on all platforms (they'll return a zero
instead; whether +0 or -0 will remain a platform-dependent crap shoot for
now).  Nothing here addresses underflow exceptions that may be raised by fp
hardware, though; this has solely to do with the platform libm's treatment
of errno.

So in this respect, we're removing Python's current unpredictability, and in
the way you favor.

> b. Some people use Inf but most people want the code to STOP so they can
> find out where the INFS started. Otherwise, two hours later you have big
> arrays of Infs and no idea how it happened.

Apparently Python on libc+glibc+Linux never raised OverflowError from math.*
functions in 1.5.2 (although it did on most other platforms I know about).
A patch checked in to fix some other complaint on some other Unixish
platform had the side-effect of making Python on libc+glibc+Linux start
raising OverflowError from math.* functions in 2.0, but in both overflow and
underflow cases.  We intend to (as above) suppress the underflow exceptions,
but let the overflow cases continue to raise OverflowError.  Huaiyu's
original complaint was about the underflow cases, but (as such things often
do) expanded beyond that when it became clear he would get what he asked for
<wink>.

Again we're removing Python's current unpredictability, and again in the way
you favor -- although this one is still at the mercy of whether the platform
libm sets errno correctly on overflow (but it seems that most do these
days).

> Likewise sqrt(-1.) needs to stop, not put a zero and keep going.

Nobody has proposed changing anything about libm domain (as opposed to
range) errors (although Huaiyu probably should if he's serious about his
flavor of 754 subsetism -- I have no idea what gcc+glibc+Linux did here on
1.5.2, but it *should* have silently returned a NaN (not a zero) without
setting errno if it was *self*-consistent -- anyone care to check that
under -lieee?:

    import math
    math.sqrt(-1)

NaN or ValueError?  2.0 should raise ValueError regardless of what 1.5.2 did
here.).

just-another-day-of-universal-python-harmony-ly y'rs  - tim




From sdm7g@virginia.edu  Thu Oct 12 04:23:32 2000
From: sdm7g@virginia.edu (Steven D. Majewski)
Date: Wed, 11 Oct 2000 23:23:32 -0400 (EDT)
Subject: [Python-Dev] RE: [Numpy-discussion] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison)
In-Reply-To: <Pine.LNX.4.10.10010111833510.3385-100000@rocket.knowledgetrack.com>
Message-ID: <Pine.A32.3.90.1001011225636.4671B-100000@elvis.med.Virginia.EDU>


First: I haven't followed this thread from the beginning -- only the
last ten or so posts. 

Second: One reason I didn't follow it from the start is that I'm not
doing any heavy numerical stuff in Python. I've been using Lisp for
that, and use Python more for string/symbolic or GUI hacking. 

But, if I was going to do the sort of numerical stuff I now do in 
Lisp in Python, I would agree with Huaiya Zhu. I do a lot of 
vectorized operations on what are often independent samples. 
If some of the numbers overflow or underflow, that just represents
an outlier or bad sample. I don't want it to blow off the whole
pipeline of operations on the other data points in the vector -- 
they are independent of the bad points. 

 In my case, it's not that these are lengthy calculations. It's
that they are interactive and tied to immediate graphical 
representations. If there are strange zero's or infinities in
the result, there is (or should be) a way to backtrack and 
investigate. ( That's why people want interactive and graphical
regression analysis and modeling tools! ) 

 The idea that your calculation should blow up and you should 
check it and resubmit your job sounds just so ancient-20th-century-
Fortran-JCL-and-punched-cards-technology! 
 

---|  Steven D. Majewski   (804-982-0831)  <sdm7g@Virginia.EDU>  |---
---|  Department of Molecular Physiology and Biological Physics  |---
---|  University of Virginia             Health Sciences Center  |---
---|  P.O. Box 10011            Charlottesville, VA  22906-0011  |---
		"All operating systems want to be unix, 
		 All programming languages want to be lisp." 



From tim_one@email.msn.com  Thu Oct 12 05:18:19 2000
From: tim_one@email.msn.com (Tim Peters)
Date: Thu, 12 Oct 2000 00:18:19 -0400
Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison)
In-Reply-To: <20001011234038.A2322@better.net>
Message-ID: <LNBBLJKPBEHFEDALKOLCKEOFHKAA.tim_one@email.msn.com>

[William Park]
> On Wed, Oct 11, 2000 at 10:44:20PM -0400, Tim Peters wrote:
> > > Likewise sqrt(-1.) needs to stop, not put a zero and keep going.

I didn't write that.  Paul Dubois did.

> Hmm... I don't like this.  It should stop or return complex.

Paul said it should stop.  You said it should stop (or return complex).  So
what is it that you don't like <wink/frown>?  754 mandates that sqrt(x) for
x<0 return a NaN and keep going (by default) -- which even Huaiyu apparently
doesn't like.

[actually Tim]
> I have no idea what gcc+glibc+Linux  did here on 1.5.2, but it *should*
> have silently returned a NaN (not a zero) without setting errno if it
> was *self*-consistent -- anyone care to check that under -lieee?:
>
>      import math
>      math.sqrt(-1)
>
> NaN or ValueError?  2.0 should raise ValueError regardless of
> what 1.5.2 did here.).

[back to William]
> It returns 'OverflowError: math range error' in 1.5.2,

Ah, that's hilarious <wink>!  It's tempting to believe that glibc is
violating the IEEE std despite the -lieee flag in this case, but I don't
believe that's true:  it's almost certainly the case that glibc is actually
returning a NaN, *not* setting errno at all, and this other check in
Python's mathmodule.c:

#define CHECK(x) if (errno != 0) ; \
	else if (-HUGE_VAL <= (x) && (x) <= HUGE_VAL) ; \
	else errno = ERANGE

is setting errno to ERANGE purely due to an accident of the way gcc happens
to compile code for comparing NaN to Inf and -Inf.

> and 'ValueError: math domain error' in 2.0.

Which is the correct exception, so is another reason for Python to
avoid -lieee in 2.0.

will-be-easier-to-make-it-work-right-by-design-than-to-keep-doping-out-
    what-happens-by-accident-now-ly y'rs  - tim




From tim_one@email.msn.com  Thu Oct 12 07:16:23 2000
From: tim_one@email.msn.com (Tim Peters)
Date: Thu, 12 Oct 2000 02:16:23 -0400
Subject: [Python-Dev] RE: [Numpy-discussion] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison)
In-Reply-To: <Pine.LNX.4.10.10010111833510.3385-100000@rocket.knowledgetrack.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCEEOHHKAA.tim_one@email.msn.com>

[Huaiyu Zhu]
> ...
> $ /usr/bin/python
> Python 1.5.2 (#1, Sep 17 1999, 20:15:36)  [GCC egcs-2.91.66 19990314/Linux
> (egcs- on linux-i386
> Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
> >>> from math import *
> >>> exp(777)
> inf
> >>> exp(-777)
> 0.0
> >>> sqrt(-1)
> Traceback (innermost last):
>   File "<stdin>", line 1, in ?
> OverflowError: math range error
>
> This was sane behavior.  Are we saying that Python 2.0 has invented
> something better than IEEE 754?

754 allows users to choose the behaviors they want.  Any *fixed* policy is
not 754.  So long as we have to fix a single policy, yes, I believe Guido (&
know I) would say that raising OverflowError on exp(777), and silently
returning 0 on exp(-777), and raising ValueError on sqrt(-1) (*not*
OverflowError, as shown above), is indeed better than the 754 default
behaviors.  And 2.0 will do all three of those (& I just checked in the code
to make that happen).

About the sqrt example above, that's neither 754 behavior nor sane behavior:
default 754 behavior on sqrt(-1) is to return a NaN and keep on going.  I'm
pretty sure that's what glibc linked w/ -lieee actually does, too (if it
doesn't, glibc -lieee is violating 754).  That 1.5.2 raised an OverflowError
instead is insane, and appears purely due to an accident of how gcc compiles
code to compare Infs to NaNs (Python's mathmodule.c's CHECK() macro was
fooled by this into setting errno to ERANGE itself).  Python should raise a
ValueError there instead (corresponding to libm setting errno to EDOM --
this is a domain error, not a range error) -- which it does now under CVS
Python.

754-doesn't-work-unless-you've-got-all-of-it-ly y'rs  - tim




From thomas@xs4all.net  Thu Oct 12 09:11:57 2000
From: thomas@xs4all.net (Thomas Wouters)
Date: Thu, 12 Oct 2000 10:11:57 +0200
Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison)
In-Reply-To: <LNBBLJKPBEHFEDALKOLCKENNHKAA.tim_one@email.msn.com>; from tim_one@email.msn.com on Wed, Oct 11, 2000 at 10:44:20PM -0400
References: <Pine.LNX.4.10.10010111510270.3131-100000@rocket.knowledgetrack.com> <LNBBLJKPBEHFEDALKOLCKENNHKAA.tim_one@email.msn.com>
Message-ID: <20001012101157.Y12812@xs4all.nl>

On Wed, Oct 11, 2000 at 10:44:20PM -0400, Tim Peters wrote:

> > Likewise sqrt(-1.) needs to stop, not put a zero and keep going.

> Nobody has proposed changing anything about libm domain (as opposed to
> range) errors (although Huaiyu probably should if he's serious about his
> flavor of 754 subsetism -- I have no idea what gcc+glibc+Linux did here on
> 1.5.2, but it *should* have silently returned a NaN (not a zero) without
> setting errno if it was *self*-consistent -- anyone care to check that
> under -lieee?:

>     import math
>     math.sqrt(-1)

>>> import math
>>> math.sqrt(-1)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
OverflowError: math range error

The same under both 1.5.2 and 2.0c1 with -lieee. Without -lieee, both do:

>>> import math
>>> math.sqrt(-1)
Traceback (innermost last):
  File "<stdin>", line 1, in ?
ValueError: math domain error

Consistency-conschmistency-ly y'rs,

-- 
Thomas Wouters <thomas@xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!


From jeremy@beopen.com  Thu Oct 12 16:58:10 2000
From: jeremy@beopen.com (Jeremy Hylton)
Date: Thu, 12 Oct 2000 11:58:10 -0400 (EDT)
Subject: [Python-Dev] (no subject)
Message-ID: <14821.57234.444047.511672@bitdiddle.concentric.net>

Cc xml-sig@python.org
Subject: test_minidom non-failure failure?
X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid
Reply-To: jeremy@beopen.com
Comments: Hyperbole mail buttons accepted, v04.18.

SSBqdXN0IHJhbiAnbWFrZSB0ZXN0JyBhZ2FpbnN0IGEgY2xlYW4gY29weSBvZiB0aGUgQ1ZT
IHRyZWUgYW5kIGdvdCBhbg0KZW5vcm1vdXMgYW1vdW50IG9mIGdhcmJhZ2Ugb3V0cHV0IGZy
b20gdGVzdF9taW5pZG9tLCBhbHRob3VnaCBpdCB3YXMNCm5vdCByZXBvcnRlZCBhcyBhIHRl
c3QgdGhlIGZhaWxlZCBvciB3YXMgc2tpcHBlZC4NCg0KVGhlIG91dHB1dCBmcm9tIHRlc3Rf
bWluaWRvbSBzdGFydGVkIHRoaXMgd2F5Og0KDQp0ZXN0X21pbmlkb20NCmdhcmJhZ2U6IFt7
J25vZGVWYWx1ZSc6IHUnT2Jzb2xldGUgYnV0IGltcGxlbWVudGVkLi4uJywgJ25leHRTaWJs
aW5nJzogPERPTSBUZXh0IG5vZGUgIlwwMTIiPiwgJ2NoaWxkTm9kZXMnOiBOb25lLCAnYXR0
cmlidXRlcyc6IE5vbmUsICdwYXJlbnROb2RlJzogTm9uZSwgJ2RhdGEnOiB1J09ic29sZXRl
IGJ1dCBpbXBsZW1lbnRlZC4uLicsICdwcmV2aW91c1NpYmxpbmcnOiBOb25lfSwgPERPTSBU
ZXh0IG5vZGUgIk9ic29sZXRlIGIuLi4iPiwgeydub2RlVmFsdWUnOiB1J1wwMTInLCAnbmV4
dFNpYmxpbmcnOiBOb25lLCAnY2hpbGROb2Rlcyc6IE5vbmUsICdhdHRyaWJ1dGVzJzogTm9u
ZSwgJ3BhcmVudE5vZGUnOiBOb25lLCAnZGF0YSc6IHUnXDAxMicsICdwcmV2aW91c1NpYmxp
bmcnOiA8RE9NIFRleHQgbm9kZSAiT2Jzb2xldGUgYi4uLiI+fSwgPERPTSBUZXh0IG5vZGUg
IlwwMTIiPiwgeydub2RlVmFsdWUnOiB1J09ic29sZXRlIGJ1dCBpbXBsZW1lbnRlZC4uLics
ICduZXh0U2libGluZyc6IDxET00gVGV4dCBub2RlICJcMDEyIj4sICdjaGlsZE5vZGVzJzog
Tm9uZSwgJ2F0dHJpYnV0ZXMnOiBOb25lLCAncGFyZW50Tm9kZSc6IE5vbmUsICdkYXRhJzog
dSdPYnNvbGV0ZSBidXQgaW1wbGVtZW50ZWQuLi4nLCAncHJldmlvdXNTaWJsaW5nJzogTm9u
ZX0sIDxET00gVGV4dCBub2RlICJPYnNvbGV0ZSBiLi4uIj4sIHsnbm9kZVZhbHVlJzogdSdc
MDEyJywgJ25leHRTaWJsaW5nJzogTm9uZSwgJ2NoaWxkTm9kZXMnOiBOb25lLCAnYXR0cmli
dXRlcyc6IE5vbmUsICdwYXJlbnROb2RlJzogTm9uZSwgJ2RhdGEnOiB1J1wwMTInLCAncHJl
dmlvdXNTaWJsaW5nJzogPERPTSBUZXh0IG5vZGUgIk9ic29sZXRlIGIuLi4iPn0sIDxET00g
VGV4dCBub2RlICJcMDEyIj4sIHsnbm9kZVZhbHVlJzogdSdPYnNvbGV0ZSBidXQgaW1wbGVt
ZW50ZWQuLi4nLCAnbmV4dFNpYmxpbmcnOiA8RE9NIFRleHQgbm9kZSAiXDAxMiI+LCAnY2hp
bGROb2Rlcyc6IE5vbmUsICdhdHRyaWJ1dGVzJzogTm9uZSwgJ3BhcmVudE5vZGUnOiBOb25l
LCAnZGF0YSc6IHUnT2Jzb2xldGUgYnV0IGltcGxlbWVudGVkLi4uJywgJ3ByZXZpb3VzU2li
bGluZyc6IE5vbmV9LCA8RE9NIFRleHQgbm9kZSAiT2Jzb2xldGUgYi4uLiI+LCB7J25vZGVW
YWx1ZSc6IHUnXDAxMicsICduZXh0U2libGluZyc6IE5vbmUsICdjaGlsZE5vZGVzJzogTm9u
ZSwgJ2F0dHJpYnV0ZXMnOiBOb25lLCAncGFyZW50Tm9kZSc6IE5vbmUsICdkYXRhJzogdSdc
MDEyJywgJ3ByZXZpb3VzU2libGluZyc6IDxET00gVGV4dCBub2RlICJPYnNvbGV0ZSBiLi4u
Ij59LCA8RE9NIFRleHQgbm9kZSAiXDAxMiI+LCB7J25vZGVWYWx1ZSc6ICd0ZXh0JywgJ25l
eHRTaWJsaW5nJzogPERPTSBFbGVtZW50OiBzdWJlbG0gYXQgMTM3ODYzMzg4PiwgJ2NoaWxk
Tm9kZXMnOiBOb25lLCAnYXR0cmlidXRlcyc6IE5vbmUsICdwYXJlbnROb2RlJzogTm9uZSwg
J2RhdGEnOiAndGV4dCcsICdwcmV2aW91c1NpYmxpbmcnOiBOb25lfSwgPERPTSBUZXh0IG5v
ZGUgInRleHQiPiwgeydfYXR0cnMnOiB7fSwgJ3ByZXZpb3VzU2libGluZyc6IDxET00gVGV4
dCBub2RlICJ0ZXh0Ij4sICdjaGlsZE5vZGVzJzogTm9uZSwgJ2xvY2FsTmFtZSc6ICdzdWJl
bG0nLCAndGFnTmFtZSc6ICdzdWJlbG0nLCAnX2F0dHJzTlMnOiB7fSwgJ3ByZWZpeCc6ICcn
LCAnbmFtZXNwYWNlVVJJJzogJycsICdub2RlVmFsdWUnOiBOb25lLCAnbmV4dFNpYmxpbmcn
OiA8RE9NIFRleHQgbm9kZSAidGV4dCI+LCAncGFyZW50Tm9kZSc6IE5vbmUsICdub2RlTmFt
ZSc6ICdzdWJlbG0nfSwgPERPTSBFbGVtZW50OiBzdWJlbG0gYXQgMTM3ODYzMzg4Piwge30s
IHt9LCB7J25vZGVWYWx1ZSc6ICd0ZXh0JywgJ25leHRTaWJsaW5nJzogTm9uZSwgJ2NoaWxk
Tm9kZXMnOiBOb25lLCAnYXR0cmlidXRlcyc6IE5vbmUsICdwYXJlbnROb2RlJzogTm9uZSwg
J2RhdGEnOiAndGV4dCcsICdwcmV2aW91c1NpYmxpbmcnOiA8RE9NIEVsZW1lbnQ6IHN1YmVs
bSBhdCAxMzc4NjMzODg+fSwgPERPTSBUZXh0IG5vZGUgInRleHQiPiwgeydub2RlVmFsdWUn
OiB1J09ic29sZXRlIGJ1dCANCg0KSXQgY29udGludWVkIG9uIGluIHRoZSBzYW1lIGZhc2hp
b24gZm9yIGFib3V0IGEgdGhvdXNhbmQgbGluZXMuICBBZnRlcg0KcHJpbnRpbmcgYWxsIHRo
aXMgZ2FyYmFnZSwgaXQgY29udGludWVkIG9uIHRvIHRlc3RfbW1hcC4NCg0KVGhlIGZpbmFs
IHRlc3QgcmVwb3J0IHdhczoNCg0KOTUgdGVzdHMgT0suDQoxMyB0ZXN0cyBza2lwcGVkOiB0
ZXN0X2FsIHRlc3RfY2QgdGVzdF9jbCB0ZXN0X2RibSB0ZXN0X2RsIHRlc3RfZ2wNCnRlc3Rf
aW1nZmlsZSB0ZXN0X2xhcmdlZmlsZSB0ZXN0X25pcyB0ZXN0X3N1bmF1ZGlvZGV2IHRlc3Rf
dGltaW5nDQp0ZXN0X3dpbnJlZyB0ZXN0X3dpbnNvdW5kDQoNCkFueSBpZGVhcyBhYm91dCB3
aGF0IHdlbnQgd3Jvbmc/DQoNCkplcmVteQ==


From jeremy@beopen.com  Thu Oct 12 17:11:53 2000
From: jeremy@beopen.com (Jeremy Hylton)
Date: Thu, 12 Oct 2000 12:11:53 -0400 (EDT)
Subject: [Python-Dev] test_minidom non-failure failure? (take 2)
Message-ID: <14821.58057.358947.271778@bitdiddle.concentric.net>

Sorry about the previous message; a mail munger somewhere between my
display and python.org choked on a very long line...

I am getting an occasional, hard-to-reproduce error in test_minidom.
When I run the test, it displays about a thousand lines of garbage,
but the test suite does not report test_minidom as failed or skipped.

The output I see during the test run is this:

test_minidom
garbage: [{'nodeValue': u'Obsolete but implemented...', 'nextSibling':
<DOM Text node "\012">, 'childNodes': None, 'attributes': None,
'parentNode': None, 'data': u'Obsolete but implemented...',
'previousSibling': None}, <DOM Text node "Obsolete b...">,
{'nodeValue': u'\012', 'nextSibling': None, 'childNodes': None, 'a 
[... many hundreds of lines omitted]

At the end of the test, I get a pretty normal result:
95 tests OK.
13 tests skipped: test_al test_cd test_cl test_dbm test_dl test_gl
test_imgfile test_largefile test_nis test_sunaudiodev test_timing
test_winreg test_winsound 

So two questions:

Why is test_minidom producing all this output?  And why is it only
happening intermittently?

Why does regrtest.py think that test_minidom is working correctly when
it produces all this output?

Jeremy



From nas@arctrix.com  Thu Oct 12 10:31:34 2000
From: nas@arctrix.com (Neil Schemenauer)
Date: Thu, 12 Oct 2000 02:31:34 -0700
Subject: [Python-Dev] test_minidom non-failure failure? (take 2)
In-Reply-To: <14821.58057.358947.271778@bitdiddle.concentric.net>; from jeremy@beopen.com on Thu, Oct 12, 2000 at 12:11:53PM -0400
References: <14821.58057.358947.271778@bitdiddle.concentric.net>
Message-ID: <20001012023134.A18254@glacier.fnational.com>

On Thu, Oct 12, 2000 at 12:11:53PM -0400, Jeremy Hylton wrote:
> I am getting an occasional, hard-to-reproduce error in test_minidom.
> When I run the test, it displays about a thousand lines of garbage,
> but the test suite does not report test_minidom as failed or skipped.
> 
> The output I see during the test run is this:
> 
> test_minidom
> garbage: [{'nodeValue': u'Obsolete but implemented...', 'nextSibling':

This is most likely the garbage collector.  regrtest.py contains
the following code:

        if findleaks:
            gc.collect()
            if gc.garbage:
                print "garbage:", repr(gc.garbage)
                found_garbage.extend(gc.garbage)
                del gc.garbage[:]

findleaks is true if the -l option is specified (TESTOPS in the
makefile includes it).  Something is producing cyclic garbage.

  Neil


From guido@python.org  Thu Oct 12 18:39:40 2000
From: guido@python.org (Guido van Rossum)
Date: Thu, 12 Oct 2000 12:39:40 -0500
Subject: [Python-Dev] test_minidom non-failure failure? (take 2)
In-Reply-To: Your message of "Thu, 12 Oct 2000 02:31:34 MST."
 <20001012023134.A18254@glacier.fnational.com>
References: <14821.58057.358947.271778@bitdiddle.concentric.net>
 <20001012023134.A18254@glacier.fnational.com>
Message-ID: <200010121739.MAA07968@cj20424-a.reston1.va.home.com>

> On Thu, Oct 12, 2000 at 12:11:53PM -0400, Jeremy Hylton wrote:
> > I am getting an occasional, hard-to-reproduce error in test_minidom.
> > When I run the test, it displays about a thousand lines of garbage,
> > but the test suite does not report test_minidom as failed or skipped.
> > 
> > The output I see during the test run is this:
> > 
> > test_minidom
> > garbage: [{'nodeValue': u'Obsolete but implemented...', 'nextSibling':

[Neil]
> This is most likely the garbage collector.  regrtest.py contains
> the following code:
> 
>         if findleaks:
>             gc.collect()
>             if gc.garbage:
>                 print "garbage:", repr(gc.garbage)
>                 found_garbage.extend(gc.garbage)
>                 del gc.garbage[:]
> 
> findleaks is true if the -l option is specified (TESTOPS in the
> makefile includes it).  Something is producing cyclic garbage.

Of course something is producing cyclic garbage!

The DOM tree is full of parent and child links.

Does this output mean that the GC works correctly?  Or does it mean
that there is a reason why this garbage cannot be disposed of?

In the latter case, could that be because there are __del__ methods?

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


From fdrake@beopen.com  Thu Oct 12 17:55:19 2000
From: fdrake@beopen.com (Fred L. Drake, Jr.)
Date: Thu, 12 Oct 2000 12:55:19 -0400 (EDT)
Subject: [Python-Dev] test_minidom non-failure failure? (take 2)
In-Reply-To: <20001012023134.A18254@glacier.fnational.com>
References: <14821.58057.358947.271778@bitdiddle.concentric.net>
 <20001012023134.A18254@glacier.fnational.com>
Message-ID: <14821.60663.213246.179325@cj42289-a.reston1.va.home.com>

Neil Schemenauer writes:
 > This is most likely the garbage collector.  regrtest.py contains
 > the following code:
...
 > findleaks is true if the -l option is specified (TESTOPS in the
 > makefile includes it).  Something is producing cyclic garbage.

  This is definately the problem.
  Lars, Paul:  This looks like a problem in the unlink() method of the
DOM.  Could you please check that the unlink() method is updated to
handle the latest version of the other changes?
  Thanks!


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member



From fdrake@beopen.com  Thu Oct 12 17:59:33 2000
From: fdrake@beopen.com (Fred L. Drake, Jr.)
Date: Thu, 12 Oct 2000 12:59:33 -0400 (EDT)
Subject: [Python-Dev] test_minidom non-failure failure? (take 2)
In-Reply-To: <14821.58057.358947.271778@bitdiddle.concentric.net>
References: <14821.58057.358947.271778@bitdiddle.concentric.net>
Message-ID: <14821.60917.429141.652655@cj42289-a.reston1.va.home.com>

Jeremy Hylton writes:
 > Why is test_minidom producing all this output?  And why is it only
 > happening intermittently?

  It isn't.  See Neil's excellent explanation.

 > Why does regrtest.py think that test_minidom is working correctly when
 > it produces all this output?

  The test is passing just fine, and is complete before the test for
garbage is performed.  The unlink() method on DOM objects is the
culprit; it is updating the Node.allnodes dictionary correctly, but
not the Node instances.  I've already asked Paul & Lars to fix this;
it should work just fine with or without GC once they've seen the
report.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member



From nas@arctrix.com  Thu Oct 12 11:24:48 2000
From: nas@arctrix.com (Neil Schemenauer)
Date: Thu, 12 Oct 2000 03:24:48 -0700
Subject: [Python-Dev] test_minidom non-failure failure? (take 2)
In-Reply-To: <200010121739.MAA07968@cj20424-a.reston1.va.home.com>; from guido@python.org on Thu, Oct 12, 2000 at 12:39:40PM -0500
References: <14821.58057.358947.271778@bitdiddle.concentric.net> <20001012023134.A18254@glacier.fnational.com> <200010121739.MAA07968@cj20424-a.reston1.va.home.com>
Message-ID: <20001012032448.A18407@glacier.fnational.com>

On Thu, Oct 12, 2000 at 12:39:40PM -0500, Guido van Rossum wrote:
> Of course something is producing cyclic garbage!
> 
> The DOM tree is full of parent and child links.
> 
> Does this output mean that the GC works correctly?  Or does it
> mean that there is a reason why this garbage cannot be disposed
> of?  In the latter case, could that be because there are
> __del__ methods?

The -l option tries to find any cyclic garbage produced by the
tests.  I don't think that that option should be enabled default.
The output means that the GC is working and is finding stuff that
would not be freed by reference counting alone.  

I can't tell if the GC would free this garbage.  The -l option
sets the DEBUG_SAVEALL option which causes all garbage found to
end up in gc.garbage, not just garbage the can't be cleaned up.

I don't have pyexpat installed here so I can't test it.  If you
want to find out if test_minidom is creating garbage the
collector can't free you should comment out the:

    gc.set_debug(gc.DEBUG_SAVEALL)

line in regrtest.py and run:

    regrtest.py -l test_minidom

If that does what I think it does and you still get the "garbage: "
line then the test is creating evil things.  :)

  Neil


From hinsen@dirac.cnrs-orleans.fr  Thu Oct 12 18:24:18 2000
From: hinsen@dirac.cnrs-orleans.fr (hinsen@dirac.cnrs-orleans.fr)
Date: Thu, 12 Oct 2000 19:24:18 +0200
Subject: [Python-Dev] RE: [Numpy-discussion] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison)
In-Reply-To: <Pine.A32.3.90.1001011225636.4671B-100000@elvis.med.Virginia.EDU>
 (sdm7g@virginia.edu)
References: <Pine.A32.3.90.1001011225636.4671B-100000@elvis.med.Virginia.EDU>
Message-ID: <200010121724.TAA15487@chinon.cnrs-orleans.fr>

>  The idea that your calculation should blow up and you should 
> check it and resubmit your job sounds just so ancient-20th-century-
> Fortran-JCL-and-punched-cards-technology! 

Long-running jobs are still with us, even there's neither Fortran nor
JCL in them. And for these applications, stopping is better than going
on with nonsense values. On the other hand, as you point out, exceptions
for math errors are a bit of a pain for interactive work.

So how about making this a run-time option? I'd choose exceptions by
default and Infs and Nans by specifying a command-line option, but
there are certainly others who would prefer it the other way round.
What matters most to me is that the choice is possible somehow.

Konrad.
-- 
-------------------------------------------------------------------------------
Konrad Hinsen                            | E-Mail: hinsen@cnrs-orleans.fr
Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24
Rue Charles Sadron                       | Fax:  +33-2.38.63.15.17
45071 Orleans Cedex 2                    | Deutsch/Esperanto/English/
France                                   | Nederlands/Francais
-------------------------------------------------------------------------------


From sdm7g@virginia.edu  Thu Oct 12 19:25:44 2000
From: sdm7g@virginia.edu (Steven D. Majewski)
Date: Thu, 12 Oct 2000 14:25:44 -0400 (EDT)
Subject: [Python-Dev] RE: [Numpy-discussion] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison)
In-Reply-To: <200010121724.TAA15487@chinon.cnrs-orleans.fr>
Message-ID: <Pine.A32.3.90.1001012140201.14856A-100000@elvis.med.Virginia.EDU>


On Thu, 12 Oct 2000 hinsen@dirac.cnrs-orleans.fr wrote:

> >  The idea that your calculation should blow up and you should 
> > check it and resubmit your job sounds just so ancient-20th-century-
> > Fortran-JCL-and-punched-cards-technology! 
> 
> Long-running jobs are still with us, even there's neither Fortran nor
> JCL in them. And for these applications, stopping is better than going
> on with nonsense values. On the other hand, as you point out, exceptions
> for math errors are a bit of a pain for interactive work.
> 
> So how about making this a run-time option? I'd choose exceptions by
> default and Infs and Nans by specifying a command-line option, but
> there are certainly others who would prefer it the other way round.
> What matters most to me is that the choice is possible somehow.
> 

I agree entirely! 
Maybe I was being a bit too glib, but I didn't mean to imply that
wanting it to halt or throw an exception on errors is wrongheaded.

I just wanted to make sure the counter-case to what Paul was saying
also got heard: Yes-- underflows  or infinities  where they aren't 
expected are usually a sign that something is very wrong somewhere.
But in the case where the vector holds independent observations or
data points, then usually what it means is that there's something
wrong with *that* data point -- miscallibrated or mislabeled -- but
no reason not to complete the calculations for all of the other
points. 

Scaling or doing projections for interactive graphics is another
case where bad points are often better than throwing an exception.
( And it's a pain to have to remember to lambda wrap all the function
calls with some sort of guard when you'ld be happy to get NaNs. ) 

I also mostly agree with Tim, except that I'm not sure that bad or
incomplete ieee support is always better than none at all.

---|  Steven D. Majewski   (804-982-0831)  <sdm7g@Virginia.EDU>  |---
---|  Department of Molecular Physiology and Biological Physics  |---
---|  University of Virginia             Health Sciences Center  |---
---|  P.O. Box 10011            Charlottesville, VA  22906-0011  |---
		"All operating systems want to be unix, 
		 All programming languages want to be lisp." 



From thomas@xs4all.net  Thu Oct 12 20:14:37 2000
From: thomas@xs4all.net (Thomas Wouters)
Date: Thu, 12 Oct 2000 21:14:37 +0200
Subject: [Python-Dev] Re: getopt() prototype [was: checkin-message of something or other]
In-Reply-To: <200010121711.KAA00584@slayer.i.sourceforge.net>; from fdrake@users.sourceforge.net on Thu, Oct 12, 2000 at 10:11:41AM -0700
References: <200010121711.KAA00584@slayer.i.sourceforge.net>
Message-ID: <20001012211436.Z12812@xs4all.nl>

On Thu, Oct 12, 2000 at 10:11:41AM -0700, Fred L. Drake wrote:

[ use -Wall and -Wstrict-prototypes by default, if the compiler is gcc ]

> There is one known warning at this time, caught by the -Wstrict-prototypes
> option.  In Modules/main.c, the declaration of getopt() without parameters
> gets a complaint (rightly) that it is not a proper prototype.  The lack of
> a complete prototype information should be corrected when the right
> portability conditions have been identified.

I already looked at this before, and the problem is that the prototype for
getopt is not portable (because of quirks in the ANSI C standard regarding
'compatible' pointer types.) Some systems define it as 'const char **' (or
'char const **'), some perhaps as 'char **', and some as 'char * const *'.
'const char **' and 'char const **' are the same, but 'char * const *' is
something else, and so is 'char **'. 'char * const *' and 'char **' are
equivalent types, meaning that conforming compilers should be able to
intermix them without problems, but 'const char **' is a different type, and
ANSI C either demands or strongly suggests a warning.

(Why exactly it's a different type is mostly a choice of language, though
I'm sure there are people who would defend the choice. What it means it that
you can't mix two layers of indirection with qualifiers like 'const' or
'volatile', without paying close attention to assignment and prototypes :P)

As a result, no matter what prototype we think up, we're always screwing
either the one type of platform or the other. And not with a warning; the
conflicting prototype would generate an error, nto a warning. The only
solution I can think of is adding the proper prototype to the pyport.h
header file, inside a proper #ifdef. For generated code it doesn't really
matter which of the prototypes is used, but if the system headers do
provide a prototype, and it doesn't match in indirect-constness, compilation
will fail. 

(In other words, even on the platforms that are missing it, close attention
should be paid to the manual pages, trying to guess what the prototype is
going to look like if that particular system would ever grow a prototype in
a system header. From what I read in the getopt(3) manpage on my linux box
the prototype mixup comes from a POSIX.2 flaw, but I'm not sure.)

Does anyone have a system where the prototype to getopt() is not defined in
header files ? My Solaris 2.x testbox has that problem, but the box in
question is one huge mess, and I doubt it has anything to do with Solaris in
particular. I only use it to reproduce reported bugs, not report any myself
;P

-- 
Thomas Wouters <thomas@xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!


From jeremy@beopen.com  Thu Oct 12 21:10:50 2000
From: jeremy@beopen.com (Jeremy Hylton)
Date: Thu, 12 Oct 2000 16:10:50 -0400 (EDT)
Subject: [Python-Dev] test_minidom non-failure failure? (take 2)
In-Reply-To: <20001012032448.A18407@glacier.fnational.com>
References: <14821.58057.358947.271778@bitdiddle.concentric.net>
 <20001012023134.A18254@glacier.fnational.com>
 <200010121739.MAA07968@cj20424-a.reston1.va.home.com>
 <20001012032448.A18407@glacier.fnational.com>
Message-ID: <14822.6858.920988.167252@bitdiddle.concentric.net>

>>>>> "NS" == Neil Schemenauer <nas@arctrix.com> writes:

  NS> The -l option tries to find any cyclic garbage produced by the
  NS> tests.  I don't think that that option should be enabled
  NS> default.  The output means that the GC is working and is finding
  NS> stuff that would not be freed by reference counting alone.

  NS> I can't tell if the GC would free this garbage.  The -l option
  NS> sets the DEBUG_SAVEALL option which causes all garbage found to
  NS> end up in gc.garbage, not just garbage the can't be cleaned up.

  NS> I don't have pyexpat installed here so I can't test it.  If you
  NS> want to find out if test_minidom is creating garbage the
  NS> collector can't free you should comment out the:

  NS>     gc.set_debug(gc.DEBUG_SAVEALL)

  NS> line in regrtest.py and run:

  NS>     regrtest.py -l test_minidom

  NS> If that does what I think it does and you still get the
  NS> "garbage: " line then the test is creating evil things.  :)

The test is not creating evil things.  I commented out the
DEBUG_SAVEALL line and got no error report.

The question, then, is what to do about the -l option.  I assume we
should remove the -l option from the Makefile, so that "make test"
doesn't turn on DEBUG_SAVEALL.  Or do we need to change regrtest in
some way so that it still reports on tests that create evil things?

Jeremy


From nas@arctrix.com  Thu Oct 12 14:20:10 2000
From: nas@arctrix.com (Neil Schemenauer)
Date: Thu, 12 Oct 2000 06:20:10 -0700
Subject: [Python-Dev] test_minidom non-failure failure? (take 2)
In-Reply-To: <14822.6858.920988.167252@bitdiddle.concentric.net>; from jeremy@beopen.com on Thu, Oct 12, 2000 at 04:10:50PM -0400
References: <14821.58057.358947.271778@bitdiddle.concentric.net> <20001012023134.A18254@glacier.fnational.com> <200010121739.MAA07968@cj20424-a.reston1.va.home.com> <20001012032448.A18407@glacier.fnational.com> <14822.6858.920988.167252@bitdiddle.concentric.net>
Message-ID: <20001012062010.A19026@glacier.fnational.com>

On Thu, Oct 12, 2000 at 04:10:50PM -0400, Jeremy Hylton wrote:
> The question, then, is what to do about the -l option.  I assume we
> should remove the -l option from the Makefile, so that "make test"
> doesn't turn on DEBUG_SAVEALL.  Or do we need to change regrtest in
> some way so that it still reports on tests that create evil things?

This is a policy decision.  Is it okay for the test suite to
create garbage that is not collectable by reference counting?  If
yes, what about garbage that is not collectable by the (current)
GC?  

  Neil


From guido@python.org  Thu Oct 12 22:21:39 2000
From: guido@python.org (Guido van Rossum)
Date: Thu, 12 Oct 2000 16:21:39 -0500
Subject: [Python-Dev] test_minidom non-failure failure? (take 2)
In-Reply-To: Your message of "Thu, 12 Oct 2000 16:10:50 -0400."
 <14822.6858.920988.167252@bitdiddle.concentric.net>
References: <14821.58057.358947.271778@bitdiddle.concentric.net> <20001012023134.A18254@glacier.fnational.com> <200010121739.MAA07968@cj20424-a.reston1.va.home.com> <20001012032448.A18407@glacier.fnational.com>
 <14822.6858.920988.167252@bitdiddle.concentric.net>
Message-ID: <200010122121.QAA09024@cj20424-a.reston1.va.home.com>

> The question, then, is what to do about the -l option.  I assume we
> should remove the -l option from the Makefile, so that "make test"
> doesn't turn on DEBUG_SAVEALL.

This seems to make sense, yes.  Since the "leaked" objects that are
found will be released by the GC code, I see no point in reporting
these during the regression test.  This can only confuse people (like
it did Jeremy :-).

> Or do we need to change regrtest in
> some way so that it still reports on tests that create evil things?

Any form of evilness that can be detected without *too* much effort is
worth it...  I have no idea what kind of evil we're looking for here
or how to detect is, so I can't answer yes or no.

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


From fdrake@beopen.com  Thu Oct 12 21:18:15 2000
From: fdrake@beopen.com (Fred L. Drake, Jr.)
Date: Thu, 12 Oct 2000 16:18:15 -0400 (EDT)
Subject: [Python-Dev] New development documentation up...
Message-ID: <14822.7303.953870.727070@cj42289-a.reston1.va.home.com>

  I don't normally post when I've updated the development copy of the
documentation, but there are a couple of big additions there now.
  Martin von L=F6wis contributed substantial SAX2 documentation, which
I've now integrated.  Thanks, Martin!
  Chris Barker is working on new documentation for the Macintosh
manual; I've only just started to look at it, but there's definately a
*lot* of new material.  That's not checked into CVS yet, but will be
once I've had more time to go over it.  Thanks, Chris!

=09ftp://python.beopen.com/pub/docco/devel/index.html


  -Fred

--=20
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member



From nas@arctrix.com  Thu Oct 12 14:28:04 2000
From: nas@arctrix.com (Neil Schemenauer)
Date: Thu, 12 Oct 2000 06:28:04 -0700
Subject: [Python-Dev] test_minidom non-failure failure? (take 2)
In-Reply-To: <200010122121.QAA09024@cj20424-a.reston1.va.home.com>; from guido@python.org on Thu, Oct 12, 2000 at 04:21:39PM -0500
References: <14821.58057.358947.271778@bitdiddle.concentric.net> <20001012023134.A18254@glacier.fnational.com> <200010121739.MAA07968@cj20424-a.reston1.va.home.com> <20001012032448.A18407@glacier.fnational.com> <14822.6858.920988.167252@bitdiddle.concentric.net> <200010122121.QAA09024@cj20424-a.reston1.va.home.com>
Message-ID: <20001012062804.B19026@glacier.fnational.com>

On Thu, Oct 12, 2000 at 04:21:39PM -0500, Guido van Rossum wrote:
> Any form of evilness that can be detected without *too* much effort is
> worth it...  I have no idea what kind of evil we're looking for here
> or how to detect is, so I can't answer yes or no.

That would be reference cycles with finalizers (ie. instances
with __del__ methods).  The current garbage collector does not
free such structures but instead appends them to gc.garbage.
Sorry for not being clear.

In any case, regrtest should probably print a more clueful
message when objects are found in gc.garbage.  That would go a
long way in clearing up the confusion.  I'll see about a patch.

  Neil


From guido@python.org  Thu Oct 12 22:26:49 2000
From: guido@python.org (Guido van Rossum)
Date: Thu, 12 Oct 2000 16:26:49 -0500
Subject: [Python-Dev] test_minidom non-failure failure? (take 2)
In-Reply-To: Your message of "Thu, 12 Oct 2000 06:20:10 MST."
 <20001012062010.A19026@glacier.fnational.com>
References: <14821.58057.358947.271778@bitdiddle.concentric.net> <20001012023134.A18254@glacier.fnational.com> <200010121739.MAA07968@cj20424-a.reston1.va.home.com> <20001012032448.A18407@glacier.fnational.com> <14822.6858.920988.167252@bitdiddle.concentric.net>
 <20001012062010.A19026@glacier.fnational.com>
Message-ID: <200010122126.QAA09072@cj20424-a.reston1.va.home.com>

> This is a policy decision.  Is it okay for the test suite to
> create garbage that is not collectable by reference counting?

I don't see why that should be forbidden.  After all some of the code
we test has such leaks -- we haven't declared those absolute bugs.

> If yes, what about garbage that is not collectable by the (current)
> GC?

Can you give an example of how such garbage can be created?

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


From jeremy@beopen.com  Thu Oct 12 21:38:29 2000
From: jeremy@beopen.com (Jeremy Hylton)
Date: Thu, 12 Oct 2000 16:38:29 -0400 (EDT)
Subject: [Python-Dev] test_minidom non-failure failure? (take 2)
In-Reply-To: <20001012062804.B19026@glacier.fnational.com>
References: <14821.58057.358947.271778@bitdiddle.concentric.net>
 <20001012023134.A18254@glacier.fnational.com>
 <200010121739.MAA07968@cj20424-a.reston1.va.home.com>
 <20001012032448.A18407@glacier.fnational.com>
 <14822.6858.920988.167252@bitdiddle.concentric.net>
 <200010122121.QAA09024@cj20424-a.reston1.va.home.com>
 <20001012062804.B19026@glacier.fnational.com>
Message-ID: <14822.8517.675600.578272@bitdiddle.concentric.net>

>>>>> "NS" == Neil Schemenauer <nas@arctrix.com> writes:

  NS> In any case, regrtest should probably print a more clueful
  NS> message when objects are found in gc.garbage.  That would go a
  NS> long way in clearing up the confusion.  I'll see about a patch.

I think there is some value to issueing reports when a test creates
trash that can't be cleaned up by the GC, but it doesn't make sense to
report this by default.  If "make test" reports an error, it should
mean that something has gone wrong with the user's build and the
interpreter is broken.  That's not the case here.  The build was fine;
it's just the test that is iffy.

I think we should turn of the -l option by default *and* patch it so
that the output is more useful.  I would suggest printing a count of
the objects, perhaps organized by type/class name.  Something like
this: 

    Test created 6 uncollectable objects
    4 foo.Bar instances
    2 foo.Baz instances

Jeremy


From tim_one@email.msn.com  Thu Oct 12 21:33:41 2000
From: tim_one@email.msn.com (Tim Peters)
Date: Thu, 12 Oct 2000 16:33:41 -0400
Subject: [Python-Dev] RE: [Numpy-discussion] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison)
In-Reply-To: <Pine.A32.3.90.1001012140201.14856A-100000@elvis.med.Virginia.EDU>
Message-ID: <LNBBLJKPBEHFEDALKOLCEEACHLAA.tim_one@email.msn.com>

[Steven D. Majewski]
> ...
> I also mostly agree with Tim, except that I'm not sure that bad or
> incomplete ieee support is always better than none at all.

This is true, because having Python is better than not having Python, and in
having Python you indeed have bad *and* incomplete 754 support on every 754
platform it runs on.  Even better, it's a subset of damaged 754 support
unique to each platform whose details can't be guessed or documented in
advance of trying it exhaustively to see what happens(*), and a subset that
can change delightfully across releases, compiler upgrades, library upgrades
and seemingly irrelevant minor config changes.  So if bad or incomplete IEEE
support is good, Python is-- here as elsewhere --the King of Languages
<wink>.

Every step of this dance is thoroughly predictable.  In this case, I'm doing
my darnedest to nudge Python its very first step towards *real* 754 support,
and getting dumped on for it by a 754 fan.  Simultaneously, the "old guard"
defends their lifestyle against new-fangled ideas <wink>, asking for
protections unaware that 754 *requires* they get a better form of the
protections they seek than they've dreamed of so far.  It appears that
nobody on either side has actually read the std, and I've become the very
754 Storm Trooper I used to despise.  Computer life is great <wink>.

all-it's-missing-is-variety-ly y'rs  - tim


(*) Quiz:  *if* you can manage to trick Python into creating a NaN on your
particular 754 platform, does the Python expression NaN == 1.0 return true,
false, or raise an exception?  Answer before you try it.  Then try it on
enough 754 platforms until you give up trying to guess in advance.  NaN ==
NaN is predictable in Python, and is the one 754 feature Python guarantees
won't work correctly on any 754 platform (although I've heard that it loses
this predictability when run using NumPy's flavor of comparisons instead of
core Python's).




From nas@arctrix.com  Thu Oct 12 14:43:09 2000
From: nas@arctrix.com (Neil Schemenauer)
Date: Thu, 12 Oct 2000 06:43:09 -0700
Subject: [Python-Dev] test_minidom non-failure failure? (take 2)
In-Reply-To: <200010122126.QAA09072@cj20424-a.reston1.va.home.com>; from guido@python.org on Thu, Oct 12, 2000 at 04:26:49PM -0500
References: <14821.58057.358947.271778@bitdiddle.concentric.net> <20001012023134.A18254@glacier.fnational.com> <200010121739.MAA07968@cj20424-a.reston1.va.home.com> <20001012032448.A18407@glacier.fnational.com> <14822.6858.920988.167252@bitdiddle.concentric.net> <20001012062010.A19026@glacier.fnational.com> <200010122126.QAA09072@cj20424-a.reston1.va.home.com>
Message-ID: <20001012064309.C19026@glacier.fnational.com>

On Thu, Oct 12, 2000 at 04:26:49PM -0500, Guido van Rossum wrote:
> > This is a policy decision.  Is it okay for the test suite to
> > create garbage that is not collectable by reference counting?
> 
> I don't see why that should be forbidden.  After all some of the code
> we test has such leaks -- we haven't declared those absolute bugs.

Again, "-l" should probably not be a default.  I don't know who
added it to TESTOPTS but it wasn't me.

> Can you give an example of how such garbage can be created?

Look at test_gc.  Here is an example:

    class Foo:
        def __del__(self):
            pass
    foo = Foo()
    foo.foo = foo
    del foo

Theoretically this structure could be collected without problem
but the GC is too simple minded to realize that there is only one
finalizer involved.  Here's a better example:

    foo = Foo()
    bar = Foo()
    foo.bar = bar
    bar.foo = foo
    del foo, bar

The GC cannot safely break this cycle so it punts and adds the
instance objects involved to gc.garbage and forgets about it.

  Neil


From tim_one@email.msn.com  Thu Oct 12 22:38:13 2000
From: tim_one@email.msn.com (Tim Peters)
Date: Thu, 12 Oct 2000 17:38:13 -0400
Subject: [Python-Dev] Re: getopt() prototype [was: checkin-message of something or other]
In-Reply-To: <20001012211436.Z12812@xs4all.nl>
Message-ID: <LNBBLJKPBEHFEDALKOLCIEAGHLAA.tim_one@email.msn.com>

[Thomas Wouters, on getopt]
> ...
> From what I read in the getopt(3) manpage on my linux box the
> prototype mixup comes from a POSIX.2 flaw, but I'm not sure.)

I bet it's actually talking about Interpretation 150 to POSIX.2, here (while
you can't read the std online, you can read the complaints online!):

http://standards.ieee.org/reading/ieee/interp/1003-2-92_int/pasc-1003.2-150.
html

Doesn't have anything to do with the prototype, alas.

> Does anyone have a system where the prototype to getopt() is not
> defined in header files ? My Solaris 2.x testbox has that problem, but
> the box in question is one huge mess, and I doubt it has anything to do
> with Solaris in particular. ...

Sure:  Windows doesn't have a getopt; getopt isn't std C (not even in C99).
Assorted derived stds demand that a getopt protoptype appear in stdlib.h,
and others that it appear in unistd.h.

I have a different suggestion:  screw it.  getopt keeps creating problems on
GNUish systems too, because without the POSIXLY_CORRECT envar set, the GNU
getopt shuffles all the "option strings" to the front, making a mess of,
e.g.,

python myprog.py -v

The Python source tree already has its own getopt implementation
(Python/getopt.c) -- let's rename its contained function to PyOS_Getopt, get
rid of the irritating __BEOS__ #ifdef'ery therein, prototype it the way we
like, and have Python use that instead on all systems.  Every second we've
spent tracking down problems with platform-supplied getopts has been a waste
of time.

they've-had-21-years-to-straighten-out-"the-std"-getopt-and-they-blew-it-
    ly y'rs  - tim




From jack@oratrix.nl  Thu Oct 12 23:03:57 2000
From: jack@oratrix.nl (Jack Jansen)
Date: Fri, 13 Oct 2000 00:03:57 +0200
Subject: [Python-Dev] MacPython 2.0c1 available
Message-ID: <20001012220402.ABE8D104729@oratrix.oratrix.nl>

MacPython 2.0c1 is available, both as binary installer and in source
form. You can find it through
http://www.cwi.nl/~jac/macpython.html. If people give it a testdrive
please let me know whether it works, and, in the unlikely event it
doesn't:-) what the problems are.

Thanks,
--
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/ ++++


From guido@python.org  Fri Oct 13 00:07:28 2000
From: guido@python.org (Guido van Rossum)
Date: Thu, 12 Oct 2000 18:07:28 -0500
Subject: [Python-Dev] Re: getopt() prototype [was: checkin-message of something or other]
In-Reply-To: Your message of "Thu, 12 Oct 2000 17:38:13 -0400."
 <LNBBLJKPBEHFEDALKOLCIEAGHLAA.tim_one@email.msn.com>
References: <LNBBLJKPBEHFEDALKOLCIEAGHLAA.tim_one@email.msn.com>
Message-ID: <200010122307.SAA09493@cj20424-a.reston1.va.home.com>

> I have a different suggestion:  screw it.  getopt keeps creating problems on
> GNUish systems too, because without the POSIXLY_CORRECT envar set, the GNU
> getopt shuffles all the "option strings" to the front, making a mess of,
> e.g.,
> 
> python myprog.py -v
> 
> The Python source tree already has its own getopt implementation
> (Python/getopt.c) -- let's rename its contained function to PyOS_Getopt, get
> rid of the irritating __BEOS__ #ifdef'ery therein, prototype it the way we
> like, and have Python use that instead on all systems.  Every second we've
> spent tracking down problems with platform-supplied getopts has been a waste
> of time.

Excellent.  After 2.0.

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


From thomas@xs4all.net  Thu Oct 12 23:18:01 2000
From: thomas@xs4all.net (Thomas Wouters)
Date: Fri, 13 Oct 2000 00:18:01 +0200
Subject: [Python-Dev] Re: getopt() prototype [was: checkin-message of something or other]
In-Reply-To: <LNBBLJKPBEHFEDALKOLCIEAGHLAA.tim_one@email.msn.com>; from tim_one@email.msn.com on Thu, Oct 12, 2000 at 05:38:13PM -0400
References: <20001012211436.Z12812@xs4all.nl> <LNBBLJKPBEHFEDALKOLCIEAGHLAA.tim_one@email.msn.com>
Message-ID: <20001013001801.A12812@xs4all.nl>

On Thu, Oct 12, 2000 at 05:38:13PM -0400, Tim Peters wrote:
> [Thomas Wouters, on getopt]
> > ...
> > From what I read in the getopt(3) manpage on my linux box the
> > prototype mixup comes from a POSIX.2 flaw, but I'm not sure.)
> 
> I bet it's actually talking about Interpretation 150 to POSIX.2, here (while
> you can't read the std online, you can read the complaints online!):

> http://standards.ieee.org/reading/ieee/interp/1003-2-92_int/pasc-1003.2-150.
> html

> Doesn't have anything to do with the prototype, alas.

Ah, that sounds about right. Nifty link, too. I thought it had something to
do with the prototype because of this comment:

CONFORMING TO
       getopt():
              POSIX.2,    provided   the   environment   variable
              POSIXLY_CORRECT is set.  Otherwise, the elements of
              argv  aren't really const, because we permute them.
              We pretend they're const in  the  prototype  to  be
              compatible with other systems.


> I have a different suggestion:  screw it.  getopt keeps creating problems on
> GNUish systems too, because without the POSIXLY_CORRECT envar set, the GNU
> getopt shuffles all the "option strings" to the front, making a mess of
  [ a lot of things ]

Ahh, yes, I see Python/getopt.c and the autoconf check that enables it when
necessary. Funny, I've seen that file a number of times, and read it, and
read the getopt autoconf test as well, but somehow I never connected it with
the loose prototype in main.c. I'm +1 on doing what you suggested, then.

Wonder why it hasn't been done yet, though... we have no use for a
system-wide getopt, except for a slightly smaller binary on systems that do
have a 'good' system getopt. We can't use enhancements made to system getopt
or anything, anyway.

> they've-had-21-years-to-straighten-out-"the-std"-getopt-and-they-blew-it-
>     ly y'rs  - tim

what-do-you-want-to-bet-it's-going-to-take-longer-for-Python-getopt-modules-
	ly y'rs,

-- 
Thomas Wouters <thomas@xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!


From m.favas@per.dem.csiro.au  Fri Oct 13 01:47:25 2000
From: m.favas@per.dem.csiro.au (Mark Favas)
Date: Fri, 13 Oct 2000 08:47:25 +0800
Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich
 comparison)
Message-ID: <39E65B9D.B9F6BA70@per.dem.csiro.au>

Just a little unreality check - the whole world is not (yet) Linux - or
even MS. The behaviour of math.exp(-746) on my flavours of 1.5.2 on
Solaris boxes and DEC Alphas (Tru64 Unix) is the same as the behaviour
of 2.0 - OverflowError: math range error. Thus, on these platform, the
proposed fixes _will_ change behaviour. But that's cool - I like Tim's
proposed, um, steps to "rationalizing" fp behaviour, and will do what I
can to help in the future.
-- 
Email - m.favas@per.dem.csiro.au
        CSIRO Exploration & Mining


From tim_one@email.msn.com  Fri Oct 13 06:15:13 2000
From: tim_one@email.msn.com (Tim Peters)
Date: Fri, 13 Oct 2000 01:15:13 -0400
Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich  comparison)
In-Reply-To: <39E65B9D.B9F6BA70@per.dem.csiro.au>
Message-ID: <LNBBLJKPBEHFEDALKOLCCEBBHLAA.tim_one@email.msn.com>

[Mark Favas]
> Just a little unreality check - the whole world is not (yet) Linux - or
> even MS. The behaviour of math.exp(-746) on my flavours of 1.5.2 on
> Solaris boxes and DEC Alphas (Tru64 Unix) is the same as the behaviour
> of 2.0 - OverflowError: math range error.

This is unfortunate.  Guido never intended for Python to raise exceptions on
underflow (and especially not *Over*flowError(!)), but he apparently didn't
run on any platforms where this happened (I never have!), and AFAIK nobody
ever mentioned this before.

> Thus, on these platform, the proposed fixes _will_ change behaviour.

See "unfortunate" above <0.5 wink>.

> But that's cool - I like Tim's proposed, um, steps to "rationalizing"
> fp behaviour, and will do what I can to help in the future.

Want to fund a crack group of 754 experts for a year?  Didn't think so.
Constructive complaints will help a lot.  So will beta testing.  For
example, I'm very keen to know whether the current CVS version of Python
(2.0c1) still raises OverflowError for math.exp(-746) on your Solaris and/or
Tru64 Unix boxes.  Running the (current CVS) std test suite will tell you:
test_libm will pass or fail accordingly.  If it's still busted on one of
your systems, we've only got about a day to fix it (2.0 final is shipping
early next week, and we have to let the codebase settle down for a couple
days before building the final release).

but-since-it's-been-a-random-mess-for-a-decade-already-i'm-not-
    losing-much-sleep-over-it-ly y'rs  - tim




From tim_one@email.msn.com  Fri Oct 13 06:18:52 2000
From: tim_one@email.msn.com (Tim Peters)
Date: Fri, 13 Oct 2000 01:18:52 -0400
Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich  comparison)
In-Reply-To: <LNBBLJKPBEHFEDALKOLCCEBBHLAA.tim_one@email.msn.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCKEBBHLAA.tim_one@email.msn.com>

[Tim hallucinated ...]
> ... I'm very keen to know whether the current CVS version of Python
> (2.0c1) still raises OverflowError for math.exp(-746) on your
> Solaris and/or Tru64 Unix boxes.

Sorry for contradicting myself within a single sentence:  I couldn't care
less what happens in 2.0c1 anymore.  Like I clearly said at the start,
"current CVS version" is the question.




From bwarsaw@beopen.com  Fri Oct 13 06:33:57 2000
From: bwarsaw@beopen.com (Barry A. Warsaw)
Date: Fri, 13 Oct 2000 01:33:57 -0400 (EDT)
Subject: [Python-Dev] test_minidom non-failure failure? (take 2)
References: <14821.58057.358947.271778@bitdiddle.concentric.net>
 <20001012023134.A18254@glacier.fnational.com>
 <200010121739.MAA07968@cj20424-a.reston1.va.home.com>
 <20001012032448.A18407@glacier.fnational.com>
 <14822.6858.920988.167252@bitdiddle.concentric.net>
 <20001012062010.A19026@glacier.fnational.com>
 <200010122126.QAA09072@cj20424-a.reston1.va.home.com>
 <20001012064309.C19026@glacier.fnational.com>
Message-ID: <14822.40645.656159.493390@anthem.concentric.net>

>>>>> "NS" == Neil Schemenauer <nas@arctrix.com> writes:

    NS> Again, "-l" should probably not be a default.  I don't know
    NS> who added it to TESTOPTS but it wasn't me.

I did, but at the time -l set LEAK_DEBUG not DEBUG_SAVEALL, and I
think (but don't really remember) that LEAK_DEBUG had different
semantics than it does now.

No matter.  This was useful when gc was spankin' new and only
semi-tested.  It's probably fine to turn off -l in "make test" by
default for the 2.0 release.

-Barry


From tim_one@email.msn.com  Fri Oct 13 09:01:16 2000
From: tim_one@email.msn.com (Tim Peters)
Date: Fri, 13 Oct 2000 04:01:16 -0400
Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison)
In-Reply-To: <slrn8ucd0a.4id.hzhu@localhost.localdomain>
Message-ID: <LNBBLJKPBEHFEDALKOLCIEBCHLAA.tim_one@email.msn.com>

[Tim]
> ...
> We cannot consider this to be a bug since Python has had no *intended*
> behavior whatsoever wrt 754 gimmicks.  We can and do consider gripes
> about these accidents to be feature requests.

[Huaiyu Zhu]
> Yes it varies widely in Python.  But isn't that precisely because Python
> does not support IEEE?

Yes, but that's darned near tautological <0.5 wink>.

> If Python does not actively undermine IEEE on platforms that have it,
> would it still vary widely across these platforms?

Yes.  Your own -lieee example showed that math.sqrt(-1) computes not only a
non-754 result, but a senseless result, on your platform under 1.5.2.  If I
show you a platform, how are you going to decide whether it "has" IEEE?  754
is a very involved std, and it's still rare to find a platform C that
supports it correctly.  On platform C's that do support it correctly, I know
of none that do so without requiring platform-specific tricks.  Python has
*nothing* portable it can rely on, and its mass of utterly non-754-aware
code building on haphazard C implementations adds up to the random
x-platform crap we have today.

...
[T]
> The patch to stop setting -lieee was contributed by a Python user who
> claimed it fixed bugs on *their* platform.  That's "the reason".
> We don't want to screw them either.

[H]
> Q: What bug?  Which platform?  Maybe there is another way that has less
>    impact on others?  How to find out?

I didn't check it in, and you can search the CVS archives as easily as I can
(I'm not inclined to, since I don't think it can affect the outcome of
this).  Jeremy Hylton may, or may not, remember more about it (IIRC, he said
he checked it in).

> ...
> If there is a way to fix the bug on that other platform while still keep
> -lieee on Linux, would that be acceptable?

No:  Guido *wants* overflow to raise OverflowError by default, and *wants*
sqrt(-1.0) to raise ValueError by default.  Python's x-platform fp numerics
today are an utter mess, and the best we can do for 2.0 is to make them as
consistent as we have time to make them, despite that we know it will break
some of your code (but you can still link with -lieee if you feel you must),
and that Mark Favas has confirmed it will break code under both his Solaris
and Tru64 Unix systems (but for a reason opposite of yours:  he's been
getting OverflowError on underflow since 1.5.2, and we're taking that away
from him, and he'll have *no* way to go back).  At this point we favor
forcing consistency over maintaining platform accidents, no matter how
attached people have gotten to them; else we'll be stuck with them forever.

[oh some of Kahan's papers, at http://http.cs.berkeley.edu/~wkahan/]
> Interesting! I've glanced through some of Prof Kahan's writings.

He is an entertaining writer, although his rhetoric is often more extreme
than either of ours <wink>.

> It appears that he favors raising flags that can be checked optionally,
and
> he is against mandatary raising exceptions.

Have you read the 754 std?  He's in favor of the 754 std.

[quotes snipped, except for my favorite, which I've paraphrased many times
 over the years on c.l.py]
> ...
>   They are called "Exceptions" because to any policy for handling them,
>   imposed in advance upon all programmers by the computer system, some
>   programmers will have good reason to take exception.

> ...
> From these quotes and others I understand that he wants f.p. exceptions to
> be merely messanges, not errors that force programmers to take extra
> actions, unless the programmer choose to.  So what aspect of Java did he
> think is deficient?  It is the "Trap" style exception that mandate a users
> action.

His paper "How JAVA's Floating-Point Hurts Everyone Everywhere" lists his 5
main gripes about Java in bullet points at the top of page 3.  The paper
runs on to 80 pages.  You somehow managed to miss 79.89 of them <0.4 wink>,
reducing it to a bogus claim about Java that Kahan didn't make (Java has
neither "Trap" nor "Flag" style fp exception signaling).

> He told "A cautionary Tale of the Ariane 5",

Which has nothing to do with Java -- the software in question was written in
Ada, which (unlike Java) has "Trap" style.  Why he put it in a paper about
Java is a bit of a mystery; I write it off to rhetorical excess.

> the European rocket that mulfunctioned after lift off.  It turned out
> that a piece of software produced an unimportant exception that is
> not caught by a handler and caused debugging data to be dumped to a
> critical memory location.  This would have been avoided if the exception
> merely raised a flag and returned a NaN, and the program continued.

Actually, that was impossible to do, and he didn't suggest that.  What he
wrote is

    Had overflow merely obeyed the IEEE 754 default policy, the
    recalibration software would have raised a flag and delivered an
    invalid result both to be ignored by the motor guidance programs,
    and the Ariane 5 would have pursued its intended trajectory.

Note that he didn't say NaN.  He couldn't, because this was overflow in a
conversion from Float to Integer.  Despite his cheery optimism here, 754 is
approximately useless in this case, since there is no generally accepted
"invalid result" in integer formats (and 754 doesn't define one either --
the result of overflow in converting floats to ints is ill-defined in 754;
754 doesn't even require that it set the overflow flag).

> So do we want every Python program to bomb whenever there is a floating
> point value outside bound and is not trapped by try/except?

By default, yes, Guido does, but for overflow, not underflow.  If you read
the following section of Kahan's paper, you should have noticed that he is
*just* as critical of just returning Infs and NaNs (which is all Java does,
and which is the accidental Python behavior you're arguing we keep in glibc)
as he is of just trapping!  His conclusion:  "Without Traps nor Flags, Java’
s floating-point is Dangerous":

    Without flags, detecting rare creations of Inf and NaN before they
    disappear requires programmed tests and branches that, besides
    duplicating tests already performed by the hardware, slow down the
    program and impel a programmer to make decisions prematurely in many
    cases. Worse, a plethora of tests and branches undermines a program’s
    modularity, clarity and concurrency.

I agree with him there wholeheartedly:  without the 754-mandated flags,
*and* without raising exceptions, the subset of 754 remaining sucks.

>> ironically, 754 is hardest to sell to those who could benefit from
>> it the most.

> So far the only concern from number-crunchers voiced here is that it might
> allow sqrt(-1)==0, which is not the case.

Gimme a break!  In the very msg Paul Dubois said that, he also said "Some
people use Inf but most people want the code to STOP so they can find out
where the INFS started.  Otherwise, two hours later you have big arrays of
Infs and no idea how it happened.".  I'm starting to drop my assumption of
good faith on your part:  what you remember and how you paraphrase (whether
it's Paul or Kahan) is extremely selective, beyond normal bounds of
zeal-inspired distortion.

> I was a fortran programmer before.  I switched to using IEEE ten years
> ago as soon as it was available on the machine I was using.  So there
> are different opinions.

Certainly, and good 754 support will cater to most of them.  I don't believe
your opinion (or mine, for that matter) reflects anything even close to the
majority view here, though.  As I said in my reply to Paul, my observations
(based on 15 years on the vendor side of the fp biz) matched his exactly
(based on his experience with hundreds of numeric code authors):  a vast
majority still want divide-by-0, invalid operation, and overflow to raise an
exception the vast majority of the time.

> ...
> Obviously we agree on the benefit of having a choice.  But we
> have different perspective on what choice means.  Your want a choice
> to force user to take explicit action, I want a choice to ignore these
> events.

No.  I want exactly the choices 754 lays out:  user-settable sticky flags
and user-maskable exceptions.  We're not getting that for 2.0.  And we're
*never* getting it if 2.0 doesn't do *something* to start disabusing people
of the notion that their historical numeric platform accidents in Python
will be faithfully preserved forever more.

> The ideal solution might be to have a sys.fp_exception class.  Each
> exception would set a flag like fp_exception.overflow so that user can
> check them.  There could also be a variable like fp_exception.force_trap,
> which when set, could make each f.p. exception to produce a Python
> exception.  This would confirm to IEEE 754 and give both of us a choice
> we want.

Kinda, except that each of the 5 754-defined traps must be individually
maskable.  754 spells out what's needed.  A PEP will be required to spell
out the Python- and C-level APIs.  I've corresponded (just -- no time now) a
little with Kevin Jacobs about that offline.

> Now that we are in feature freeze for 2.0, we can't get both choices.
> Can we adopt the one that does not break behaviors on previous official
> release, even if that's only by accident?

Not as far as Guido or I are concerned, no.  You can link with -lieee
yourself if you must, although I can't recommend perpetuating the x-platform
confusion here.  We want to say that, e.g., math.exp works substantially the
same way on *all* platforms under 2.0, not repeat the same decade-old "umm,
don't know, and no way to guess -- try it on your platform and see what it
does" yet again.  I don't expect 2.0 will actually achieve that on all
platforms, but it should on the primary ones.

> ...
> So now I know why people reported that NaN and Inf were broken on HPUX
> and Windows and some others.  If Python had simply ignored the flags ...

Then we would have broken 754 subsets in slightly subtler ways, and still
wildly varying across platforms.

> ...
> Could you please point a URL to "presubstitution"?  In the paragraphs I
> quoted the only mention of presubstitute is with NaNs and Inf, etc.

Sorry, I don't save URLs, and don't recall whether this was in a paper or on
David Hough's "Numeric Interest" mailing list in the early 90's.  A Google
search on "presubstitution Kahan" turns up 4 promising-looking hits I'll
leave you to pursue.  The basic idea is that the programmer gets to specify,
via library calls (whatever), which particular fp value each 754 exceptional
case returns.  So, e.g., if it made sense for some part of the app, the
programmer could say they wanted +- pi returned instead +- Inf, if and
whenever overflow happened.  Then set it back to +- Inf (or anything else
they needed) later.  This would be best if supported in HW directly, of
course.

> ...
> You are not confirming to 754 until you allow all the exceptions to go
> through with well defined values as default.

I know that, but don't care.  As I said, enabling overflow + invalid + div0
by default is the only scheme that can be *sold*.  If you can find two NumPy
users in favor of disabling them all by default, I'll be mildly astonished.
754 did itself enormous harm by insisting on that trivial point (it's
trivial because, with proper support, anyone can change the defaults to
anything they like with one line of code):  I worked in the supercomputer
biz at the time 754 was adopted, and for a decade after, and the "non stop"
defaults were *universally* opposed by customers.  Scared the hell out of
language stds committees too, which goes a lot farther than the 754 folks
would like to admit toward explaining why language committees stayed away
from 754 bindings in droves.  C99 is 15 years(!) after the fact.

> Raising Python exceptions on some of them does not confirm to 754, as
> the default IEEE 754 behavior on f.p. exception is not a Python exception,
> but just a raised flag.

See above.

> Before that happens, what is the motive to make IEEE less usable for those
> who have it (pretty much every one nowadays), even if just by accident?

I think I've repeated the reasons to death already, and you've repeated to
death that you'll never agree.  So no more from me on that.

> ...
> But just to clarify some wordings you quoted in another post: I meant that
> sqrt(-1)==0 is insane, whether silent or not.

I agree.

> Raising an exception is sane,

Not according to 754's default rules, which you wanted me to take as sacred
just a few paragraphs ago <wink>.

> although OverflowError is not so reasonable.

I'd say it's insane.

> Raising a ValueError is reasonable.

I expect we'll have to make InvalidOperationError a subclass of ValueError
for that reason, when 754 support materializes.

> But just returning NaN without a fuss is even better.

You're going to find that's a very lonely position.

> My favorite is returning 1j, as MatPy does.

Then you should use cmath.sqrt instead of math.sqrt.  Even $3 business
calculators have a sqrt key these days, and you do not want to be on the
other end of email when trying to explain to a businessperson why their
crappy std deviation program returned a complex number <0.1 wink>.

> if-it-ain't-broke-don't-fix-it-ly y'rs

it-it-weren't-broke-we-wouldn't-ly y'rs  - tim




From fgranger@altern.org  Fri Oct 13 11:08:23 2000
From: fgranger@altern.org (Francois Granger)
Date: Fri, 13 Oct 2000 12:08:23 +0200
Subject: [Python-Dev] Re: [Pythonmac-SIG] MacPython 2.0c1 available
In-Reply-To: <20001012220402.ABE8D104729@oratrix.oratrix.nl>
Message-ID: <B60CABB6.14362%fgranger@altern.org>

on 13/10/00 0:03, Jack Jansen at jack@oratrix.nl wrote:

> MacPython 2.0c1 is available, both as binary installer and in source
> form. You can find it through
> http://www.cwi.nl/~jac/macpython.html.

This one works better.

http://www.cwi.nl/~jack/macpython.html


--=20
Fran=E7ois Granger
fgranger@altern.org



From nas@arctrix.com  Fri Oct 13 07:37:17 2000
From: nas@arctrix.com (Neil Schemenauer)
Date: Thu, 12 Oct 2000 23:37:17 -0700
Subject: [Python-Dev] test_minidom non-failure failure? (take 2)
In-Reply-To: <14822.40645.656159.493390@anthem.concentric.net>; from bwarsaw@beopen.com on Fri, Oct 13, 2000 at 01:33:57AM -0400
References: <14821.58057.358947.271778@bitdiddle.concentric.net> <20001012023134.A18254@glacier.fnational.com> <200010121739.MAA07968@cj20424-a.reston1.va.home.com> <20001012032448.A18407@glacier.fnational.com> <14822.6858.920988.167252@bitdiddle.concentric.net> <20001012062010.A19026@glacier.fnational.com> <200010122126.QAA09072@cj20424-a.reston1.va.home.com> <20001012064309.C19026@glacier.fnational.com> <14822.40645.656159.493390@anthem.concentric.net>
Message-ID: <20001012233717.A20054@glacier.fnational.com>

On Fri, Oct 13, 2000 at 01:33:57AM -0400, Barry A. Warsaw wrote:
> I think (but don't really remember) that LEAK_DEBUG had
> different semantics than it does now.

Nope.  LEAK_DEBUG prints to stderr information about all garbage
the GC finds, even stuff the GC can free.  The thinking was that
GC would be an option and people would want to find applications
that leak when only using reference counting.

> No matter.  This was useful when gc was spankin' new and only
> semi-tested.  It's probably fine to turn off -l in "make test" by
> default for the 2.0 release.

I've left -l enabled for now.  Detecting tests that create
uncollectable garbage is probably a good thing.  It doesn't cost
much and the message should be fairly clear now.

  Neil


From fdrake@beopen.com  Fri Oct 13 14:34:03 2000
From: fdrake@beopen.com (Fred L. Drake, Jr.)
Date: Fri, 13 Oct 2000 09:34:03 -0400 (EDT)
Subject: [Python-Dev] test_minidom non-failure failure? (take 2)
In-Reply-To: <20001012233717.A20054@glacier.fnational.com>
References: <14821.58057.358947.271778@bitdiddle.concentric.net>
 <20001012023134.A18254@glacier.fnational.com>
 <200010121739.MAA07968@cj20424-a.reston1.va.home.com>
 <20001012032448.A18407@glacier.fnational.com>
 <14822.6858.920988.167252@bitdiddle.concentric.net>
 <20001012062010.A19026@glacier.fnational.com>
 <200010122126.QAA09072@cj20424-a.reston1.va.home.com>
 <20001012064309.C19026@glacier.fnational.com>
 <14822.40645.656159.493390@anthem.concentric.net>
 <20001012233717.A20054@glacier.fnational.com>
Message-ID: <14823.3915.245246.310674@cj42289-a.reston1.va.home.com>

Neil Schemenauer writes:
 > I've left -l enabled for now.  Detecting tests that create
 > uncollectable garbage is probably a good thing.  It doesn't cost
 > much and the message should be fairly clear now.

  Perhaps one thing that could be done is to reduce the volume of the
output; perhaps just list the first 1K or 2K of the repr?


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member



From nas@arctrix.com  Fri Oct 13 08:09:48 2000
From: nas@arctrix.com (Neil Schemenauer)
Date: Fri, 13 Oct 2000 00:09:48 -0700
Subject: [Python-Dev] test_minidom non-failure failure? (take 2)
In-Reply-To: <14823.3915.245246.310674@cj42289-a.reston1.va.home.com>; from fdrake@beopen.com on Fri, Oct 13, 2000 at 09:34:03AM -0400
References: <20001012023134.A18254@glacier.fnational.com> <200010121739.MAA07968@cj20424-a.reston1.va.home.com> <20001012032448.A18407@glacier.fnational.com> <14822.6858.920988.167252@bitdiddle.concentric.net> <20001012062010.A19026@glacier.fnational.com> <200010122126.QAA09072@cj20424-a.reston1.va.home.com> <20001012064309.C19026@glacier.fnational.com> <14822.40645.656159.493390@anthem.concentric.net> <20001012233717.A20054@glacier.fnational.com> <14823.3915.245246.310674@cj42289-a.reston1.va.home.com>
Message-ID: <20001013000948.C20054@glacier.fnational.com>

On Fri, Oct 13, 2000 at 09:34:03AM -0400, Fred L. Drake, Jr. wrote:
> Perhaps one thing that could be done is to reduce the volume of the
> output; perhaps just list the first 1K or 2K of the repr?

It just prints the number of object found now.

  Neil


From fdrake@beopen.com  Fri Oct 13 15:06:22 2000
From: fdrake@beopen.com (Fred L. Drake, Jr.)
Date: Fri, 13 Oct 2000 10:06:22 -0400 (EDT)
Subject: [Python-Dev] test_minidom non-failure failure? (take 2)
In-Reply-To: <20001013000948.C20054@glacier.fnational.com>
References: <20001012023134.A18254@glacier.fnational.com>
 <200010121739.MAA07968@cj20424-a.reston1.va.home.com>
 <20001012032448.A18407@glacier.fnational.com>
 <14822.6858.920988.167252@bitdiddle.concentric.net>
 <20001012062010.A19026@glacier.fnational.com>
 <200010122126.QAA09072@cj20424-a.reston1.va.home.com>
 <20001012064309.C19026@glacier.fnational.com>
 <14822.40645.656159.493390@anthem.concentric.net>
 <20001012233717.A20054@glacier.fnational.com>
 <14823.3915.245246.310674@cj42289-a.reston1.va.home.com>
 <20001013000948.C20054@glacier.fnational.com>
Message-ID: <14823.5854.638859.950835@cj42289-a.reston1.va.home.com>

Neil Schemenauer writes:
 > It just prints the number of object found now.

  Ok, I must have missed the checkin that changed that.  This is fine
in my book as well.
  Thanks for staying on top of this work!  I think you've really done
a great job with the GC effort.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member



From cgw@fnal.gov  Fri Oct 13 16:18:23 2000
From: cgw@fnal.gov (Charles G Waldman)
Date: Fri, 13 Oct 2000 10:18:23 -0500 (CDT)
Subject: [Python-Dev] can't build with threads on OSF/1
Message-ID: <14823.10175.741638.857531@buffalo.fnal.gov>

Sorry, I don't have time to investigate this fully right now.  Maybe
this weekend.  For now this is just a heads-up.  Hopefully, something
is just misconfigured on this system.

The machine in question is running OSF1 V4.0 878 alpha

I can only build Python from current CVS sources on OSF/1 if I specify
--without-thread.   If I don't specify this I get the following errors
at link time:

Unresolved:
__pthread_mutex_init
__pthread_mutex_destroy
__pthread_mutex_lock
__pthread_mutex_unlock
__pthread_cond_init
__pthread_cond_destroy
__pthread_cond_signal
__pthread_cond_wait
__pthread_create
__pthread_detach

I tried sending a message with the output of ./configure and make
attached, but it was over the 40K limit.  If anybody wants to see
these, email me.


From nas@arctrix.com  Fri Oct 13 09:28:49 2000
From: nas@arctrix.com (Neil Schemenauer)
Date: Fri, 13 Oct 2000 01:28:49 -0700
Subject: [Python-Dev] can't build with threads on OSF/1
In-Reply-To: <14823.10175.741638.857531@buffalo.fnal.gov>; from cgw@fnal.gov on Fri, Oct 13, 2000 at 10:18:23AM -0500
References: <14823.10175.741638.857531@buffalo.fnal.gov>
Message-ID: <20001013012849.C20168@glacier.fnational.com>

On Fri, Oct 13, 2000 at 10:18:23AM -0500, Charles G Waldman wrote:
> Unresolved:
> __pthread_mutex_init
[...]

What is the LIBS variable set to in Modules/Makefile?  It looks
your missing something like "-lpthread".

  Neil


From cgw@fnal.gov  Fri Oct 13 16:35:52 2000
From: cgw@fnal.gov (Charles G Waldman)
Date: Fri, 13 Oct 2000 10:35:52 -0500 (CDT)
Subject: [Python-Dev] can't build with threads on OSF/1
In-Reply-To: <20001013012849.C20168@glacier.fnational.com>
References: <14823.10175.741638.857531@buffalo.fnal.gov>
 <20001013012849.C20168@glacier.fnational.com>
Message-ID: <14823.11224.545609.761307@buffalo.fnal.gov>

Neil Schemenauer writes:
 > On Fri, Oct 13, 2000 at 10:18:23AM -0500, Charles G Waldman wrote:
 > > Unresolved:
 > > __pthread_mutex_init
 > [...]
 > 
 > What is the LIBS variable set to in Modules/Makefile?  It looks
 > your missing something like "-lpthread".

Hehehe.  I might be kinda thick sometimes, but I think I would have
caught that.  Here's a little more of the "make" output:

cd Modules;  make OPT="-O -Olimit 1500" VERSION="2.0"  prefix="/usr/local" exec_prefix="/usr/local"  LIBRARY=../libpython2.0.a link
 cc   python.o  ../libpython2.0.a -ldb                                 -lpthreads -lm  -o python 
ld:
Unresolved:
__pthread_mutex_init
__pthread_mutex_destroy
__pthread_mutex_lock
__pthread_mutex_unlock
__pthread_cond_init
__pthread_cond_destroy
__pthread_cond_signal
__pthread_cond_wait
__pthread_create
__pthread_detach
*** Exit 1
Stop.
*** Exit 1
Stop.



From thomas@xs4all.net  Fri Oct 13 17:34:36 2000
From: thomas@xs4all.net (Thomas Wouters)
Date: Fri, 13 Oct 2000 18:34:36 +0200
Subject: [Python-Dev] can't build with threads on OSF/1
In-Reply-To: <14823.10175.741638.857531@buffalo.fnal.gov>; from cgw@fnal.gov on Fri, Oct 13, 2000 at 10:18:23AM -0500
References: <14823.10175.741638.857531@buffalo.fnal.gov>
Message-ID: <20001013183436.B12812@xs4all.nl>

On Fri, Oct 13, 2000 at 10:18:23AM -0500, Charles G Waldman wrote:

> Sorry, I don't have time to investigate this fully right now.  Maybe
> this weekend.  For now this is just a heads-up.  Hopefully, something
> is just misconfigured on this system.

> The machine in question is running OSF1 V4.0 878 alpha

That's a former DEC alpha, right ? Perhaps running configure with
'--with-dec-threads' will solve the problem ? I'm not sure if that will work
alone, so you might need '--with-dec-threads --with-threads=no' to disable
'normal' thread-checking. 

You can also try this by hand; after running configure, edit
Modules/Makefile.pre, and change

LDLAST=

into

LDLAST= -threads

(not -lthreads, just -threads) That seems to be the only difference
--with-dec-threads uses.

I looked at this before, but don't have an alpha or anything else that needs
--with-dec-threads, so I couldn't detect this automatically. I do think it
should be done automatically, though. Perhaps I can figure it if you can
send me, for instance, config.log and the output of configure, and find the
time to run a few tests later. 

> I can only build Python from current CVS sources on OSF/1 if I specify
> --without-thread.   If I don't specify this I get the following errors
> at link time:

> Unresolved:
> __pthread_mutex_init

> I tried sending a message with the output of ./configure and make
> attached, but it was over the 40K limit.  If anybody wants to see
> these, email me.

If the above doesn't fix it, I can take a look at the output of configure
and config.log. No need to see the output of make just yet.

-- 
Thomas Wouters <thomas@xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!


From cgw@fnal.gov  Fri Oct 13 19:31:34 2000
From: cgw@fnal.gov (Charles G Waldman)
Date: Fri, 13 Oct 2000 13:31:34 -0500 (CDT)
Subject: [Python-Dev] can't build with threads on OSF/1
In-Reply-To: <20001013183436.B12812@xs4all.nl>
References: <14823.10175.741638.857531@buffalo.fnal.gov>
 <20001013183436.B12812@xs4all.nl>
Message-ID: <14823.21766.733905.575290@buffalo.fnal.gov>

Thomas Wouters writes:
 > 
 > That's a former DEC alpha, right ? Perhaps running configure with
 > '--with-dec-threads' will solve the problem ? I'm not sure if that will work
 > alone, so you might need '--with-dec-threads --with-threads=no' to disable
 > 'normal' thread-checking. 

Thank you, that indeed solves the problem.  Sorry for the noise.

It would be nice if configure were smart enough to figure this out!



From cgw@fnal.gov  Fri Oct 13 19:38:26 2000
From: cgw@fnal.gov (Charles G Waldman)
Date: Fri, 13 Oct 2000 13:38:26 -0500 (CDT)
Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee,
 and rich  comparison)
In-Reply-To: <LNBBLJKPBEHFEDALKOLCIECGHLAA.tim_one@email.msn.com>
References: <200010131453.JAA23050@buffalo.fnal.gov>
 <LNBBLJKPBEHFEDALKOLCIECGHLAA.tim_one@email.msn.com>
Message-ID: <14823.22178.605732.455689@buffalo.fnal.gov>

Tim Peters wrote:
 > I'm very keen to know whether the current CVS version of Python
 > (2.0c1) still raises OverflowError for math.exp(-746) on your
 > Solaris and/or Tru64 Unix boxes.

I just repeated this test, on the following 4 platforms:

1)   SunOS fsui02 5.6 Generic_105181-21 sun4u sparc SUNW,Ultra-Enterprise
     cc: WorkShop Compilers 4.2 30 Oct 1996 C 4.2

2)   OSF1 V4.0 878 alpha
     DEC C V5.6-079 on Digital UNIX V4.0 (Rev. 878)

3)   IRIX64 6.5 07151432 IP27
     MIPSpro Compilers: Version 7.2.1

4)   Linux 2.2.16 #31 SMP Thu Jun 29 14:51:26 CDT 2000 i686
     gcc version 2.95.2 19991024 (release)

On all of the above systems, math.exp(-999) returns 0.0, math.sqrt(-1)
raises an exception, and test_math.py completes successfully.

Testing-ly (not to be confused with testily) yr's,
		cgw


From tim_one@email.msn.com  Fri Oct 13 19:56:43 2000
From: tim_one@email.msn.com (Tim Peters)
Date: Fri, 13 Oct 2000 14:56:43 -0400
Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich  comparison)
In-Reply-To: <14823.22178.605732.455689@buffalo.fnal.gov>
Message-ID: <LNBBLJKPBEHFEDALKOLCIECKHLAA.tim_one@email.msn.com>

[Charles G Waldman]
> I just repeated this test, on the following 4 platforms:
>
> 1)   SunOS fsui02 5.6 Generic_105181-21 sun4u sparc SUNW,Ultra-Enterprise
>      cc: WorkShop Compilers 4.2 30 Oct 1996 C 4.2
>
> 2)   OSF1 V4.0 878 alpha
>      DEC C V5.6-079 on Digital UNIX V4.0 (Rev. 878)
>
> 3)   IRIX64 6.5 07151432 IP27
>      MIPSpro Compilers: Version 7.2.1
>
> 4)   Linux 2.2.16 #31 SMP Thu Jun 29 14:51:26 CDT 2000 i686
>      gcc version 2.95.2 19991024 (release)
>
> On all of the above systems, math.exp(-999) returns 0.0, math.sqrt(-1)
> raises an exception, and test_math.py completes successfully.

Excellent!  Note that test_math.py was augmented to verify that:

1. exp(-huge) returns 0 without exception.
2. exp(+huge) raises OverflowError.
3. sqrt(-1) raises ValueError.

None of those were reliable across platforms before, and I'm afraid there's
strong reason to suspect one or more still won't work right under Mandrake
Linux when Python is compiled with -O (this based on the output of a C
program someone posted to c.l.py yesterday).    But it's a world better than
it used to be.

> Testing-ly (not to be confused with testily) yr's,

You bet -- everyone leave testily to me on this one.  I'm bitter enough
about floating-point in stinking C for everyone combined <0.9 wink>.




From thomas@xs4all.net  Fri Oct 13 20:19:38 2000
From: thomas@xs4all.net (Thomas Wouters)
Date: Fri, 13 Oct 2000 21:19:38 +0200
Subject: [Python-Dev] can't build with threads on OSF/1
In-Reply-To: <14823.21766.733905.575290@buffalo.fnal.gov>; from cgw@fnal.gov on Fri, Oct 13, 2000 at 01:31:34PM -0500
References: <14823.10175.741638.857531@buffalo.fnal.gov> <20001013183436.B12812@xs4all.nl> <14823.21766.733905.575290@buffalo.fnal.gov>
Message-ID: <20001013211938.C12812@xs4all.nl>

--jRHKVT23PllUwdXP
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Fri, Oct 13, 2000 at 01:31:34PM -0500, Charles G Waldman wrote:
> Thomas Wouters writes:
>  > 
>  > That's a former DEC alpha, right ? Perhaps running configure with
>  > '--with-dec-threads' will solve the problem ? I'm not sure if that will work
>  > alone, so you might need '--with-dec-threads --with-threads=no' to disable
>  > 'normal' thread-checking. 

> Thank you, that indeed solves the problem.  Sorry for the noise.

No problem. When I went over the README file a few weeks back, and sent
Guido an update, this particular issue was one of the biggest problems for
me: the old README, which assumed threads were not default, was quite
adamant about using --with-dec-threads for OSF/1 and its incarnations.
Unfortunately, it doesn't say why :) And the configure script only says that
it's necessary to get threadsafe libraries.

> It would be nice if configure were smart enough to figure this out!

Configure is as smart as we make it. configure is made by autoconf, which is
moderately intelligent, and we just have to add the extra geniality to
configure.in. If the only check we need is 'does this system call itself
OSF1', we can easily add that. See the attached patch (configure.in version
only. Let me know if you need a patched configure as well, I don't know if
OSF systems come with autoconf. It's pretty large, though, and you don't
need to generate configure on the same system as you run it on. Just apply
the configure.in patch, type 'autoconf', and copy the resulting configure
script to your OSF1 machine.)

The question is, is this enough ? Will this detect all the OSF platforms
that need '-threads', and will it only add it to those platforms ? It
wouldn't be particularly nice of configure if it insisted on adding
'-threads' on platforms that don't need it, or worse, break because of it.
For instance, the patch uses 'OSF*', which might be too generic... but
'OSF1' might be too restrictive :-) A better fix would probably be to write
a test program that explicitly uses threads & the -threads arguments, but
that could fail for a large number of reasons, which doesn't mean -threads
isn't needed :P

(Configure is really amusing like that. For instance, if your compile system
is broken, like when you unpacked a new linux kernel source tree in
/usr/src/linux, but forgot to type 'make symlinks', configure will assume
the worst (every check is negative, after all.) If you're lucky, it will
complain because you miss an essential feature... If you're unlucky, it
finishes cleanly, writes the config.cache file, your compile fails, you
figure out the problem, and you keep compiling using the wrong autoconf
'settings'. And re-configuring doesn't fix it, because the config.cache file
is just fine ;)

-- 
Thomas Wouters <thomas@xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!

--jRHKVT23PllUwdXP
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="dec-thread.patch"

Index: configure.in
===================================================================
RCS file: /cvsroot/python/python/dist/src/configure.in,v
retrieving revision 1.172
diff -c -r1.172 configure.in
*** configure.in	2000/10/12 17:11:38	1.172
--- configure.in	2000/10/13 19:15:11
***************
*** 805,810 ****
--- 805,819 ----
      LIBS="$LIBS -lthread"
      LIBOBJS="$LIBOBJS thread.o"
      USE_THREAD_MODULE=""])
+ 
+     if test "$USE_THREAD_MODULE" != "#"
+     then
+         # If the above checks didn't disable threads, (at least) OSF1
+         # needs this '-threads' argument during linking.
+         case $ac_sys_system in
+         OSF*) LDLAST=-threads;;
+         esac
+     fi
  fi
  
  # Check for GC support

--jRHKVT23PllUwdXP--


From skip@mojam.com (Skip Montanaro)  Fri Oct 13 20:39:42 2000
From: skip@mojam.com (Skip Montanaro) (Skip Montanaro)
Date: Fri, 13 Oct 2000 14:39:42 -0500 (CDT)
Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich  comparison)
In-Reply-To: <LNBBLJKPBEHFEDALKOLCIECKHLAA.tim_one@email.msn.com>
References: <14823.22178.605732.455689@buffalo.fnal.gov>
 <LNBBLJKPBEHFEDALKOLCIECKHLAA.tim_one@email.msn.com>
Message-ID: <14823.25854.786347.542654@beluga.mojam.com>

    Tim> None of those were reliable across platforms before, and I'm afraid
    Tim> there's strong reason to suspect one or more still won't work right
    Tim> under Mandrake Linux when Python is compiled with -O (this based on
    Tim> the output of a C program someone posted to c.l.py yesterday).  But
    Tim> it's a world better than it used to be.

After executing

    cvs update -d .
    ./configure
    make clean
    make OPT=-O3

I get the following output from regrtest.py regarding test_math:

    % ./python Lib/test/regrtest.py test_math
    test_math
    1 test OK.

This is on a Mandrake 7.1 system.  Here are the bits I think are relevant to
identify my environment:

    % cat /etc/issue.net
    Linux Mandrake release 7.1 (helium)
    Kernel 2.2.16-9mdk on an i686
    % gcc -v
    Reading specs from /usr/lib/gcc-lib/i586-mandrake-linux/2.95.3/specs
    gcc version 2.95.3 19991030 (prerelease)
    % rpm -q -a | egrep glibc
    glibc-devel-2.1.3-15mdk
    compat-glibc-5.3-2.0.7.6mdk
    glibc-2.1.3-15mdk

If you have a C test program you'd like me to try, shoot it over.  I'll be
glad to run it and shoot back the results.

Skip


From fdrake@beopen.com  Fri Oct 13 20:41:46 2000
From: fdrake@beopen.com (Fred L. Drake, Jr.)
Date: Fri, 13 Oct 2000 15:41:46 -0400 (EDT)
Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich  comparison)
In-Reply-To: <14823.25854.786347.542654@beluga.mojam.com>
References: <14823.22178.605732.455689@buffalo.fnal.gov>
 <LNBBLJKPBEHFEDALKOLCIECKHLAA.tim_one@email.msn.com>
 <14823.25854.786347.542654@beluga.mojam.com>
Message-ID: <14823.25978.181614.85977@cj42289-a.reston1.va.home.com>

Skip Montanaro writes:
 > This is on a Mandrake 7.1 system.  Here are the bits I think are relevant to
 > identify my environment:

  The test passes for me as well on Mandrake 7.1.  Here's the
environment info:

% ./python -tt ../Lib/test/regrtest.py test_math
test_math
1 test OK.
% cat /etc/issue.net 
Welcome to %h
Linux Mandrake release 7.1 (helium)
Kernel 2.2.15-4mdk on an i686
% gcc -v
Reading specs from /usr/lib/gcc-lib/i586-mandrake-linux/2.95.3/specs
gcc version 2.95.3 19991030 (prerelease)
% rpm -qa | egrep glibc
nedit-5.1.1-1.glibc
glibc-profile-2.1.3-5mdk
glibc-2.1.3-5mdk
compat-glibc-5.3-2.0.7.6mdk
glibc-devel-2.1.3-5mdk

 > If you have a C test program you'd like me to try, shoot it over.  I'll be
 > glad to run it and shoot back the results.

  Same here...


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member



From cgw@fnal.gov  Fri Oct 13 20:52:44 2000
From: cgw@fnal.gov (Charles G Waldman)
Date: Fri, 13 Oct 2000 14:52:44 -0500 (CDT)
Subject: [Python-Dev] gcc versions (was:RE:  Possible bug (was Re: some other junk, ...))
In-Reply-To: <14823.25854.786347.542654@beluga.mojam.com>
References: <14823.22178.605732.455689@buffalo.fnal.gov>
 <LNBBLJKPBEHFEDALKOLCIECKHLAA.tim_one@email.msn.com>
 <14823.25854.786347.542654@beluga.mojam.com>
Message-ID: <14823.26636.59174.832572@buffalo.fnal.gov>

Skip Montanaro writes:

 > This is on a Mandrake 7.1 system.  Here are the bits I think are relevant to
 > identify my environment:

 >     % gcc -v
 >     Reading specs from /usr/lib/gcc-lib/i586-mandrake-linux/2.95.3/specs
 >     gcc version 2.95.3 19991030 (prerelease)

AFAIK, this version of GCC was never "blessed" by the GCC maintainers
and should not be being used for any production work.  I think
Mandrake did a bad thing by shipping this version.  Not quite as bad
as what RedHat did by shipping the completely not-for-general-use
gcc-2.96, but nonetheless still a bad thing.  When will distribution
builders learn that having a higher version number is not necessarily
a good thing?  Why do they keep second-guessing the good advice of the
GCC Steering Committee?  Sigh...

In any case, I don't think we should put effort into chasing down bugs
that are caused by bogus C compilers.  Any reports coming in from
RedHat 7.0 users or Mandrake 7.1 need to be evaluated in this light.



From fdrake@beopen.com  Fri Oct 13 20:58:53 2000
From: fdrake@beopen.com (Fred L. Drake, Jr.)
Date: Fri, 13 Oct 2000 15:58:53 -0400 (EDT)
Subject: [Python-Dev] gcc versions (was:RE:  Possible bug (was Re: some other junk, ...))
In-Reply-To: <14823.26636.59174.832572@buffalo.fnal.gov>
References: <14823.22178.605732.455689@buffalo.fnal.gov>
 <LNBBLJKPBEHFEDALKOLCIECKHLAA.tim_one@email.msn.com>
 <14823.25854.786347.542654@beluga.mojam.com>
 <14823.26636.59174.832572@buffalo.fnal.gov>
Message-ID: <14823.27005.800291.217346@cj42289-a.reston1.va.home.com>

Charles G Waldman writes:
 > AFAIK, this version of GCC was never "blessed" by the GCC maintainers
 > and should not be being used for any production work.  I think
 > Mandrake did a bad thing by shipping this version.  Not quite as bad

  I agree.

 > In any case, I don't think we should put effort into chasing down bugs
 > that are caused by bogus C compilers.  Any reports coming in from
 > RedHat 7.0 users or Mandrake 7.1 need to be evaluated in this light.

  I think Skip & I were showing that there isn't a bug for Mandrake
7.1.  I don't know what version of GCC shipped with Mandrake 7.0,
which may have been the version Tim received the report for (I recall
he said "Mandrake 7", which isn't specific).


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member



From larsga@garshol.priv.no  Fri Oct 13 21:08:05 2000
From: larsga@garshol.priv.no (Lars Marius Garshol)
Date: 13 Oct 2000 22:08:05 +0200
Subject: [XML-SIG] Re: [Python-Dev] test_minidom non-failure failure? (take 2)
In-Reply-To: <14821.60663.213246.179325@cj42289-a.reston1.va.home.com>
References: <14821.58057.358947.271778@bitdiddle.concentric.net> 	<20001012023134.A18254@glacier.fnational.com> <14821.60663.213246.179325@cj42289-a.reston1.va.home.com>
Message-ID: <m37l7cpkre.fsf@lambda.garshol.priv.no>

* Fred L. Drake, Jr.
|
| This looks like a problem in the unlink() method of the DOM.  Could
| you please check that the unlink() method is updated to handle the
| latest version of the other changes?  

It seems that the current unlink() does not remove sibling cycles.
Patch #101897 adds a line to set sibling references to None, which
seems to make regrtest.py -l happy.

--Lars M.



From prescod@prescod.net  Fri Oct 13 21:12:38 2000
From: prescod@prescod.net (Paul)
Date: Fri, 13 Oct 2000 15:12:38 -0500 (CDT)
Subject: [XML-SIG] Re: [Python-Dev] test_minidom non-failure failure?
 (take 2)
In-Reply-To: <m37l7cpkre.fsf@lambda.garshol.priv.no>
Message-ID: <Pine.LNX.4.21.0010131512240.4759-100000@amati.techno.com>

Right, I just checked in the fix to that.

 Paul Prescod

On 13 Oct 2000, Lars Marius Garshol wrote:

> 
> * Fred L. Drake, Jr.
> |
> | This looks like a problem in the unlink() method of the DOM.  Could
> | you please check that the unlink() method is updated to handle the
> | latest version of the other changes?  
> 
> It seems that the current unlink() does not remove sibling cycles.
> Patch #101897 adds a line to set sibling references to None, which
> seems to make regrtest.py -l happy.
> 
> --Lars M.
> 
> 
> _______________________________________________
> Python-Dev mailing list
> Python-Dev@python.org
> http://www.python.org/mailman/listinfo/python-dev
> 



From tim_one@email.msn.com  Fri Oct 13 21:23:31 2000
From: tim_one@email.msn.com (Tim Peters)
Date: Fri, 13 Oct 2000 16:23:31 -0400
Subject: Mandrake vs glibc (was RE: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich  comparison)
In-Reply-To: <14823.25854.786347.542654@beluga.mojam.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCMEDEHLAA.tim_one@email.msn.com>

The original source of my concern was this c.l.py post from David Cooke:

    http://www.deja.com/getdoc.xp?AN=680840594

He ran a little C program that Huaiyu Zhu had posted earlier in the thread.
According to David's results, under "Linux-Mandrake 7.1 (glibc 2.1.3) ...
without -lieee, but compiled with -O ... gcc 2.95.2.", platform exp and sqrt
*never* set errno, regardless of input.  In which case what Python does with
the platform NaN result from math.sqrt(-1.) is an accident (and probably
ends up setting errno to ERANGE itself by mistake), and an overflowing exp
would let the platform +Inf result pass thru silently.

So, if David's report is correct, and best I understand it you were all
using 7.1 too with at least some level of optimization, it's A Mystery why
CVS test_math.py succeeds on that system (its new math.sqrt(-1) test would
probably fail; its new math.exp(+huge) test would almost certainly fail).
I'm anal enough about this stuff that I'd try to figure out why if I had a
Mandrake system, but in the cosmic scheme of things I doubt it's important
enough for anyone else to burn time on.




From jeremy@beopen.com  Sat Oct 14 00:05:02 2000
From: jeremy@beopen.com (Jeremy Hylton)
Date: Fri, 13 Oct 2000 19:05:02 -0400 (EDT)
Subject: [Python-Dev] build problems large and small on FreeBSD
Message-ID: <14823.38174.143372.125749@bitdiddle.concentric.net>

I just built the latest CVS sources on a FreeBSD machine (4.1-RELEASE
FreeBSD).  There are a number of compiler warnings, all having to do
with redefinitions, plus some linker warnings and a test failure.

I don't have time to investigate further, but thought I'd let people
know in case someone else has time to take a look.

test_math failed -- overflowing exp() didn't trigger OverflowError

Python 2.0c1 (#2, Oct 13 2000, 15:50:26) 
[GCC 2.95.2 19991024 (release)] on freebsd4
Type "copyright", "credits" or "license" for more information.
>>> import math
>>> math.exp(1200)
Inf

The warnings from the linker seem harmless enough.  I don't know why
it is complaining about setkey and des_setkey.  

/usr/lib/libc.so: WARNING!  setkey(3) not present in the system!
/usr/lib/libc.so: warning: this program uses gets(), which is unsafe.
/usr/lib/libc.so: warning: mktemp() possibly used unsafely; consider using mkstemp()
/usr/lib/libc.so: WARNING!  des_setkey(3) not present in the system!
/usr/lib/libc.so: WARNING!  encrypt(3) not present in the system!
/usr/lib/libc.so: warning: tmpnam() possibly used unsafely; consider using mkstemp()
/usr/lib/libc.so: warning: this program uses f_prealloc(), which is stupid.
/usr/lib/libc.so: WARNING!  des_cipher(3) not present in the system!
/usr/lib/libc.so: warning: tempnam() possibly used unsafely; consider using mkstemp()

The compiler-time warnings look like they are caused by a configure
problem.  If so, I don't know how to fix it :-).

gcc -O3 -I../../Python/../Include -I.. -DHAVE_CONFIG_H -c ../../Python/thread.c
In file included from /usr/include/unistd.h:42,
                 from ../../Python/thread.c:28:
/usr/include/sys/unistd.h:71: warning: `_POSIX_THREADS' redefined
../config.h:136: warning: this is the location of the previous definition
In file included from ../../Python/thread.c:118:
../../Python/thread_pthread.h:59: warning: `pthread_attr_default' redefined
/usr/include/pthread.h:158: warning: this is the location of the previous definition
../../Python/thread_pthread.h:60: warning: `pthread_mutexattr_default' redefined
/usr/include/pthread.h:157: warning: this is the location of the previous definition
../../Python/thread_pthread.h:61: warning: `pthread_condattr_default' redefined
/usr/include/pthread.h:156: warning: this is the location of the previous definition

Jeremy


From jeremy@beopen.com  Sat Oct 14 00:11:10 2000
From: jeremy@beopen.com (Jeremy Hylton)
Date: Fri, 13 Oct 2000 19:11:10 -0400 (EDT)
Subject: [Python-Dev] warnings --with-pydebug
Message-ID: <14823.38542.908547.275077@bitdiddle.concentric.net>

If you configure using '--with-pydebug' you get a lot of compile-time
warnings. 

../../Python/ceval.c: In function `eval_code2':
../../Python/ceval.c:672: warning: value computed is not used
../../Python/ceval.c:675: warning: value computed is not used
../../Python/ceval.c:678: warning: value computed is not used
../../Python/ceval.c:680: warning: value computed is not used
../../Python/ceval.c:681: warning: value computed is not used
[etc.]

I assume these are caused by the definition of Py_INCREF
#define Py_INCREF(op) (_Py_RefTotal++, (op)->ob_refcnt++)

Is there some way to change this macro so that the warnings are
silenced? 

Jeremy


From thomas@xs4all.net  Sat Oct 14 00:28:19 2000
From: thomas@xs4all.net (Thomas Wouters)
Date: Sat, 14 Oct 2000 01:28:19 +0200
Subject: [Python-Dev] build problems large and small on FreeBSD
In-Reply-To: <14823.38174.143372.125749@bitdiddle.concentric.net>; from jeremy@beopen.com on Fri, Oct 13, 2000 at 07:05:02PM -0400
References: <14823.38174.143372.125749@bitdiddle.concentric.net>
Message-ID: <20001014012819.D12812@xs4all.nl>

On Fri, Oct 13, 2000 at 07:05:02PM -0400, Jeremy Hylton wrote:

> The warnings from the linker seem harmless enough.  I don't know why
> it is complaining about setkey and des_setkey.  

That's probably due to 'crypt()' being used, or some other library call that
Python uses indirectly. If you want crypt(), you need to install a seperate
DES encryption package under FreeBSD, IIRC. (It uses md5-hashes for all
crypt purposes by default, because of the US Counter-Espionage Protection
Plan or something :) If you don't want to install those, don't enable the
crypt module. There are a couple of pure python crypt() implementations
around, by the way, which always use pure DES crypt().

> /usr/lib/libc.so: warning: this program uses gets(), which is unsafe.

This one is weirdish. I don't see any gets() call in Python, so I have to
assume it's in some library or header file Python includes. A good candidate
would be readline, which has appalled me before :) but who knows :P I'm
inclined to think it isn't a library that comes with FreeBSD by default,
since they are usually pretty picky about such things. (especially if it
generates a linker warning each time it's used!)

> /usr/lib/libc.so: warning: mktemp() possibly used unsafely; consider using mkstemp()
> /usr/lib/libc.so: warning: tmpnam() possibly used unsafely; consider using mkstemp()
> /usr/lib/libc.so: warning: tempnam() possibly used unsafely; consider using mkstemp()

Yes, I've seen this before. Debian-unstable (I think ?) complains about
tmpnam() and tempnam() as well. The manpages just say 'don't use
this function, use mkstemp(3)'. It doesn't mention a reason, but it's
probably because the files/directories created by these functions are
predictable, which means you shouldn't use them for security-by-obscurity.

The mktemp() warning doesn't come from Python, looks like. Probably another
library that is included. If you really care about which it is, you'll have
to comment them out one by one (I'd suggest starting with the oldest and
least FreeBSDish one, i.e. readline :) but I don't think it's going to
really matter. Python does use 'tempnam' and 'tmpnam', but only in the
posixmodule, to provide Python versions. I'm not sure if we can just change
these functions to use mkstemp (or tempfile, see below) internally, without
breaking code, though I expect it'll be alright. What's more, these
functions are new since 1.5.2. And also, I just noticed a bug/typo in the
tempnam docstring.

The one funny bit, though, is that these three functions point to mkstemp(),
and the mkstemp() manpage reads this:

       Don't use this  function,  use  tmpfile(3)  instead.  It's
       better defined and more portable.

"When does the hurting stop ?"

> /usr/lib/libc.so: warning: this program uses f_prealloc(), which is stupid.

And this falls in the 'it wasn't us' category again.

> The compiler-time warnings look like they are caused by a configure
> problem.  If so, I don't know how to fix it :-).

> gcc -O3 -I../../Python/../Include -I.. -DHAVE_CONFIG_H -c ../../Python/thread.c
> In file included from /usr/include/unistd.h:42,
>                  from ../../Python/thread.c:28:
> /usr/include/sys/unistd.h:71: warning: `_POSIX_THREADS' redefined
> ../config.h:136: warning: this is the location of the previous definition

Hm, yes. This looks like an unfortunate clash between a Python internal
#define and a FreeBSD libc internal #define. I'm not sure if this is really
the case, maybe the Python one serves exactly the same purpose as the
FreeBSD one, but in that case, configure shouldn't redefine it. We can
either rename the #define in Python, as it's only used to determine which
thread functionality is available, or adjust the configure tests to see if
it is #defined and not redefine it if so.

(Or rather, to be sure that it defines the right thing, configure would have
to test for posix threads, check the #define (if any), and if they don't
match up, scream its head off. So perhaps renaming is the smarter thing.) On
the other hand, the fact that you only got a warning, and not an error,
means that Python isn't defining it to a different value than FreeBSD did, so
it's not really a problem. It might be a problem if Python #defines it, but
FreeBSD does not, but FreeBSD does have code that checks that #define, and
starts doing weird things...

> In file included from ../../Python/thread.c:118:
> ../../Python/thread_pthread.h:59: warning: `pthread_attr_default' redefined
> /usr/include/pthread.h:158: warning: this is the location of the previous definition
> ../../Python/thread_pthread.h:60: warning: `pthread_mutexattr_default' redefined
> /usr/include/pthread.h:157: warning: this is the location of the previous definition
> ../../Python/thread_pthread.h:61: warning: `pthread_condattr_default' redefined
> /usr/include/pthread.h:156: warning: this is the location of the previous definition

Not sure about these, because I don't know enough about the various types of
posix thread standards, and almost-posix thread almost-standards. I'm not
sure if those names are reserved in any way, but they are apparently
clashing with FreeBSD names. Or perhaps it's FreeBSD 'compatibility' code
that does the defines like Python does, too. A simple '#undef' or '#ifndef'
would suffice, here, I think, but I'm not sure.


-- 
Thomas Wouters <thomas@xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!


From thomas@xs4all.net  Sat Oct 14 00:33:59 2000
From: thomas@xs4all.net (Thomas Wouters)
Date: Sat, 14 Oct 2000 01:33:59 +0200
Subject: [Python-Dev] warnings --with-pydebug
In-Reply-To: <14823.38542.908547.275077@bitdiddle.concentric.net>; from jeremy@beopen.com on Fri, Oct 13, 2000 at 07:11:10PM -0400
References: <14823.38542.908547.275077@bitdiddle.concentric.net>
Message-ID: <20001014013359.E12812@xs4all.nl>

On Fri, Oct 13, 2000 at 07:11:10PM -0400, Jeremy Hylton wrote:
> If you configure using '--with-pydebug' you get a lot of compile-time
> warnings. 

> ../../Python/ceval.c: In function `eval_code2':
> ../../Python/ceval.c:672: warning: value computed is not used
> ../../Python/ceval.c:675: warning: value computed is not used
> ../../Python/ceval.c:678: warning: value computed is not used
> ../../Python/ceval.c:680: warning: value computed is not used
> ../../Python/ceval.c:681: warning: value computed is not used
> [etc.]

> I assume these are caused by the definition of Py_INCREF
> #define Py_INCREF(op) (_Py_RefTotal++, (op)->ob_refcnt++)

> Is there some way to change this macro so that the warnings are
> silenced? 

Yes, prefix it with '(void)':

#define Py_INCREF(op) (void)(_Py_RefTotal++, (op)->ob_refcnt++)

However, that means that the 'return value' of Py_INCREF() must never be
used anywhere. (If it does, it'll generate an error.) The return value of
Py_INCREF() is not terribly useful, though. Both in debug and in normal
mode, it expands to the refcount of the object *before* it was INCREF'd.

I still consider this kind of warning (I've seen it before, always with
macros that do several things by using the otherwise fairly useless
tuple-creator in C ;) a bit of a bug in gcc: it knows both those statements
have sideeffects, and it's obvious we want to throw away the first result,
so why worry about the second ? But at least it isn't screwing up
floating-point operations, and nobody's perfect :-)

-- 
Thomas Wouters <thomas@xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!


From huaiyu_zhu@yahoo.com  Sat Oct 14 01:25:49 2000
From: huaiyu_zhu@yahoo.com (Huaiyu Zhu)
Date: Fri, 13 Oct 2000 17:25:49 -0700 (PDT)
Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich
 comparison)
In-Reply-To: <LNBBLJKPBEHFEDALKOLCIEBCHLAA.tim_one@email.msn.com>
Message-ID: <Pine.LNX.4.10.10010131015350.3117-100000@rocket.knowledgetrack.com>

Tim,

Thank you for the explanations.  We actually agree more than it appears:

- Full IEEE 754 support in Python is good, which should allow the user to
  decide when to use raised flags and when to use Python exceptions.

- If the user default can be changed with one line of code, it does not
  matter if Python default use exceptions, even if that's not strict
  compliance in words.  The "factory default" might as well set for the
  benefit of newbies.

- Without IEEE 754 support, or with just partial support, f.p. computation
  is a mess.

Following are some contentious issues:

I am not so sure that even with 754, there would still be a great variety.
I see you giving one example: sqrt(-1) in 1.5.2.  But wasn't that caused by
extra Python checking?  I say this because errno=3D=3D0 in C.  Maybe I'm mi=
ssing
something.  Or, do you mean that glibc itself is deficient, because it
should have set the flag?

My worry concerns the decision to unify 2.0 f.p. behavior in a specific way
before full IEEE 754 support.  I understand that you say this does not coun=
t
as a changed behavior because the previous one is accidental.  But I don't
see the particular fixed subset chosen as any better than any other. I agre=
e
that I do have a choice of using -lieee, though.

It is interesting to know that someone actually relies on OverflowError to
detect underflow.  But why not let them continue that as well, given that
all of these would be available in the future anyway?

> At this point we favor forcing consistency over maintaining platform
> accidents, no matter how attached people have gotten to them; else we'll
> be stuck with them forever.

I do not understand.  Once there is full IEEE 754, everyone would have a
choice, which pretty much includes all the things people are doing now.
Before that happens, why consistency accross platform is deemed more
important than consistency accross releases?  My naive thinking is that
people port more from 1.5.2 to 2.0 than from one platform to another, isn't
it?  :-)

Following does not have much new to say, just some clarification.

You are right to emphasise that Kahan does not favor any subset of IEEE 754=
:

> >   They are called "Exceptions" because to any policy for handling them,
> >   imposed in advance upon all programmers by the computer system, some
> >   programmers will have good reason to take exception.

Yes.  And that's what's happening. :-)

> His paper "How JAVA's Floating-Point Hurts Everyone Everywhere" lists his=
 5
> main gripes about Java in bullet points at the top of page 3.  The paper
> runs on to 80 pages.  You somehow managed to miss 79.89 of them <0.4 wink=
>,
> reducing it to a bogus claim about Java that Kahan didn't make (Java has
> neither "Trap" nor "Flag" style fp exception signaling).

Thank you for correcting me on this one.  I did "glance over" all the pages=
=2E
I was somewhat puzzled by his decriptions, so I made a quick test: 1/0, and
got Exception in thread "main" java.lang.ArithmeticException: / by zero

But now I see that 1/0.0 is Infinity.  So is Math.exp(777).  And so on.
So that teaches me to test, test, test, ...

> > He told "A cautionary Tale of the Ariane 5",
>=20
> Which has nothing to do with Java -- the software in question was written=
 in
> Ada, which (unlike Java) has "Trap" style.  Why he put it in a paper abou=
t
> Java is a bit of a mystery; I write it off to rhetorical excess.

You are right it does not apply to Java.  I guess he meant that as a warnin=
g
that changing to the other side might be equally bad.

> > So do we want every Python program to bomb whenever there is a floating
> > point value outside bound and is not trapped by try/except?
>=20
> By default, yes, Guido does, but for overflow, not underflow.

That's the harsh reality I have to live with, I suppose. <0.9wink>

>  If you read
> the following section of Kahan's paper, you should have noticed that he i=
s
> *just* as critical of just returning Infs and NaNs (which is all Java doe=
s,
> and which is the accidental Python behavior you're arguing we keep in gli=
bc)
> as he is of just trapping!  His conclusion:  "Without Traps nor Flags, Ja=
va=92
> s floating-point is Dangerous":
>=20
>     Without flags, detecting rare creations of Inf and NaN before they
>     disappear requires programmed tests and branches that, besides
>     duplicating tests already performed by the hardware, slow down the
>     program and impel a programmer to make decisions prematurely in many
>     cases. Worse, a plethora of tests and branches undermines a program=
=92s
>     modularity, clarity and concurrency.
>=20
> I agree with him there wholeheartedly:  without the 754-mandated flags,
> *and* without raising exceptions, the subset of 754 remaining sucks.

That is true, but all these problems apply to "without raising flags",
whether with or without "raising exceptions".  Silent overflow forces
programmers to do extra checking if they need to find them.  Mandatory
exception forces programmer to do extra checking if they don't want them to
stop the program.  Which is more common?  It depends on programming style.
In my programs, intentional NaN is far more than NaN by mistake.

As to whether it is dangerous, I would say that if an overflow is really an
error, good programming style requires that it be detected much earlier tha=
n
the actual overflow.  I agree this cannot be expected of everyone, though.

> >> ironically, 754 is hardest to sell to those who could benefit from
> >> it the most.
>=20
> > So far the only concern from number-crunchers voiced here is that it mi=
ght
> > allow sqrt(-1)=3D=3D0, which is not the case.
>=20
> Gimme a break!  In the very msg Paul Dubois said that, he also said "Some
> people use Inf but most people want the code to STOP so they can find out
> where the INFS started.  Otherwise, two hours later you have big arrays o=
f
> Infs and no idea how it happened.".  I'm starting to drop my assumption o=
f
> good faith on your part:  what you remember and how you paraphrase (wheth=
er
> it's Paul or Kahan) is extremely selective, beyond normal bounds of
> zeal-inspired distortion.

Well, I was talking about whether anyone has shown a concern to oppose 754.
I was not talking about whether exception is prefered to flags.  See the
line I was replying to?  Actually, thinking about it, Paul was not talking
about concerns over 754, either.  So there appears zero resistence to 754
from number crunchers here.

> > Obviously we agree on the benefit of having a choice.  But we
> > have different perspective on what choice means.  Your want a choice
> > to force user to take explicit action, I want a choice to ignore these
> > events.
>=20
> No.  I want exactly the choices 754 lays out:  user-settable sticky flags
> and user-maskable exceptions.  We're not getting that for 2.0.  And we're
> *never* getting it if 2.0 doesn't do *something* to start disabusing peop=
le
> of the notion that their historical numeric platform accidents in Python
> will be faithfully preserved forever more.

Let me make it clear that we agree on all essential points about full 754
support.  The difference only exists in the period before that.  Since both
the 1.5.2 accidental behaviors and the one you want to unify to are just
subsets of the full support, it does not appear to me that disabling severa=
l
of them is a prerequisite for the full support.

> Kinda, except that each of the 5 754-defined traps must be individually
> maskable.  754 spells out what's needed.  A PEP will be required to spell
> out the Python- and C-level APIs.  I've corresponded (just -- no time now=
) a
> little with Kevin Jacobs about that offline.

Great!  If the true IEEE 754 support could come soon, all my gripe is moot.
So I'll stop disturbing you on the good work.  :-)

OK, I see that you want consistency above anything else before that good da=
y
comes.  Well, consistency is good.  Whether the price is too high is a
subjective judgement.  So I'll just use the -lieee hack for myself, then.

[On presubstitution]=20

Ok, I found it.  It looks good.

[On whether 754 default uses flags or exceptions]=20

I agree with you: the system default matters very little as long as users
can set their own defaults easily.
=20
> I expect we'll have to make InvalidOperationError a subclass of ValueErro=
r
> for that reason, when 754 support materializes.

That'll be handy.

> > My favorite is returning 1j, as MatPy does.
>=20
> Then you should use cmath.sqrt instead of math.sqrt.=20

Thanks.

Huaiyu



From skip@mojam.com (Skip Montanaro)  Sat Oct 14 01:29:06 2000
From: skip@mojam.com (Skip Montanaro) (Skip Montanaro)
Date: Fri, 13 Oct 2000 19:29:06 -0500 (CDT)
Subject: [Python-Dev] Simple xml.sax example?
Message-ID: <14823.43218.337621.157021@beluga.mojam.com>

Is there a simple example available that demonstrates how to use elements of
the new xml.sax package?  I'd prefer something that doesn't require me to
install anything other than what comes with the Python 2.0 distribution?

Thanks,

Skip



From cbarker@jps.net  Sat Oct 14 02:22:28 2000
From: cbarker@jps.net (Chris Barker)
Date: Fri, 13 Oct 2000 18:22:28 -0700
Subject: [Python-Dev] RE: [Numpy-discussion] RE: Possible bug (was Re: numpy,
 overflow, inf, ieee, and rich comparison)
References: <LNBBLJKPBEHFEDALKOLCEEACHLAA.tim_one@email.msn.com>
Message-ID: <39E7B554.29A168E3@jps.net>

Incomplete vs. non-at-all IEEE 754 support is a non argument. If you
have full IEEE support (which it seems everyone here thinks would be
good, but difficult), it is clear what you have. If not, you are not
consistent with a standard, and therefor making up your own. That being
the case, it's a matter of what we want the Python standard to be.

I, for one think that NaN and Inf are fantastic!!! I think the best
argument for them here is that it is almost impossible to do a lot of
array based calculations without them, and you can't do serious number
crunching in Python without array based calculations.

I've come to Python from MATLAB for numerics, and I really appreciated
MATLAB's way of handling all this. I don't think MATLAB has true 754
support, as I don't think you can change the behaviour, but you do get a
consistent result across platforms (including non-iee machines like the
Cray?---I have no idea). 

I have not yet heard a decent response to the question of what to do
when a single value in a large array is bad, and causes an exception.
This really does render Python essentially useless for Numerics for me.
I suspect all those number crunchers that want an exception rather than
an Inf are NOT using array-oriented languages. My goal is to dump MATLAB
for Python, but this may prevent me from doing that.

Does anyone know what other array-oriented languages use? I know what
MATLAB does:

>> exp(-777)
ans =
     0
>> exp(777)
ans =
   Inf
>> sqrt(-1)
ans =
        0 + 1.0000i

Hey! I like that! Python is dynamic, why can't we just get the actual
answer to sqrt(-1), without using cmath, that always returns a complex ?
sorry, other subjet, not meant to be raised at the moment.

>> 54/0
Warning: Divide by zero.
ans =
   Inf                   

Here we get a warning, but also a result that won't crash the
computation.

>> a = 0/0
Warning: Divide by zero.
a =
   NaN
>> b = a
b =
   NaN
>> a == b
ans =
     0            

So comparing two NaNs yields a false, as it should, and though Python
won't do it now, it could. One thing that a numerical routine should
NEVER do is give an incorrect answer. No answer is often bad, but an
incorrect one is much worse. NaN == NaN must return false.

Does anyone know what FORTRAN 90 specifies (if anything)? What other
array-oriented languages are there?

I think what MATLAB does is what Tim is calling "bad *and* incomplete
754 support" Incomplete is surely true, "bad" is clearly a matter of
opinion. It seems we have a variety of users of numerics in Python, that
I break into three broad catagories:

Casual users:
mostly doing non-numeric stuff, with the occasional calculation:
This group could use any non-cryptic handling of over/underflow, it just
doesn't matter.

Mid-level number crunchers:
This is the group I put myself in. We crunch a lot of numbers, really
like the array semantics (and speed) of NumPy, and are doing things like
graphing functions, statistical calculations, etc. We have probably only
taken one of two (at most) numerical analysis courses, and many don't
know what the heck IEE 754 is. (The one Numerical Analysis course I did
take, happened to be with Kahan, which is why I know what it is)

For this group, the incomplete IEEE support is probably the best way to
go. We're more likely to be annoyed by our whole computation stopping
because of one bad data point, than we are to be pissed off that it
didn't stop when it started to compute garbage.

Hard Core Number crunchers:
These are the folks that do things like write optimised routines for
particular architectures, adn teach numerical analysis courses. These
folks want either FULL IEEE, or plain old "classic" overflow and
underflow errors, that they can handle themselves. Do these folks really
use Python as other than a glue language? Are they really doing massive
number crunching in Python itself, rather than in C (or whatever)
extensions? If so, I'd be surprised is they didn't find Huaiyu's
argument compelling when doing array based calculations.

Tim pointed out that Python was not designed with 754 in mind, so for
2.0, what he is doing is probably our best bet, but it seems to not be
the best ultimate solution, I hope using NaN and Inf will be considered
for future versions, even if it is incomplete 754 compliance.

Note: if the ultimate goal is REAL IEEE 754 compliance, is it possible
without custom re-compiling your own interpreter? If so, is there any
chance that it will come any time soon (2.1 ?) , so we don't have to
have this discussion at all?

Thanks for all of your work on this, Python just keeps getting better!!

-Chris

-- 
Christopher Barker,
Ph.D.                                                           
cbarker@jps.net                      ---           ---           ---
http://www.jps.net/cbarker          -----@@       -----@@       -----@@
                                   ------@@@     ------@@@     ------@@@
Water Resources Engineering       ------   @    ------   @   ------   @
Coastal and Fluvial Hydrodynamics -------      ---------     --------    
------------------------------------------------------------------------
------------------------------------------------------------------------


From cgw@fnal.gov  Sat Oct 14 03:44:42 2000
From: cgw@fnal.gov (Charles G Waldman)
Date: Fri, 13 Oct 2000 21:44:42 -0500 (CDT)
Subject: [Python-Dev] RE: [Numpy-discussion] RE: Possible bug (was Re:
 numpy, overflow, inf, ieee, and rich comparison)
In-Reply-To: <39E7B554.29A168E3@jps.net>
References: <LNBBLJKPBEHFEDALKOLCEEACHLAA.tim_one@email.msn.com>
 <39E7B554.29A168E3@jps.net>
Message-ID: <14823.51354.977817.409017@buffalo.fnal.gov>

Chris Barker writes:

 > Hey! I like that! Python is dynamic, why can't we just get the actual
 > answer to sqrt(-1), without using cmath, that always returns a complex ?

You have to import the sqrt function from somewhere.  Either you
import it from math or from cmath, depending on which flavor you need.
Anybody sophisticated enough to know what complex numbers are, and
sophisticated enough to want to get complex values as a result of a
calculation, should be sophisticated enough to be able to type
"cmath".




From larsga@garshol.priv.no  Sat Oct 14 11:19:20 2000
From: larsga@garshol.priv.no (Lars Marius Garshol)
Date: 14 Oct 2000 12:19:20 +0200
Subject: [Python-Dev] Simple xml.sax example?
In-Reply-To: <14823.43218.337621.157021@beluga.mojam.com>
References: <14823.43218.337621.157021@beluga.mojam.com>
Message-ID: <m34s2fpvx3.fsf@lambda.garshol.priv.no>

* Skip Montanaro
|
| Is there a simple example available that demonstrates how to use
| elements of the new xml.sax package?

Here are a couple from an internal seminar I recently gave on this.  I
could make the slides available as well, if there is interest.

--Lars M.

--- elem_count.py

import sys

from xml.sax import make_parser, handler

class FancyCounter(handler.ContentHandler):

    def __init__(self):
        self._elems = 0
        self._attrs = 0
        self._elem_types = {}
        self._attr_types = {}

    def startElement(self, name, attrs):
        self._elems = self._elems + 1
        self._attrs = self._attrs + len(attrs)
        self._elem_types[name] = self._elem_types.get(name, 0) + 1

        for name in attrs.keys():
            self._attr_types[name] = self._attr_types.get(name, 0) + 1

    def endDocument(self):
        print "There were", self._elems, "elements."
        print "There were", self._attrs, "attributes."

        print "---ELEMENT TYPES"
        for pair in  self._elem_types.items():
            print "%20s %d" % pair

        print "---ATTRIBUTE TYPES"
        for pair in  self._attr_types.items():
            print "%20s %d" % pair

            
parser = make_parser()
parser.setContentHandler(FancyCounter())
parser.parse(sys.argv[1])

--- roundtrip.py

"""
A simple demo that reads in an XML document and spits out an equivalent,
but not necessarily identical, document.
"""

import sys, string

from xml.sax import saxutils, handler, make_parser

# --- The ContentHandler

class ContentGenerator(handler.ContentHandler):

    def __init__(self, out = sys.stdout):
        handler.ContentHandler.__init__(self)
        self._out = out

    # ContentHandler methods
        
    def startDocument(self):
        self._out.write('<?xml version="1.0" encoding="iso-8859-1"?>\n')

    def startElement(self, name, attrs):
        self._out.write('<' + name)
        for (name, value) in attrs.items():
            self._out.write(' %s="%s"' % (name, saxutils.escape(value)))
        self._out.write('>')

    def endElement(self, name):
        self._out.write('</%s>' % name)

    def characters(self, content):
        self._out.write(saxutils.escape(content))

    def ignorableWhitespace(self, content):
        self._out.write(content)
        
    def processingInstruction(self, target, data):
        self._out.write('<?%s %s?>' % (target, data))

# --- The main program

parser = make_parser()
parser.setContentHandler(ContentGenerator())
parser.parse(sys.argv[1])

--- rss2html.py

import sys

from xml.sax import make_parser, handler

# --- Templates

top = \
"""
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML>
<HEAD>
  <TITLE>%s</TITLE>
</HEAD>

<BODY>
<H1>%s</H1>
"""

bottom = \
"""
</ul>

<HR>
<ADDRESS>
Converted to HTML by sax_rss2html.py.
</ADDRESS>

</BODY>
</HTML>
"""

# --- The ContentHandler

class RSSHandler(handler.ContentHandler):

    def __init__(self, out = sys.stdout):
        handler.ContentHandler.__init__(self)
        self._out = out

        self._text = ""
        self._parent = None
        self._list_started = 0
        self._title = None
        self._link = None
        self._descr = ""

    # ContentHandler methods

    def startElement(self, name, attrs):
        if name == "channel" or name == "image" or name == "item":
            self._parent = name

        self._text = ""

    def endElement(self, name):
        if self._parent == "channel":
            if name == "title":
                self._out.write(top % (self._text, self._text))
            elif name == "description":
                self._out.write("<p>%s</p>\n" % self._text)

        elif self._parent == "item":
            if name == "title":
                self._title = self._text
            elif name == "link":
                self._link = self._text
            elif name == "description":
                self._descr = self._text
            elif name == "item":
                if not self._list_started:
                    self._out.write("<ul>\n")
                    self._list_started = 1

                self._out.write('  <li><a href="%s">%s</a> %s\n' %
                                (self._link, self._title, self._descr))

                self._title = None
                self._link = None
                self._descr = ""

        if name == "rss":
            self._out.write(bottom)
                
    def characters(self, content):
        self._text = self._text + content

# --- Main program

parser = make_parser()
parser.setContentHandler(RSSHandler())
parser.parse(sys.argv[1])



From thomas@xs4all.net  Sat Oct 14 12:05:41 2000
From: thomas@xs4all.net (Thomas Wouters)
Date: Sat, 14 Oct 2000 13:05:41 +0200
Subject: [Python-Dev] can't build with threads on OSF/1
In-Reply-To: <20001013211938.C12812@xs4all.nl>; from thomas@xs4all.net on Fri, Oct 13, 2000 at 09:19:38PM +0200
References: <14823.10175.741638.857531@buffalo.fnal.gov> <20001013183436.B12812@xs4all.nl> <14823.21766.733905.575290@buffalo.fnal.gov> <20001013211938.C12812@xs4all.nl>
Message-ID: <20001014130541.F12812@xs4all.nl>

On Fri, Oct 13, 2000 at 09:19:38PM +0200, Thomas Wouters wrote:

> On Fri, Oct 13, 2000 at 01:31:34PM -0500, Charles G Waldman wrote:

[ DEC threads (OSF1) are not automatically detected, causing a compilation
  failure on such systems ]

> > It would be nice if configure were smart enough to figure this out!

> ... we can easily add that. See the attached patch ...

Charles, if you get a chance to test this patch before monday, please do. I
think it's important to try and get the thread compiling right, now that
threads are on by default. This is going to create a lot of confusion with
OSF-users that don't read the README all the way through!

If you can't test it, perhaps we can apply it before 2.0 none the less. I
personally think there are more systems calling themselves OSF1 that do need
the -threads argument than there are that don't need it (if any) and the
patch only adds -threads if threads are really enabled. (Or perhaps change
the patch to read 'OSF1)' instead of 'OSF*)' in the case stmt, to be
conservative.)

-- 
Thomas Wouters <thomas@xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!


From Fredrik Lundh" <effbot@telia.com  Sat Oct 14 12:35:29 2000
From: Fredrik Lundh" <effbot@telia.com (Fredrik Lundh)
Date: Sat, 14 Oct 2000 13:35:29 +0200
Subject: [Python-Dev] can't build with threads on OSF/1
References: <14823.10175.741638.857531@buffalo.fnal.gov> <20001013183436.B12812@xs4all.nl> <14823.21766.733905.575290@buffalo.fnal.gov> <20001013211938.C12812@xs4all.nl> <20001014130541.F12812@xs4all.nl>
Message-ID: <009801c035d2$dc8ff4c0$3c6340d5@hagrid>

Thomas Wouters wrote:
> (Or perhaps change the patch to read 'OSF1)' instead of 'OSF*)'
> in the case stmt, to be conservative.)

are there really any others?

(that "1" is part of the original name, it's not a version number)

</F>




From thomas@xs4all.net  Sat Oct 14 12:28:20 2000
From: thomas@xs4all.net (Thomas Wouters)
Date: Sat, 14 Oct 2000 13:28:20 +0200
Subject: [Python-Dev] can't build with threads on OSF/1
In-Reply-To: <009801c035d2$dc8ff4c0$3c6340d5@hagrid>; from effbot@telia.com on Sat, Oct 14, 2000 at 01:35:29PM +0200
References: <14823.10175.741638.857531@buffalo.fnal.gov> <20001013183436.B12812@xs4all.nl> <14823.21766.733905.575290@buffalo.fnal.gov> <20001013211938.C12812@xs4all.nl> <20001014130541.F12812@xs4all.nl> <009801c035d2$dc8ff4c0$3c6340d5@hagrid>
Message-ID: <20001014132820.Y12776@xs4all.nl>

On Sat, Oct 14, 2000 at 01:35:29PM +0200, Fredrik Lundh wrote:

> Thomas Wouters wrote:
> > (Or perhaps change the patch to read 'OSF1)' instead of 'OSF*)'
> > in the case stmt, to be conservative.)

> are there really any others?

Don't know. That's why I asked it :)

> (that "1" is part of the original name, it's not a version number)

Ah, but that doesn't explain why configure.in OSF*) in some cases, and OSF1)
in others:

        case $ac_sys_system in
        OSF1)   CC=cc
                without_gcc=;;

versus

if test -z "$LDSHARED"
then
        case $ac_sys_system/$ac_sys_release in
[..]
        OSF*) LDSHARED="ld -shared -expect_unresolved \"*\"";;
[..]

I guess the OSF*) action is specific enough (most likely to lead to errors
on systems that call themselves, say, OSFORME) that we don't really have to
worry about it right now.

-- 
Thomas Wouters <thomas@xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!


From fdrake@beopen.com  Sat Oct 14 13:32:33 2000
From: fdrake@beopen.com (Fred L. Drake, Jr.)
Date: Sat, 14 Oct 2000 08:32:33 -0400 (EDT)
Subject: [Python-Dev] Simple xml.sax example?
In-Reply-To: <m34s2fpvx3.fsf@lambda.garshol.priv.no>
References: <14823.43218.337621.157021@beluga.mojam.com>
 <m34s2fpvx3.fsf@lambda.garshol.priv.no>
Message-ID: <14824.21089.373315.436615@cj42289-a.reston1.va.home.com>

Lars Marius Garshol writes:
 > Here are a couple from an internal seminar I recently gave on this.  I
 > could make the slides available as well, if there is interest.

  Could we include this in Demos/xml/ ?


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member



From cgw@fnal.gov  Sat Oct 14 14:08:30 2000
From: cgw@fnal.gov (Charles G Waldman)
Date: Sat, 14 Oct 2000 08:08:30 -0500 (CDT)
Subject: [Python-Dev] can't build with threads on OSF/1
In-Reply-To: <20001014130541.F12812@xs4all.nl>
References: <14823.10175.741638.857531@buffalo.fnal.gov>
 <20001013183436.B12812@xs4all.nl>
 <14823.21766.733905.575290@buffalo.fnal.gov>
 <20001013211938.C12812@xs4all.nl>
 <20001014130541.F12812@xs4all.nl>
Message-ID: <14824.23246.159738.283035@buffalo.fnal.gov>

Thomas Wouters writes:
 > 
 > Charles, if you get a chance to test this patch before monday, please do. I
 > think it's important to try and get the thread compiling right, now that
 > threads are on by default.

OK, I just tried it and it worked for me.  (I only tested it on one
OSF/1 system, but I suppose that's better than nothing).

Thanks for patching this, I think you are right that it will save a
lot of confusion (at least for that handful of people running this
OS!)


From m.favas@per.dem.csiro.au  Sat Oct 14 14:11:11 2000
From: m.favas@per.dem.csiro.au (Mark Favas)
Date: Sat, 14 Oct 2000 21:11:11 +0800
Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich
 comparison)
Message-ID: <39E85B6F.E95AD41F@per.dem.csiro.au>

[Huaiyu Zhu, replying to Tim...]
>It is interesting to know that someone actually relies on >OverflowError to detect underflow.  But why not let them continue that >as well, given that all of these would be available in the future >anyway?

I think I'm the someone referred to - but I _don't_ rely on this at all.
I was reporting that, on my platforms, the behaviour of exp(-666) did
_not_ change between 1.5.2 and 2.0, both of which raised an
OverflowError (for underflow). I prefer Tim's change so that exp(-huge)
will produce 0, and that exp(huge) produces an OverflowError, even
though this changes the behaviour when moving from 1.5.2 to 2.x...

[Huaiyu Zhu again]
>Before that happens, why consistency accross platform is deemed more
>important than consistency accross releases?  My naive thinking is >that people port more from 1.5.2 to 2.0 than from one platform to >another, isn't it?  :-)

In spite of the smiley, I'd have to say (politely) "Rubbish!". One of
the many attractions of Python to me _is_ cross-platform consistency -
more so than up-version consistency. In my previous life as a
computational chemist I spent a lot of effort in writing code that was
portable - indeed, we developed a pre-processor language (which spat out
FORTRAN) to try to more easily handle
OS/compiler/word-size/FP-characteristic/phase-of-moon issues. I first
came up against IEEE stuff in the early 80's, and I agree with Tim - as
a user, I hated the non-stop defaults. Mollycoddled by CDC machines, I
was used to my code stopping when I divided by zero - it usually
indicated a coding or algorithmic error. When (if) Python supports
access to masking/unmasking 754 exceptions, that'll be good - in the
meantime, from my POV, the steps taken by Tim/Guido are in the right
direction.

-- 
Mark Favas  -   m.favas@per.dem.csiro.au
CSIRO, Private Bag No 5, Wembley, Western Australia 6913, AUSTRALIA


From thomas@xs4all.net  Sat Oct 14 18:12:34 2000
From: thomas@xs4all.net (Thomas Wouters)
Date: Sat, 14 Oct 2000 19:12:34 +0200
Subject: [Python-Dev] can't build with threads on OSF/1
In-Reply-To: <14824.23246.159738.283035@buffalo.fnal.gov>; from cgw@fnal.gov on Sat, Oct 14, 2000 at 08:08:30AM -0500
References: <14823.10175.741638.857531@buffalo.fnal.gov> <20001013183436.B12812@xs4all.nl> <14823.21766.733905.575290@buffalo.fnal.gov> <20001013211938.C12812@xs4all.nl> <20001014130541.F12812@xs4all.nl> <14824.23246.159738.283035@buffalo.fnal.gov>
Message-ID: <20001014191234.G12812@xs4all.nl>

On Sat, Oct 14, 2000 at 08:08:30AM -0500, Charles G Waldman wrote:
> Thomas Wouters writes:

>  > Charles, if you get a chance to test this patch before monday, please do. I
>  > think it's important to try and get the thread compiling right, now that
>  > threads are on by default.

> OK, I just tried it and it worked for me.  (I only tested it on one
> OSF/1 system, but I suppose that's better than nothing).

Yeah, I already tested it on the ther platforms I have. Not really
necessary, since the patch is really tiny and can only really be a problem
on platforms that have a 'system name' that matches 'OSF*' but don't need
'-threads'. Thanx for testing that it works, though.

Jeremy, are you OK on checking this autoconf change in ? Is it in time for
2.0-final ?

-- 
Thomas Wouters <thomas@xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!


From jeremy@beopen.com  Sat Oct 14 23:11:30 2000
From: jeremy@beopen.com (Jeremy Hylton)
Date: Sat, 14 Oct 2000 18:11:30 -0400
Subject: [Python-Dev] RE: [Python-checkins] CVS: distutils/distutils util.py,1.55,1.56
In-Reply-To: <200010140407.VAA08029@slayer.i.sourceforge.net>
Message-ID: <AJEAKILOCCJMDILAPGJNOEDKCCAA.jeremy@beopen.com>

Greg,

Do you intend these most recent changes to be included in 2.0 final on
Monday?  Just giving you a heads up in case you didn't realize what the
release schedule is.  The only changes we should be making are critical bugs
fixes for mainline code (non-demo, tools, etc.).

Also, there is some code in the top-level of the CVS repository that hasn't
been put in the previous source tarballs; at least the C code for the
Windows installer, but maybe other things as well.  Can you recommend how to
include this in the source distribution for the final release?  We'd like to
include *all* the source code for distutils.

Jeremy




From barry@scottb.demon.co.uk  Sun Oct 15 00:28:45 2000
From: barry@scottb.demon.co.uk (Barry Scott)
Date: Sun, 15 Oct 2000 00:28:45 +0100
Subject: [Python-Dev] Python 2.0b2 note for Windows developers
In-Reply-To: <LNBBLJKPBEHFEDALKOLCGEEEHKAA.tim_one@email.msn.com>
Message-ID: <000001c03636$7f5b5600$060210ac@private>


> -----Original Message-----
> From: Tim Peters [mailto:tim_one@email.msn.com]
> Sent: 08 October 2000 20:29
> To: Barry Scott; PythonDev; Python list
> Subject: RE: [Python-Dev] Python 2.0b2 note for Windows developers
> 
> 
> [Barry]
> > 	Two requests:
> >
> > 1. Can you ship the .PDB files for the debug images so devo's
> >    do not need to build the python sources to debug extensions.
> >    And Yes I know the .ZIP will be huge. If you want a
> >    compromise only include the .PDB for python20_d.dll.
> 
> Sure!  Most .pdb files are highly compressible, and the zip size hit isn't
> anything to worry about.

	Thanks

> 
> > 2. Place the files into libs, pyd etc dirs. I had to extract
> >    the groups into the right places which is a bit tedious
> >    and error prone.
> 
> No.  If you want a directory structure that doesn't match the actual build
> directory structure, I can't read your mind, and have no reason to believe
> that the specific artificial structure you have in mind is of use to anyone

	The structure I refer to is the one used by the Python Windows installer.

> but you.  Don't be so helpless <wink>:  write a tiny Python script to move

	I comment not because I'm lazy but because it seemed that every
	developer would need to reorganise the files.

> the files where you want them after unpacking.  What I upload will be an
> exact image of the build directory structure.  Most feedback I've gotten is
> that people want exactly that, because they *want* to compile Python

	I'd not thought of that. MY assumption was that I build the release
	windows code against the files installed by the python windows installer.
	And that the debug settings would logically point into the same
	structure.

> themselves and just want to avoid jumping thru all the snaky hoops needed to
> compile the 3rd-party subprojects (from _tkinter to zlib).
> 
> alphabetically y'rs  - tim

		Barry



From MarkH@ActiveState.com  Sun Oct 15 00:53:03 2000
From: MarkH@ActiveState.com (Mark Hammond)
Date: Sun, 15 Oct 2000 10:53:03 +1100
Subject: [Python-Dev] Python 2.0b2 note for Windows developers
In-Reply-To: <000001c03636$7f5b5600$060210ac@private>
Message-ID: <ECEPKNMJLHAPFFJHDOJBGEJADNAA.MarkH@ActiveState.com>

[Tim]
> the files where you want them after unpacking.  What I upload
> will be an exact image of the build directory structure.  Most
> feedback I've gotten is that people want exactly that,
> because they *want* to compile Python

[Barry]
> I'd not thought of that.

My either.  I must admit mild surprise at that.  If people want the debug
files in the same tree as the build tree, it seems all they are trying to
do is avoid the initial huge build.  If they intend compiling, why are they
asking for the binaries?

My experience with people wanting debug binaries is that they either don't
want to, or can not build.  When people need debug binaries, they go one of
2 routes - try and find pre-built debugs, or build them themselves.  I
can't see when people ever do both.

For the last year or so, I have been making Debug builds of win32all
available to registered users.  This has always been made available in the
"install" structure - quite a bit different than the source/build
structure.  I've never been asked for anything different.

Just-FWIW ly,

Mark.



From nick@nickbower.com  Sun Oct 15 06:09:26 2000
From: nick@nickbower.com (Nick Bower)
Date: Sun, 15 Oct 2000 05:09:26 GMT
Subject: [Python-Dev] RE: [Numpy-discussion] RE: Possible bug (was Re:
 numpy,  overflow, inf, ieee, and rich comparison)
In-Reply-To: <39E7B554.29A168E3@jps.net>
References: <LNBBLJKPBEHFEDALKOLCEEACHLAA.tim_one@email.msn.com> <39E7B554.29A168E3@jps.net>
Message-ID: <20001015.5092600@cricket.>

> Does anyone know what other array-oriented languages use? I know what
> MATLAB does:

I'm an Interactive Data Language or IDL user (the Univ of Wisconsin's=20
Space Science Ceter is split down the middle between this and MatLab, =20
but python/numpy is definitely on the increase).  As you can see from=20
results below, like MatLab over/under-flows in IDL are reported but do=20
not stop execution.  This is the best (only) possible scenario for an=20
interactive arrays and visualization environment.

IDL> print, exp(-777)
      0.00000
% Program caused arithmetic error: Floating underflow
IDL> print, exp(777)
          Inf
% Program caused arithmetic error: Floating overflow
IDL> print, sqrt(-1)
         -NaN
% Program caused arithmetic error: Floating illegal operand
IDL> print, 54/0
      54
% Program caused arithmetic error: Integer divide by 0




From martin@loewis.home.cs.tu-berlin.de  Sun Oct 15 16:57:18 2000
From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Sun, 15 Oct 2000 17:57:18 +0200
Subject: [Python-Dev] Mandrake vs glibc
Message-ID: <200010151557.RAA05091@loewis.home.cs.tu-berlin.de>

> So, if David's report is correct, and best I understand it you were
> all using 7.1 too with at least some level of optimization, it's A
> Mystery why CVS test_math.py succeeds on that system (its new
> math.sqrt(-1) test would probably fail; its new math.exp(+huge) test
> would almost certainly fail).  I'm anal enough about this stuff that
> I'd try to figure out why if I had a Mandrake system, but in the
> cosmic scheme of things I doubt it's important enough for anyone
> else to burn time on.

Well, I don't know about Mandrake, but I have glibc 2.1.94 here, and I
get

Python 2.0 (#104, Oct 15 2000, 15:47:19) 
[GCC 2.95.2 19991024 (release)] on linux2
Type "copyright", "credits" or "license" for more information.
>>> import math
>>> math.sqrt(-1)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
OverflowError: math range error
>>> math.exp(800)
inf
>>> math.exp(-800)
0.0

It turns that Tcl8.3 and Tk8.3, on my system, link with -lieee. That
is implemented as

_LIB_VERSION_TYPE _LIB_VERSION = _IEEE_;

in this version of glibc, which in turn changes the behaviour of 

double __exp(double x)		/* wrapper exp */
{
	double z;
	z = __ieee754_exp(x);
	if(_LIB_VERSION == _IEEE_) return z;
	if(__finite(x)) {
	    if(x>o_threshold)
	        return __kernel_standard(x,x,6); /* exp overflow */
	    else if(x<u_threshold)
	        return __kernel_standard(x,x,7); /* exp underflow */
	}
	return z;
}

As a rationale for linking with -lieee, the Tcl/Tk configure.in offers

#       Also, Linux requires the "ieee" library for math to
#       work right (and it must appear before "-lm").

Without testing, it seems that this would give some interesting
consequences on installations where Tkinter is a shared module: the
outcome of these functions could depend on whether Tkinter is imported
or not. I can't produce such a scenario with the BeOpen binaries on a
RedHat systems; the Tcl 8.0 RPMs of RedHat include the
tcltk-8.0-ieee.patch, which removes the line 

AC_CHECK_LIB(ieee, main, [MATH_LIBS="-lieee $MATH_LIBS"])

from both Tcl's and Tk's configure.in.

Of course, the problem is not restricted to Tcl: any extension module
that links with a shared library that includes libieee.a would change
the behaviour of Python's math functions.

Regards,
Martin



From martin@loewis.home.cs.tu-berlin.de  Sun Oct 15 17:43:23 2000
From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Sun, 15 Oct 2000 18:43:23 +0200
Subject: [Python-Dev] distutils extra sources
Message-ID: <200010151643.SAA05423@loewis.home.cs.tu-berlin.de>

> Can you recommend how to include this in the source distribution for
> the final release?

Even though I was not asked, I still answer :-) I think having the
source code for the installer is essential, just so that people won't
get frightened by the potential for a Trojan Horse in front of the
gates (or, rather, the windows?-)

I'd put the installer (i.e. all of distutils/misc except for
get_metadata.py) into Tools/wininst.  (I'd actually preferred to see
the wininst sources in distutils in a different directory as well).

In case you need some descripting text as well, here's my proposal.
In Tools/README, maybe it would be

wininst    Sources for Windows installer of distutils.command.bdist_wininst.

For Tools/wininst/README, see the text below.

One complication is that invoking bdist_wininst as a program will
regenerate the module, but it expects the installer binary in
../../misc/wininst.exe; I'm not sure whether it is worth the effort to
change that for the Python distribution.

Regards,
Martin

THE WINDOWS INSTALLER
=====================

The distutils support the command bdist_wininst, which will produce a
windows auto-installing executable using the information in the setup
function. The executable consists of a user interface program,
concatenated with a zip archive of the distributed files. This
directory contains the sources of the user interface program. The
bdist_wininst command itself does not need the sources, instead, it
has an embedded copy of the installer binary file. If the installer
program is modified, bdist_wininst.py must be updated by invoking it
as a program (i.e. "python bdist_wininst.py")

Building the installer
----------------------

To build the installer, you need a copy of Microsoft Visual C++
version 6; the project file is wininst.dsp. You may also use the
executable compressor UPX, which is available from
http://upx.tsx.org. UPX must be installed into c:\util. Using UPX is
not strictly required - it just reduces the size of the installation
program itself.

Using the bdist_wininst command
-------------------------------
To create an binary distribution of your package for Windows, simply
invoke "python setup.py bdist_wininst" in your package directory. If
your package does not contain C modules, you may invoke this command
on any system; if it does contain C modules, bdist_wininst will need
the C compiler used to build Python (typically MSVC++). It will not
need MSVC++ or UPX to build the setup program.

To build the ZIP file contained in the installer, bdist_wininst will
first try an external zip program (zip.exe) that understands the -rq
option, such as Info-ZIP
(http://www.info-zip.org/pub/infozip/Zip.html). If no such program is
found, it will next try the zipfile module, which is available if
Python was build with zlib support.



From larsga@garshol.priv.no  Sun Oct 15 18:52:16 2000
From: larsga@garshol.priv.no (Lars Marius Garshol)
Date: 15 Oct 2000 19:52:16 +0200
Subject: [Python-Dev] Simple xml.sax example?
In-Reply-To: <14824.21089.373315.436615@cj42289-a.reston1.va.home.com>
References: <14823.43218.337621.157021@beluga.mojam.com> 	<m34s2fpvx3.fsf@lambda.garshol.priv.no> <14824.21089.373315.436615@cj42289-a.reston1.va.home.com>
Message-ID: <m3vguunga7.fsf@lambda.garshol.priv.no>

* Lars Marius Garshol
|
| Here are a couple from an internal seminar I recently gave on this.
| I could make the slides available as well, if there is interest.

* Fred L. Drake, Jr.
| 
| Could we include this in Demos/xml/ ?

Sure.  Do whatever you like with them.  

--Lars M.



From hinsen@cnrs-orleans.fr  Sun Oct 15 20:04:27 2000
From: hinsen@cnrs-orleans.fr (Konrad Hinsen)
Date: Sun, 15 Oct 2000 21:04:27 +0200
Subject: [Python-Dev] RE: [Numpy-discussion] RE: Possible bug (was Re: numpy,
 overflow, inf, ieee, and rich comparison)
In-Reply-To: <39E7B554.29A168E3@jps.net> (message from Chris Barker on Fri, 13
 Oct 2000 18:22:28 -0700)
References: <LNBBLJKPBEHFEDALKOLCEEACHLAA.tim_one@email.msn.com> <39E7B554.29A168E3@jps.net>
Message-ID: <200010151904.VAA32561@chinon.cnrs-orleans.fr>

> I've come to Python from MATLAB for numerics, and I really appreciated
> MATLAB's way of handling all this. I don't think MATLAB has true 754

MATLAB is fine for simple interactive data processing, and its
behaviour is adapted to this task. I don't think anyone would use
MATLAB for developing complex algorithms, its programming language
isn't strong enough for that. Python is, so complex algorithms have to
be considered as well. And for that kind of application, continuing a
calculation with Infs and NaNs is a debugging nightmare.

> I have not yet heard a decent response to the question of what to do
> when a single value in a large array is bad, and causes an exception.

I'd like to have at least the option of raising an exception in that
case. Note that this is not what NumPy does today.

> >> sqrt(-1)
> ans =
>	   0 + 1.0000i
>
> Hey! I like that! Python is dynamic, why can't we just get the actual
> answer to sqrt(-1), without using cmath, that always returns a complex ?

For the same reason that makes 2/3 return zero instead of a float
division result. Like C or Fortran, Python treats integers, floats,
and complex numbers as different data types. And the return type of a
function should depend only on the types, but not the values, of its
parameters (for consistency, not because of any implementational
limitation). So sqrt(a) for a of type float can either always return a
float (math, Numeric) and crash for negative arguments, or always
return a complex (cmath).

The "right" solution, in my opinion, would be to have a single
"number" type of which integers, float, and complex numbers are simply
different internal representations. But such a change cannot be
introduced without breaking a lot of code.

Konrad.
--
-------------------------------------------------------------------------------
Konrad Hinsen                            | E-Mail: hinsen@cnrs-orleans.fr
Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24
Rue Charles Sadron                       | Fax:  +33-2.38.63.15.17
45071 Orleans Cedex 2                    | Deutsch/Esperanto/English/
France                                   | Nederlands/Francais
-------------------------------------------------------------------------------


From tim_one@email.msn.com  Sun Oct 15 20:22:09 2000
From: tim_one@email.msn.com (Tim Peters)
Date: Sun, 15 Oct 2000 15:22:09 -0400
Subject: [Python-Dev] Python 2.0b2 note for Windows developers
In-Reply-To: <000001c03636$7f5b5600$060210ac@private>
Message-ID: <LNBBLJKPBEHFEDALKOLCCEFKHLAA.tim_one@email.msn.com>

[Tim]
> the files where you want them after unpacking.  What I upload
> will be an exact image of the build directory structure.  Most
> feedback I've gotten is that people want exactly that,
> because they *want* to compile Python

[Barry Scott]
> I'd not thought of that.

[Mark Hammond]
> My either.  I must admit mild surprise at that.

Not me, because this is the Python core:  extension writers often have
problems with their use of the Python C API, and the core is what supplies
that.  It's not surprising that they want to, e.g., drop some printfs into
Python itself to see what's going on.  Then they need to recompile Python.
Plus that all the examples and instructions for building extensions assume
you're working in a build-- not a release --tree.

> If people want the debug files in the same tree as the build tree,

Some people, not all; by my informal count so far, "most", but it's like 2
or 3 to 1 -- and that's not only a ratio but a grand-total count.

> it seems all they are trying to do is avoid the initial huge build.  If
> they intend compiling, why are they asking for the binaries?

The "huge initial build" is no more than a few minutes, *provided* that they
don't have to crawl over the web too to get source for, and figure out what
to do with, the subprojects w/ a 3rd-party component (_tkinter, bsddb,
pyexpat and zlib).  Dealing with the latter for the first time can consume
hours.

> My experience with people wanting debug binaries is that they either don't
> want to, or can not build.

If they can't build, it's hard to take their claim to be developing
extension modules seriously <wink>.

> ...
> For the last year or so, I have been making Debug builds of win32all
> available to registered users.  This has always been made available in
> the "install" structure - quite a bit different than the source/build
> structure.  I've never been asked for anything different.

Were you *asked* for even that much?  Barry's was the first request Guido
recalls ever getting.  It sounded reasonable to me to supply *something*, so
I did.  But the download stats for this zip file suggest it's not popular
enough to be worth  arguing over.  Still, I've gotten a little feedback on
it, and most people seem to be happy.  Not all developers want the same
thing, and a flat .zip file with no internal directory structure is
maximally flexible.

If a handful of other Windows developers pop up who swear they can't live
with a flat file, and can't bear to write a little Python or .bat script to
move the files to where they want them, and swear they want some directory
structure that's a fuzzy generalization of the Windows install structure,
and swear they all want the same fuzzy generalization (e.g., where do they
want the .pdb files?  there are none in the install tree now), then, sure,
I'll make the *other* peoples' lives a bit more difficult by default.  I'm
not going to ship two (or more!) of these things, though.

view-it-as-a-chance-for-activestate-to-take-over<wink>-ly y'rs  - tim




From tim_one@email.msn.com  Sun Oct 15 21:35:27 2000
From: tim_one@email.msn.com (Tim Peters)
Date: Sun, 15 Oct 2000 16:35:27 -0400
Subject: [Python-Dev] RE: [Numpy-discussion] RE: Possible bug (was Re: numpy,  overflow, inf, ieee, and rich comparison)
In-Reply-To: <200010151904.VAA32561@chinon.cnrs-orleans.fr>
Message-ID: <LNBBLJKPBEHFEDALKOLCGEFLHLAA.tim_one@email.msn.com>

[cbarker@jps.net]
>> I've come to Python from MATLAB for numerics, and I really appreciated
>> MATLAB's way of handling all this. I don't think MATLAB has true 754 ...

[Konrad Hinsen]
> MATLAB is fine for simple interactive data processing, and its
> behaviour is adapted to this task. I don't think anyone would use
> MATLAB for developing complex algorithms, its programming language
> isn't strong enough for that. Python is, so complex algorithms have to
> be considered as well. And for that kind of application, continuing a
> calculation with Infs and NaNs is a debugging nightmare.

A non-constructive (because futile) speculation:  the first time I saw what
754 was intending to do, my immediate reaction was "hmm -- the exponent
field is too narrow!".  With a max (double) val in the ballpark of 1e300,
you get an infinity as soon as you square something as small as 1e150, and
once you get a few infinities, NaNs are sure to follow (due to Inf-Inf and
Inf/Inf).  The dynamic range for 754 singles is much smaller still.

There's no doubt about Cray arithmetic being hard to live with, but while
Mr. Cray didn't worry about proper rounding, he did devote 15 bits to Cray's
exponent field (vs. 11 for 754).  As a result, overflows were generally a
non-issue on Cray boxes, and *nobody* complained (in my decade there) about
Cray HW raising a fatal exception if one occurred.

In return, you got only 48 bits of precision (vs. 53 for 754).  But, for
most physical problems, how accurate are the inputs?  10 bits on a good day,
20 bits on a great day?  Crays worked despite their sloppy numerics because,
for most problems to which they were applied, they carried more than twice
the precision *and* dynamic range than the final results needed.

>> I have not yet heard a decent response to the question of what to do
>> when a single value in a large array is bad, and causes an exception.

I'd usually trace back and try to figure out how it got "bad" to begin with
...

> I'd like to have at least the option of raising an exception in that
> case. Note that this is not what NumPy does today.

Does NumPy use the fpectl module?  I suppose not.  LLNL contribued that
code, but we hear very little feedback on it.  It arranges to (in
platform-dependent ways) convert the 754 overflow, divide-by-0 and
invalid-operation signals into Python exceptions.  In core Python, this is
accomplished at the extraordinary expense of doing a setjmp before, and a
function call + double->int conversion after, every single fp operation.  A
chief problem is that SIGFPE is the only handle C gives us on fp "errors",
and the C std does not allow returning from a SIGFPE handler (the result of
trying to is undefined, and indeed varies wildly across platforms); so if
you want to regain control, you have to longjmp out of the handler.

The NumPy implementation could use the PyFPE_START_PROTECT and
PyFPE_END_PROTECT macros to brackete entire array operations, though, and so
pay for the setjmp etc only once per array op.  This is difficult stuff, but
doable.


>> >> sqrt(-1)
>> ans =
>>	   0 + 1.0000i
>>
>> Hey! I like that! Python is dynamic, why can't we just get the actual
>> answer to sqrt(-1), without using cmath, that always returns a complex ?

> For the same reason that makes 2/3 return zero instead of a float
> division result. Like C or Fortran, Python treats integers, floats,
> and complex numbers as different data types.

You know I'm in general agreement with you on this one, but I have to draw a
distinction here:  Guido thinks that 2/3 returning 0 was a design mistake,
but not that math.sqrt(-1) raising an exception is a mistake.  Most Python
users won't know what to do with a complex number, so it's "an error" to
them.  I would like to view this in P3K (if not earlier) as being akin to
754 exceptions:  some people are delighted to have 1e300**2 return +Inf,
while others want to see OverflowError instead, and still others want to see
+Inf *and* have a sticky flag set saying "an overflow occurred".  We could
treat f(x) (for f == sqrt and everything else) the same way wrt to a new
ComplexResultFromNonComplexInputsError:  define "non-stop" complex results,
let the user choose whether to do nonstop or raise an exception, and a
supply a sticky flag saying whether or not any complex results were
generated from non-complex inputs.

> ...
> The "right" solution, in my opinion, would be to have a single
> "number" type of which integers, float, and complex numbers are simply
> different internal representations. But such a change cannot be
> introduced without breaking a lot of code.

The current distinction between ints and longs (unbounded ints) should also
get swallowed by this.  A way to get from here to there is especially
irksome at the C API level, since, e.g., many C API functions pass Python
ints as C longs directly.  A smaller number pass Python floats as C doubles
directly.

it's-wonderful-that-p3k-will-solve-everything<wink>-ly y'rs  - tim




From MarkH@ActiveState.com  Mon Oct 16 00:49:19 2000
From: MarkH@ActiveState.com (Mark Hammond)
Date: Mon, 16 Oct 2000 10:49:19 +1100
Subject: [Python-Dev] Wierd buffer "add" behaviour.
Message-ID: <ECEPKNMJLHAPFFJHDOJBIEJMDNAA.MarkH@ActiveState.com>

I just struck this, and wonder if it is intentional:

* Adding 2 buffer objects together yields a string.  Fair enough.
* Adding a buffer and a string yields a type error!  Eeek.

This yields the following strange behaviour:

>>> a=buffer('a')
>>> a+a
'aa'
>>> a+a+a
Traceback (innermost last):
  File "<interactive input>", line 1, in ?
TypeError: cannot add type "buffer" to string
>>> 

That doesnt seem correct to me?

Mark.


From rob@hooft.net  Mon Oct 16 06:39:13 2000
From: rob@hooft.net (Rob W. W. Hooft)
Date: Mon, 16 Oct 2000 07:39:13 +0200 (CEST)
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib calendar.py,1.17,1.18
In-Reply-To: <200010091242.FAA02671@slayer.i.sourceforge.net>
References: <200010091242.FAA02671@slayer.i.sourceforge.net>
Message-ID: <14826.38017.352907.716552@temoleh.chem.uu.nl>

Just checking my E-mail coming back from holidays, I see:

  diff -C2 -r1.17 -r1.18
  *** calendar.py 2000/08/30 14:01:28     1.17
  --- calendar.py 2000/10/09 12:42:04     1.18
  ***************
  *** 55,60 ****
    def leapdays(y1, y2):
        """Return number of leap years in range [y1, y2).
  !        Assume y1 <= y2 and no funny (non-leap century) years."""
  !     return (y2+3)/4 - (y1+3)/4

    def weekday(year, month, day):
  --- 55,62 ----
    def leapdays(y1, y2):
        """Return number of leap years in range [y1, y2).
  !        Assume y1 <= y2."""
  !     y1 -= 1
  !     y2 -= 1
  !     return (y2/4 - y1/4) - (y2/100 - y1/100) + (y2/400 - y1/400)

    def weekday(year, month, day):

I am worried about the use of "-=" here. The code basically says: "if the
arguments are mutable numeric types, I'd like to modify them in place". In
c.l.py it has been stressed multiple times that "-=" is not the same as
"=   -". I think this is clearly a place where "=   -" is preferable over
"-=". Even though you might think people will always call this with 
python integers, you can never be sure enough.

Rob

-- 
=====   rob@hooft.net          http://www.hooft.net/people/rob/  =====
=====   R&D, Nonius BV, Delft  http://www.nonius.nl/             =====
===== PGPid 0xFA19277D ========================== Use Linux! =========


From pf@artcom-gmbh.de  Mon Oct 16 08:23:11 2000
From: pf@artcom-gmbh.de (Peter Funk)
Date: Mon, 16 Oct 2000 09:23:11 +0200 (MEST)
Subject: [Python-Dev] gettext may fail to find .mo file (was Re: [PATCH] gettext)
In-Reply-To: <lblmvq8czj.fsf@mask.tf.hut.fi>
Message-ID: <m13l4c3-000Dm8C@artcom0.artcom-gmbh.de>

Hi Ulf,

Ulf Betlehem:
[...]
>         ok, I compiled 2.0c1 and tried gettext. Now, there seems to be
>         a bug in the "normalize and expand" code that can prevent
>         gettext from finding an existing .mo file. The normalization
>         is done using a dictionary and therefore the languages get
>         reordered (as dict keys do). Later when selecting language the
>         function returns None if 'C' happens to come before the
>         required languages. I've included a patch to fix this.

Your patch looks good to me.  Thanks for taking the time to test and 
contributing the patch.  I've submitted your bug report and your 
patch to sourceforge.

See:
https://sourceforge.net/bugs/?func=detailbug&bug_id=116964&group_id=5470
https://sourceforge.net/patch/?func=detailpatch&patch_id=101928&group_id=5470

Regards, Peter
P.S.: Cc to python-dev
-- 
Peter Funk, Oldenburger Str.86, D-27777 Ganderkesee, Germany, Fax:+49 4222950260
office: +49 421 20419-0 (ArtCom GmbH, Grazer Str.8, D-28359 Bremen)


From mal@lemburg.com  Mon Oct 16 08:50:22 2000
From: mal@lemburg.com (M.-A. Lemburg)
Date: Mon, 16 Oct 2000 09:50:22 +0200
Subject: [Python-Dev] Wierd buffer "add" behaviour.
References: <ECEPKNMJLHAPFFJHDOJBIEJMDNAA.MarkH@ActiveState.com>
Message-ID: <39EAB33E.35B72EA4@lemburg.com>

Mark Hammond wrote:
> 
> I just struck this, and wonder if it is intentional:
> 
> * Adding 2 buffer objects together yields a string.  Fair enough.
> * Adding a buffer and a string yields a type error!  Eeek.

This just seems plain wrong. Adding two buffers should yield
a new buffer -- in the long run, buffers should replace strings
wrt to holding binary data. If not even buffers themselves
implement this idea, I don't see any perspective for ever getting
there...
 
> This yields the following strange behaviour:
> 
> >>> a=buffer('a')
> >>> a+a
> 'aa'
> >>> a+a+a
> Traceback (innermost last):
>   File "<interactive input>", line 1, in ?
> TypeError: cannot add type "buffer" to string
> >>>
> 
> That doesnt seem correct to me?

Neither to me.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/


From thomas.heller@ion-tof.com  Mon Oct 16 10:14:49 2000
From: thomas.heller@ion-tof.com (Thomas Heller)
Date: Mon, 16 Oct 2000 11:14:49 +0200
Subject: [Python-Dev] Wierd buffer "add" behaviour.
References: <ECEPKNMJLHAPFFJHDOJBIEJMDNAA.MarkH@ActiveState.com>
Message-ID: <037601c03751$88ecc1b0$e000a8c0@thomasnotebook>

IMHO, the whole buffer interface is weird.

- Only the Buffer_FromObject() function is exposed to the python
level (as buffer()), the other functions are missing. This
means that one could only use the buffer interface in
extension modules. Was this intentional?

- No way a python class can expose the buffer interface

- There is a bug in the buffer interface (which
prevented recently that I could use buffer objects
at all, I had to implement my own)

PyObject *base = PyBuffer_New(100);
PyObject *buffer = PyBuffer_FromObject(base, 0, 100);
Py_DECREF(base);

After this code is executed,
buffer points to deallocated memory (because
buffer does not hold a reference to base anymore).

(Guido classified this as a wish, but at least
it contradicts the documentation)

Thomas



From MarkH@ActiveState.com  Mon Oct 16 10:38:26 2000
From: MarkH@ActiveState.com (Mark Hammond)
Date: Mon, 16 Oct 2000 20:38:26 +1100
Subject: [Python-Dev] Wierd buffer "add" behaviour.
In-Reply-To: <037601c03751$88ecc1b0$e000a8c0@thomasnotebook>
Message-ID: <ECEPKNMJLHAPFFJHDOJBMEKHDNAA.MarkH@ActiveState.com>

> IMHO, the whole buffer interface is weird.

I'm not sure that weird is the correct term for your points (it is for my
spelling, though :-)

> - Only the Buffer_FromObject() function is exposed to the
...
> - No way a python class can expose the buffer interface

These are simply oversights, I would suggest.  Nothing in the design
prevents this.

> - There is a bug in the buffer interface (which
> prevented recently that I could use buffer objects
> at all, I had to implement my own)

This looks like quite a simple bug.  bufferobject.c, line 77:

	/* if the base object is another buffer, then "deref" it */
	if ( PyBuffer_Check(base) )
		base = ((PyBufferObject *)base)->b_base;

if the condition was changed to:

	if ( PyBuffer_Check(base) && ((PyBufferObject *)base)->b_base)

Then I think this one would be solved?

A more serious design flaw is the one Fredrik pointed out quite some time
ago.  If you have (eg.) an "array" object and query for its buffer, life is
good.  If the array then resizes itself, your pointer is now dangling.  The
simplest solution to this is probably to simply define the lifetimes of
these pointers as very very short ;-)

Mark.



From mal@lemburg.com  Mon Oct 16 11:14:46 2000
From: mal@lemburg.com (M.-A. Lemburg)
Date: Mon, 16 Oct 2000 12:14:46 +0200
Subject: [Python-Dev] Wierd buffer "add" behaviour.
References: <ECEPKNMJLHAPFFJHDOJBMEKHDNAA.MarkH@ActiveState.com>
Message-ID: <39EAD516.7EA34C20@lemburg.com>

Mark Hammond wrote:
> [Problems with the buffer interface]
> If you have (eg.) an "array" object and query for its buffer, life is
> good.  If the array then resizes itself, your pointer is now dangling.  The
> simplest solution to this is probably to simply define the lifetimes of
> these pointers as very very short ;-)

...or disable the buffer interface for mutable types altogether !

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/


From gstein@lyra.org  Mon Oct 16 14:01:26 2000
From: gstein@lyra.org (Greg Stein)
Date: Mon, 16 Oct 2000 06:01:26 -0700
Subject: [Python-Dev] Wierd buffer "add" behaviour.
In-Reply-To: <39EAB33E.35B72EA4@lemburg.com>; from mal@lemburg.com on Mon, Oct 16, 2000 at 09:50:22AM +0200
References: <ECEPKNMJLHAPFFJHDOJBIEJMDNAA.MarkH@ActiveState.com> <39EAB33E.35B72EA4@lemburg.com>
Message-ID: <20001016060126.X347@lyra.org>

On Mon, Oct 16, 2000 at 09:50:22AM +0200, M.-A. Lemburg wrote:
> Mark Hammond wrote:
>...
> > This yields the following strange behaviour:
> > 
> > >>> a=buffer('a')
> > >>> a+a
> > 'aa'
> > >>> a+a+a
> > Traceback (innermost last):
> >   File "<interactive input>", line 1, in ?
> > TypeError: cannot add type "buffer" to string
> > >>>
> > 
> > That doesnt seem correct to me?
> 
> Neither to me.

It is caused by the non-commutative aspect of Python types. You end up with
a string, and that type doesn't know how to add a buffer to itself.

Ideally, it might be nice to allow a string to append any object that
exports the buffer-interface. But when somebody goes and writes
"abc"+my_array ... hoo boy, will we hear complaints.

The alternative is to allow the buffer to resolve the type conflict and do
the appending within the buffer code.

Of course, the choice of returning a string (from buf+buf) rather than a
buffer was arguably the wrong choice.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/


From guido@python.org  Mon Oct 16 15:30:44 2000
From: guido@python.org (Guido van Rossum)
Date: Mon, 16 Oct 2000 09:30:44 -0500
Subject: [Python-Dev] mutable integers
In-Reply-To: Your message of "Mon, 16 Oct 2000 07:39:13 +0200."
 <14826.38017.352907.716552@temoleh.chem.uu.nl>
References: <200010091242.FAA02671@slayer.i.sourceforge.net>
 <14826.38017.352907.716552@temoleh.chem.uu.nl>
Message-ID: <200010161430.JAA28885@cj20424-a.reston1.va.home.com>

Rob W. W. Hooft:

> Just checking my E-mail coming back from holidays, I see:
[...]
>     def leapdays(y1, y2):
>         """Return number of leap years in range [y1, y2).
>   !        Assume y1 <= y2."""
>   !     y1 -= 1
>   !     y2 -= 1
>   !     return (y2/4 - y1/4) - (y2/100 - y1/100) + (y2/400 - y1/400)
> 
> I am worried about the use of "-=" here. The code basically says: "if the
> arguments are mutable numeric types, I'd like to modify them in place". In
> c.l.py it has been stressed multiple times that "-=" is not the same as
> "=   -". I think this is clearly a place where "=   -" is preferable over
> "-=". Even though you might think people will always call this with 
> python integers, you can never be sure enough.

Hmm...  Your fear sounds a little paranoid for this particular case,
but I can't say that I totally disagree in general.  This is
definitely something to keep in mind when writing polymorphic
functions for which a NumPy array might be an acceptable input
argument.

I don't think it's worth checking in a patch in this case.

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


From hinsen@cnrs-orleans.fr  Mon Oct 16 16:52:43 2000
From: hinsen@cnrs-orleans.fr (Konrad Hinsen)
Date: Mon, 16 Oct 2000 17:52:43 +0200
Subject: [Python-Dev] RE: [Numpy-discussion] RE: Possible bug (was Re: numpy,  overflow, inf, ieee, and rich comparison)
In-Reply-To: <LNBBLJKPBEHFEDALKOLCGEFLHLAA.tim_one@email.msn.com>
References: <LNBBLJKPBEHFEDALKOLCGEFLHLAA.tim_one@email.msn.com>
Message-ID: <200010161552.RAA02685@chinon.cnrs-orleans.fr>

> > I'd like to have at least the option of raising an exception in that
> > case. Note that this is not what NumPy does today.
> 
> Does NumPy use the fpectl module?  I suppose not.  LLNL contribued that

No. Perhaps it should, but it doesn't make sense unless fpectl works
on a large number of platforms. I confess I have never looked at it. I
want my code to be portable, so I don't even consider using packages
that aren't.

> > For the same reason that makes 2/3 return zero instead of a float
> > division result. Like C or Fortran, Python treats integers, floats,
> > and complex numbers as different data types.
> 
> You know I'm in general agreement with you on this one, but I have to draw a
> distinction here:  Guido thinks that 2/3 returning 0 was a design mistake,
> but not that math.sqrt(-1) raising an exception is a mistake.  Most Python
> users won't know what to do with a complex number, so it's "an error" to
> them.

Well, that would be a good occasion to learn about complex numbers! I
remember having learned about generalized inverses by using APL in
high school (in a very similar way: I was amazed that it could invert
non-square matrices), and that turned out to be very useful knowledge
later on. Perhaps that's a topic for the EDU-SIG...

Anyway, I don't care what math.sqrt(-1) does, but I would definitely
prefer Numeric.sqrt(-1) to return a complex result. And I think that
someone who uses NumPy has probably heard about complex numbers.


> I would like to view this in P3K (if not earlier) as being akin to
> 754 exceptions:  some people are delighted to have 1e300**2 return +Inf,
> while others want to see OverflowError instead, and still others want to see
> +Inf *and* have a sticky flag set saying "an overflow occurred".  We could
> treat f(x) (for f == sqrt and everything else) the same way wrt to a new
> ComplexResultFromNonComplexInputsError:  define "non-stop" complex results,
> let the user choose whether to do nonstop or raise an exception, and a
> supply a sticky flag saying whether or not any complex results were
> generated from non-complex inputs.

There is, however, one difference: in properly debugged production
code, there should be no overflow situations, so it doesn't matter
much how they are treated. Complex number can (do!) occur in
production code, but there could also be production code relying on
exceptions for sqrt(-1) (e.g. for input error checking). Therefore a
program using several libraries might be impossible to run with either
setting.

Since this concerns only the math module, I'd prefer to keep separate
module versions for the two cases, which can be used in parallel.

> > The "right" solution, in my opinion, would be to have a single
> > "number" type of which integers, float, and complex numbers are simply
> > different internal representations. But such a change cannot be
> > introduced without breaking a lot of code.
> 
> The current distinction between ints and longs (unbounded ints) should also
> get swallowed by this.  A way to get from here to there is especially
> irksome at the C API level, since, e.g., many C API functions pass Python
> ints as C longs directly.  A smaller number pass Python floats as C doubles
> directly.

I don't see the problem in that direction, it's rather C API functions
that *return* numbers in C data types that would be difficult to
adapt. But then, why should be C API not be allowed in P3K?

it's-wonderful-that-anything-may-be-changed-in-p3k'ly
  Konrad.
-- 
-------------------------------------------------------------------------------
Konrad Hinsen                            | E-Mail: hinsen@cnrs-orleans.fr
Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24
Rue Charles Sadron                       | Fax:  +33-2.38.63.15.17
45071 Orleans Cedex 2                    | Deutsch/Esperanto/English/
France                                   | Nederlands/Francais
-------------------------------------------------------------------------------


From guido@python.org  Mon Oct 16 19:08:07 2000
From: guido@python.org (Guido van Rossum)
Date: Mon, 16 Oct 2000 13:08:07 -0500
Subject: [Python-Dev] The buffer interface
In-Reply-To: Your message of "Mon, 16 Oct 2000 06:01:26 MST."
 <20001016060126.X347@lyra.org>
References: <ECEPKNMJLHAPFFJHDOJBIEJMDNAA.MarkH@ActiveState.com> <39EAB33E.35B72EA4@lemburg.com>
 <20001016060126.X347@lyra.org>
Message-ID: <200010161808.NAA32318@cj20424-a.reston1.va.home.com>

The buffer interface is one of the most misunderstood parts of
Python.  I believe that if it were PEPped today, it would have a hard
time getting accepted in its current form.

There are also two different parts that are commonly referred by this
name: the "buffer API", which is a C-only API, and the "buffer
object", which has both a C API and a Python API.

Both were largely proposed, implemented and extended by others, and I
have to admit that I'm still uneasy with defending them, especially
the buffer object.  Both are extremely implementation-dependent (in
JPython, neither makes much sense).

The Buffer API
--------------

The C-only buffer API was originally intended to allow efficient
binary I/O from and (in some cases) to large objects that have a
relatively well-understood underlying memory representation.  Examples
of such objects include strings, array module arrays, memory-mapped
files, NumPy arrays, and PIL objects.

It was created with the desire to avoid an expensive memory-copy
operation when reading or writing large arrays.  For example, if you
have an array object containing several millions of double precision
floating point numbers, and you want to dump it to a file, you might
prefer to do the I/O directly from the array's memory buffer rather
than first copying it to a string.  (You lose portability of the data,
but that's often not a problem the user cares about in these cases.)

An alternative solution for this particular problem was consdered:
object types in need of this kind of efficient I/O could define their
own I/O methods, thereby allowing them to hide their internal
representation.  This was implemented in some cases (e.g. the array
module has read() and write() methods) but rejected, because a
simple-minded implementation of this approach would not work with
"file-like" objects (e.g. StringIO files).  It was deemed important
that file-like objects would not place restrictions on the kind of
objects that could interact with them (compared to real file objects).

A possible solution would have been to require that each object
implementing its own read and write methods should support both
efficient I/O to/from "real" file objects and fall-back I/O to/from
"file-like" objects.  The fall-back I/O would have to convert the
object's data to a string object which would then be passed to the
write() method of the file-like object.  This approach was rejected
because it would make it impossible to implement an alternative file
object that would be as efficient as the real file object, since large
object I/O would be using the inefficient fallback interface.

To address these issues, we decided to define an interface that would
let I/O operations ask the objects where their data bytes are in
memory, so that the I/O can go directly to/from the memory allocated
by the object.  This is the classic buffer API.  It has a read-only
and a writable variant -- the writable variant is for mutable objects
that will allow I/O directly into them.  Because we expected that some
objects might have an internal representation distributed over a
(small) number of separately allocated pieces of memory, we also added
the getsegcount() API.  All objects that I know support the buffer API
return a segment count of 1, and most places that use the buffer API
give up if the segment count is larger; so this may be considered as
an unnecessary generalization (and source of complexity).

The buffer API has found significant use in a way that wasn't
originally intended: as a sort of informal common base class for
string-like objects in situations where a char[] or char* type must be
passed (in a read-only fashion) to C code.  This is in fact the most
common use of the buffer API now, and appears to be the reason why the
segment count must typically be 1.

In connection with this, the buffer API has grown a distinction
between character and binary buffers (on the read-only end only).
This may have been a mistake; it was intended to help with Unicode but
it ended up not being used.

The Buffer Object
-----------------

The buffer object has a much less clear reason for its existence.
When Greg Stein first proposed it, he wrote:

    The intent of this type is to expose a string-like interface from
    an object that supports the buffer interface (without making a
    copy). In addition, it is intended to support slices of the target
    object.

    My eventual goal here is to tweak the file object to support
    memory mapping and the buffer interface. The buffer object can
    then return slices of the file without making a new copy. Next
    step: change marshal.c, ceval.c, and compile.c to support a buffer
    for the co_code attribute. Net result is that copies of code
    streams don't need to be copied onto the heap, but can be left in
    an mmap'd file or a frozen file. I'm hoping there will be some
    perf gains (time and memory).

    Even without some of the co_code work, enabling mmap'd files and
    buffers onto them should be very useful. I can probably rattle off
    a good number of other uses for the buffer type.

I don't think that any of these benefits have been realized yet, and
altogether I think that the buffer object causes a lot of confusion.
The buffer *API* doesn't guarantee enough about the lifetime of the
pointers for the buffer *object* to be able to safely preserve those
pointers, even if the buffer object holds on to the base object.  (The
C-level buffer API informally guarantees that the data remains valid
only until you do anything to the base object; this is usually fine as
long as you don't release the global interpreter lock.)

The buffer object's approach to implementing the various sequence
operations is strange: sometimes it behaves like a string, sometimes
it doesn't.  E.g. a slice returns a new string object unless it
happens to address the whole buffer, in which case it returns a
reference to the existing buffer object.  It would seem more logical
that a subslice would return a new buffer object.  Concatenation and
repetition of buffer objects are likewise implemented inconsistently;
it would have been more consistent with the intended purpose if these
weren't supported at all (i.e. if none of the buffer object operations
would allocate new memory except for buffer object headers).

I would have concluded that the buffer object is entirely useless, if
it weren't for some very light use that is being made of it by the
Unicode machinery.  I can't quite tell whether that was done just
because it was convenient, or whether that shows there is a real
need.

What Now?
---------

I'm not convinced that we need the buffer object at all.  For example,
the mmap module defines a sequence object so doesn't seem to need the
buffer object to help it support slices.

Regarding the buffer API, it's clearly useful, although I'm not
convinced that it needs the multiple segment count option or the char
vs. binary buffer distinction, given that we're not using this for
Unicode objects as we originally planned.

I also feel that it would be helpful if there was an explicit way to
lock and unlock the data, so that a file object can release the global
interpreter lock while it is doing the I/O.  But that's not a high
priority (and there are no *actual* problems caused by the lack of
such an API -- just *theoretical*).

For Python 3000, I think I'd like to rethink this whole mess.  Perhaps
byte buffers and character strings should be different beasts, and
maybe character strings could have Unicode and 8-bit subclasses (and
maybe other subclasses that explicitly know about their encoding).
And maybe we'd have a real file base class.  And so on.

What to do in the short run?  I'm still for severely simplifing the
buffer object (ripping out the unused operations) and deprecating it.

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


From cbarker@jps.net  Mon Oct 16 18:38:11 2000
From: cbarker@jps.net (Chris Barker)
Date: Mon, 16 Oct 2000 10:38:11 -0700
Subject: [Python-Dev] Re: numpy,  overflow, inf, ieee, and rich comparison
References: <LNBBLJKPBEHFEDALKOLCGEFLHLAA.tim_one@email.msn.com>
Message-ID: <39EB3D03.A00C78B6@jps.net>


> >> I have not yet heard a decent response to the question of what to do
> >> when a single value in a large array is bad, and causes an exception.
> 
> I'd usually trace back and try to figure out how it got "bad" to begin with

And from Konrad Hinsen
>I'd like to have at least the option of raising an exception in that
>case. Note that this is not what NumPy does today.

Exactly. This was Huaiyu's point. The problem is that for your code to
be usable for folks other than yourself, you'd have to have a lot of
checks in there, and essentially revert to elementwise code, which would
kill you. With the addition of the occasional "isnan" and something like
Matlab's "any" ( "any(isnan(A))" returns true if any of the elements of
A are NaNs) you could set up your code to raise an exception in the
middle of computation. If, on the other hand the Code definiately raises
an exception, than you are stuck with a lot of elementwise coding.

> over/under-flows in IDL are reported but do 
> not stop execution.  This is the best (only) possible scenario for an 
> interactive arrays and visualization environment.

Exactly!!! ("the best (only) possible scenario" part)
 
> IDL> print, 54/0
>       54
> % Program caused arithmetic error: Integer divide by 0

This, however, is wierd!!  54/0 == 54 ??? I'd much rather see a NaN or
Inf here!

> MATLAB is fine for simple interactive data processing, and its
> behaviour is adapted to this task. I don't think anyone would use
> MATLAB for developing complex algorithms, its programming language
> isn't strong enough for that. Python is, so complex algorithms have to
> be considered as well. And for that kind of application, continuing a
> calculation with Infs and NaNs is a debugging nightmare.

People do some pretty complex algorith develpment with MATLAB. I'm also
no so sure about "continuing a calculation with Infs and NaNs is a
debugging nightmare" I'm don't think it's any more of a nighmare than
having your calculation on an entire array stop because of one Inf. It's
just a different trade off. Sprinkle a few "isnan"'s in there and and
you can get the behaviour you want, while not forcing it on all
calculations. Of course, the best option is to have it switchable, but
that may prove to be very difficult.

Are people doing the kind of numeric programming with "complex
algorithms" using Python that Konrad refers to? More importantly, how
many people?

>  Guido thinks that 2/3 returning 0 was a design mistake,
> but not that math.sqrt(-1) raising an exception is a mistake.  Most Python
> users won't know what to do with a complex number, so it's "an error" to
> them.

Guido's philosophy is clearly that Python defaults should be geared to
"Most Python users". I agree, and as I wrote in an earlier post, the
only users for whom the "exception raising only" option is best are the
users Konrad refers to as writing "complex algorithms". I would argue
that those users are few, and the group most able to deal with a
less-that-optimum system.

Maybe we can have true 754 compliance in Py3k, and we can all be happy!!

-Chris





-- 
Christopher Barker,
Ph.D.                                                           
cbarker@jps.net                      ---           ---           ---
http://www.jps.net/cbarker          -----@@       -----@@       -----@@
                                   ------@@@     ------@@@     ------@@@
Water Resources Engineering       ------   @    ------   @   ------   @
Coastal and Fluvial Hydrodynamics -------      ---------     --------    
------------------------------------------------------------------------
------------------------------------------------------------------------


From effbot@telia.com  Mon Oct 16 18:47:55 2000
From: effbot@telia.com (Fredrik Lundh)
Date: Mon, 16 Oct 2000 19:47:55 +0200
Subject: [Python-Dev] The buffer interface
References: <ECEPKNMJLHAPFFJHDOJBIEJMDNAA.MarkH@ActiveState.com> <39EAB33E.35B72EA4@lemburg.com>             <20001016060126.X347@lyra.org>  <200010161808.NAA32318@cj20424-a.reston1.va.home.com>
Message-ID: <00f601c03799$39f2c7b0$3c6340d5@hagrid>

guido wrote:
> What to do in the short run?  I'm still for severely simplifing the
> buffer object (ripping out the unused operations) and deprecating it.

agreed.

(does this mean that we're in post-2.0 mode? ;-)

</F>



From mal@lemburg.com  Mon Oct 16 18:42:15 2000
From: mal@lemburg.com (M.-A. Lemburg)
Date: Mon, 16 Oct 2000 19:42:15 +0200
Subject: [Python-Dev] Wierd buffer "add" behaviour.
References: <ECEPKNMJLHAPFFJHDOJBIEJMDNAA.MarkH@ActiveState.com> <39EAB33E.35B72EA4@lemburg.com> <20001016060126.X347@lyra.org>
Message-ID: <39EB3DF7.459A1BC1@lemburg.com>

Greg Stein wrote:
> 
> On Mon, Oct 16, 2000 at 09:50:22AM +0200, M.-A. Lemburg wrote:
> > Mark Hammond wrote:
> >...
> > > This yields the following strange behaviour:
> > >
> > > >>> a=buffer('a')
> > > >>> a+a
> > > 'aa'
> > > >>> a+a+a
> > > Traceback (innermost last):
> > >   File "<interactive input>", line 1, in ?
> > > TypeError: cannot add type "buffer" to string
> > > >>>
> > >
> > > That doesnt seem correct to me?
> >
> > Neither to me.
> 
> It is caused by the non-commutative aspect of Python types. You end up with
> a string, and that type doesn't know how to add a buffer to itself.

The problem is that buffer() objects coerce to strings in the
first place... they should return new buffer objects instead
of strings -- then we wouldn't have the above problems.
 
> ... 
> Of course, the choice of returning a string (from buf+buf) rather than a
> buffer was arguably the wrong choice.

Right :-/

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/


From guido@python.org  Mon Oct 16 19:51:51 2000
From: guido@python.org (Guido van Rossum)
Date: Mon, 16 Oct 2000 13:51:51 -0500
Subject: [Python-Dev] The buffer interface
In-Reply-To: Your message of "Mon, 16 Oct 2000 19:47:55 +0200."
 <00f601c03799$39f2c7b0$3c6340d5@hagrid>
References: <ECEPKNMJLHAPFFJHDOJBIEJMDNAA.MarkH@ActiveState.com> <39EAB33E.35B72EA4@lemburg.com> <20001016060126.X347@lyra.org> <200010161808.NAA32318@cj20424-a.reston1.va.home.com>
 <00f601c03799$39f2c7b0$3c6340d5@hagrid>
Message-ID: <200010161851.NAA32597@cj20424-a.reston1.va.home.com>

> guido wrote:
> > What to do in the short run?  I'm still for severely simplifing the
> > buffer object (ripping out the unused operations) and deprecating it.
> 
> agreed.
> 
> (does this mean that we're in post-2.0 mode? ;-)

Yes :-)

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


From mal@lemburg.com  Mon Oct 16 19:03:15 2000
From: mal@lemburg.com (M.-A. Lemburg)
Date: Mon, 16 Oct 2000 20:03:15 +0200
Subject: [Python-Dev] The buffer interface
References: <ECEPKNMJLHAPFFJHDOJBIEJMDNAA.MarkH@ActiveState.com> <39EAB33E.35B72EA4@lemburg.com>
 <20001016060126.X347@lyra.org> <200010161808.NAA32318@cj20424-a.reston1.va.home.com>
Message-ID: <39EB42E3.B76F37EB@lemburg.com>

Guido van Rossum wrote:
> ...
> I would have concluded that the buffer object is entirely useless, if
> it weren't for some very light use that is being made of it by the
> Unicode machinery.  I can't quite tell whether that was done just
> because it was convenient, or whether that shows there is a real
> need.

I used the buffer object since I thought that buffer() objects
were to replace strings as container for binary data. The buffer
object wraps a memory buffer into a Python object for the purpose
of decoding it into Unicode. 8-bit string objects would have worked
just as well...
 
> What Now?
> ---------
> 
> I'm not convinced that we need the buffer object at all.  For example,
> the mmap module defines a sequence object so doesn't seem to need the
> buffer object to help it support slices.

It would be nice to have an object for "copy by reference" rather
than "malloc + copy". This would be useful for strings (e.g. to
access substrings of a large string), Unicode and binary
data. The buffer object almost does this... it would only have
to stick to always returning buffer objects in coercion, slicing
etc. I also think that the name "buffer" is misleading, since it
really means "reference" in the context published by the Python
interface (the C API also has a way of defining new malloc areas
and referencing them through the buffer interface, but that is
not published in Python).

The other missing data type in Python is one for binary data.
Currently, string objects are in common use for this kind of
data. The problems with this are obvious: in some contexts strings
are expected to contain text data in other binary data. When the
two meet there's great confusion. I'd suggest either making
arrays the Python standard type for holding binary data, or
creating a completely new type (this should then be called
something like "buffer").

> Regarding the buffer API, it's clearly useful, although I'm not
> convinced that it needs the multiple segment count option or the char
> vs. binary buffer distinction, given that we're not using this for
> Unicode objects as we originally planned.

True.
 
> I also feel that it would be helpful if there was an explicit way to
> lock and unlock the data, so that a file object can release the global
> interpreter lock while it is doing the I/O.  But that's not a high
> priority (and there are no *actual* problems caused by the lack of
> such an API -- just *theoretical*).

How about adding a generic low-level lock type for these kind
of tasks. The interpreter could be made aware of these types
to allow a much more fine-grained lock mechanism, e.g. to check
for acquired locks of certain objects only.
 
> For Python 3000, I think I'd like to rethink this whole mess.  Perhaps
> byte buffers and character strings should be different beasts, and
> maybe character strings could have Unicode and 8-bit subclasses (and
> maybe other subclasses that explicitly know about their encoding).
> And maybe we'd have a real file base class.  And so on.

Great... but 3000 is a long way ahead :-(
 
> What to do in the short run?  I'm still for severely simplifing the
> buffer object (ripping out the unused operations) and deprecating it.

Since it isn't all that known anyway, how about streamlining
the buffer object implementations of the various protocols and
removing the distinction between "s" and "t" ?!

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/


From jcollins@endtech.com  Mon Oct 16 21:22:22 2000
From: jcollins@endtech.com (Jeff Collins)
Date: Mon, 16 Oct 2000 13:22:22 -0700 (PDT)
Subject: [Python-Dev] The buffer interface
In-Reply-To: <200010161808.NAA32318@cj20424-a.reston1.va.home.com>
Message-ID: <Pine.LNX.4.21.0010161135470.15198-100000@localhost.localdomain>

All this just when I was getting accustomed to the thought of using buffer
objects in the Palm Python port...

I need buffer objects for many the same reasons as Greg Stein originally
proposed, as you quoted below.  The on the Palm, the datamanager heap
(used for permanent database storage and limited by the physical memory
size) already stores the compiled python module.  Directly referencing the
data of objects like bytecodes and strings would greatly reduce the
dynamic heap (current limit of 256K on PalmOS 3.5 on devices with 4M RAM
or greater) requirements.

Buffer objects seem like a natural choice.  A record in a Palm database is
just chunk of contiguous memory.  Representing this chunk as a buffer
object would allow the direct referencing it and any of it's slices.  So,
the co_code of code objects could be unmarshalled with a reference to
permanent storage.  Further, with the appropriate modifications, string
objects (char *ob_sval?) could access this memory as well, though this
additional optimization is probably only appropriate for small platforms.

I think that buffer object is fairly important.  They provide a mechanism
for exposing arbitrary chunks of memory (eg, PyBuffer_FromMemory),
something that no other python object does, AFIAK.  Perhaps clarifying the
interface (such as the slice operator returning a buffer, as suggested
below) and providing more hooks from Python for creating buffers (via
newmodule, say) would be helpful.



On Mon, 16 Oct 2000, Guido van Rossum wrote:

> The buffer interface is one of the most misunderstood parts of
> Python.  I believe that if it were PEPped today, it would have a hard
> time getting accepted in its current form.
> 
> There are also two different parts that are commonly referred by this
> name: the "buffer API", which is a C-only API, and the "buffer
> object", which has both a C API and a Python API.
> 
> Both were largely proposed, implemented and extended by others, and I
> have to admit that I'm still uneasy with defending them, especially
> the buffer object.  Both are extremely implementation-dependent (in
> JPython, neither makes much sense).
> 
> The Buffer API
> --------------
> 
> The C-only buffer API was originally intended to allow efficient
> binary I/O from and (in some cases) to large objects that have a
> relatively well-understood underlying memory representation.  Examples
> of such objects include strings, array module arrays, memory-mapped
> files, NumPy arrays, and PIL objects.
> 
> It was created with the desire to avoid an expensive memory-copy
> operation when reading or writing large arrays.  For example, if you
> have an array object containing several millions of double precision
> floating point numbers, and you want to dump it to a file, you might
> prefer to do the I/O directly from the array's memory buffer rather
> than first copying it to a string.  (You lose portability of the data,
> but that's often not a problem the user cares about in these cases.)
> 
> An alternative solution for this particular problem was consdered:
> object types in need of this kind of efficient I/O could define their
> own I/O methods, thereby allowing them to hide their internal
> representation.  This was implemented in some cases (e.g. the array
> module has read() and write() methods) but rejected, because a
> simple-minded implementation of this approach would not work with
> "file-like" objects (e.g. StringIO files).  It was deemed important
> that file-like objects would not place restrictions on the kind of
> objects that could interact with them (compared to real file objects).
> 
> A possible solution would have been to require that each object
> implementing its own read and write methods should support both
> efficient I/O to/from "real" file objects and fall-back I/O to/from
> "file-like" objects.  The fall-back I/O would have to convert the
> object's data to a string object which would then be passed to the
> write() method of the file-like object.  This approach was rejected
> because it would make it impossible to implement an alternative file
> object that would be as efficient as the real file object, since large
> object I/O would be using the inefficient fallback interface.
> 
> To address these issues, we decided to define an interface that would
> let I/O operations ask the objects where their data bytes are in
> memory, so that the I/O can go directly to/from the memory allocated
> by the object.  This is the classic buffer API.  It has a read-only
> and a writable variant -- the writable variant is for mutable objects
> that will allow I/O directly into them.  Because we expected that some
> objects might have an internal representation distributed over a
> (small) number of separately allocated pieces of memory, we also added
> the getsegcount() API.  All objects that I know support the buffer API
> return a segment count of 1, and most places that use the buffer API
> give up if the segment count is larger; so this may be considered as
> an unnecessary generalization (and source of complexity).
> 
> The buffer API has found significant use in a way that wasn't
> originally intended: as a sort of informal common base class for
> string-like objects in situations where a char[] or char* type must be
> passed (in a read-only fashion) to C code.  This is in fact the most
> common use of the buffer API now, and appears to be the reason why the
> segment count must typically be 1.
> 
> In connection with this, the buffer API has grown a distinction
> between character and binary buffers (on the read-only end only).
> This may have been a mistake; it was intended to help with Unicode but
> it ended up not being used.
> 
> The Buffer Object
> -----------------
> 
> The buffer object has a much less clear reason for its existence.
> When Greg Stein first proposed it, he wrote:
> 
>     The intent of this type is to expose a string-like interface from
>     an object that supports the buffer interface (without making a
>     copy). In addition, it is intended to support slices of the target
>     object.
> 
>     My eventual goal here is to tweak the file object to support
>     memory mapping and the buffer interface. The buffer object can
>     then return slices of the file without making a new copy. Next
>     step: change marshal.c, ceval.c, and compile.c to support a buffer
>     for the co_code attribute. Net result is that copies of code
>     streams don't need to be copied onto the heap, but can be left in
>     an mmap'd file or a frozen file. I'm hoping there will be some
>     perf gains (time and memory).
> 
>     Even without some of the co_code work, enabling mmap'd files and
>     buffers onto them should be very useful. I can probably rattle off
>     a good number of other uses for the buffer type.
> 
> I don't think that any of these benefits have been realized yet, and
> altogether I think that the buffer object causes a lot of confusion.
> The buffer *API* doesn't guarantee enough about the lifetime of the
> pointers for the buffer *object* to be able to safely preserve those
> pointers, even if the buffer object holds on to the base object.  (The
> C-level buffer API informally guarantees that the data remains valid
> only until you do anything to the base object; this is usually fine as
> long as you don't release the global interpreter lock.)
> 
> The buffer object's approach to implementing the various sequence
> operations is strange: sometimes it behaves like a string, sometimes
> it doesn't.  E.g. a slice returns a new string object unless it
> happens to address the whole buffer, in which case it returns a
> reference to the existing buffer object.  It would seem more logical
> that a subslice would return a new buffer object.  Concatenation and
> repetition of buffer objects are likewise implemented inconsistently;
> it would have been more consistent with the intended purpose if these
> weren't supported at all (i.e. if none of the buffer object operations
> would allocate new memory except for buffer object headers).
> 
> I would have concluded that the buffer object is entirely useless, if
> it weren't for some very light use that is being made of it by the
> Unicode machinery.  I can't quite tell whether that was done just
> because it was convenient, or whether that shows there is a real
> need.
> 
> What Now?
> ---------
> 
> I'm not convinced that we need the buffer object at all.  For example,
> the mmap module defines a sequence object so doesn't seem to need the
> buffer object to help it support slices.
> 
> Regarding the buffer API, it's clearly useful, although I'm not
> convinced that it needs the multiple segment count option or the char
> vs. binary buffer distinction, given that we're not using this for
> Unicode objects as we originally planned.
> 
> I also feel that it would be helpful if there was an explicit way to
> lock and unlock the data, so that a file object can release the global
> interpreter lock while it is doing the I/O.  But that's not a high
> priority (and there are no *actual* problems caused by the lack of
> such an API -- just *theoretical*).
> 
> For Python 3000, I think I'd like to rethink this whole mess.  Perhaps
> byte buffers and character strings should be different beasts, and
> maybe character strings could have Unicode and 8-bit subclasses (and
> maybe other subclasses that explicitly know about their encoding).
> And maybe we'd have a real file base class.  And so on.
> 
> What to do in the short run?  I'm still for severely simplifing the
> buffer object (ripping out the unused operations) and deprecating it.
> 
> --Guido van Rossum (home page: http://www.python.org/~guido/)
> 
> _______________________________________________
> Python-Dev mailing list
> Python-Dev@python.org
> http://www.python.org/mailman/listinfo/python-dev
> 

-- 
Jeffery D. Collins  
Sr. Software Developer
Endeavors Technology, Inc.




From akuchlin@mems-exchange.org  Mon Oct 16 20:35:13 2000
From: akuchlin@mems-exchange.org (Andrew M. Kuchling)
Date: Mon, 16 Oct 2000 15:35:13 -0400
Subject: [Python-Dev] Post-2.0 strategy
In-Reply-To: <200010161851.NAA32597@cj20424-a.reston1.va.home.com>; from guido@python.org on Mon, Oct 16, 2000 at 01:51:51PM -0500
References: <ECEPKNMJLHAPFFJHDOJBIEJMDNAA.MarkH@ActiveState.com> <39EAB33E.35B72EA4@lemburg.com> <20001016060126.X347@lyra.org> <200010161808.NAA32318@cj20424-a.reston1.va.home.com> <00f601c03799$39f2c7b0$3c6340d5@hagrid> <200010161851.NAA32597@cj20424-a.reston1.va.home.com>
Message-ID: <20001016153513.A14693@amarok.cnri.reston.va.us>

On Mon, Oct 16, 2000 at 01:51:51PM -0500, Guido van Rossum wrote:
>> (does this mean that we're in post-2.0 mode? ;-)
>Yes :-)

Then this is a good time to ask what strategy will be followed
post-2.0.  Do you want a moratorium on massive checkins for a time
while 2.0 shakes out, re-opening the tree for larger changes in a few
months?  Or will you try to live with a CVS branch for 2.0 and re-open
the tree immediately?

--amk



From fdrake@beopen.com  Mon Oct 16 20:37:30 2000
From: fdrake@beopen.com (Fred L. Drake, Jr.)
Date: Mon, 16 Oct 2000 15:37:30 -0400 (EDT)
Subject: [Python-Dev] Post-2.0 strategy
In-Reply-To: <20001016153513.A14693@amarok.cnri.reston.va.us>
References: <ECEPKNMJLHAPFFJHDOJBIEJMDNAA.MarkH@ActiveState.com>
 <39EAB33E.35B72EA4@lemburg.com>
 <20001016060126.X347@lyra.org>
 <200010161808.NAA32318@cj20424-a.reston1.va.home.com>
 <00f601c03799$39f2c7b0$3c6340d5@hagrid>
 <200010161851.NAA32597@cj20424-a.reston1.va.home.com>
 <20001016153513.A14693@amarok.cnri.reston.va.us>
Message-ID: <14827.22778.902987.343492@cj42289-a.reston1.va.home.com>

Andrew M. Kuchling writes:
 > Then this is a good time to ask what strategy will be followed
 > post-2.0.  Do you want a moratorium on massive checkins for a time
 > while 2.0 shakes out, re-opening the tree for larger changes in a few
 > months?  Or will you try to live with a CVS branch for 2.0 and re-open
 > the tree immediately?

  I think a maintenance branch for 2.0.1 (or whatever) should be
created as part of the release process in case we need a quick release
for critical bug fixes.
  The tree should be re-opened after the release via a message to
python-dev after the release is published.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member



From guido@python.org  Mon Oct 16 21:46:22 2000
From: guido@python.org (Guido van Rossum)
Date: Mon, 16 Oct 2000 15:46:22 -0500
Subject: [Python-Dev] Post-2.0 strategy
In-Reply-To: Your message of "Mon, 16 Oct 2000 15:35:13 -0400."
 <20001016153513.A14693@amarok.cnri.reston.va.us>
References: <ECEPKNMJLHAPFFJHDOJBIEJMDNAA.MarkH@ActiveState.com> <39EAB33E.35B72EA4@lemburg.com> <20001016060126.X347@lyra.org> <200010161808.NAA32318@cj20424-a.reston1.va.home.com> <00f601c03799$39f2c7b0$3c6340d5@hagrid> <200010161851.NAA32597@cj20424-a.reston1.va.home.com>
 <20001016153513.A14693@amarok.cnri.reston.va.us>
Message-ID: <200010162046.PAA05288@cj20424-a.reston1.va.home.com>

> Then this is a good time to ask what strategy will be followed
> post-2.0.  Do you want a moratorium on massive checkins for a time
> while 2.0 shakes out, re-opening the tree for larger changes in a few
> months?  Or will you try to live with a CVS branch for 2.0 and re-open
> the tree immediately?

If we need to issue a patch release, we'll use a branch.  That seems
the only reasonable approach.

The tree will be open for checkins as soon as 2.0 is released (tonight
is looking good!), but I hope the people exercise some restraint and
discuss their plans for significant checkins on the python-dev list
first.

A lot of things should probably be discussed in the form of PEPs too!

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


From tim_one@email.msn.com  Mon Oct 16 20:47:05 2000
From: tim_one@email.msn.com (Tim Peters)
Date: Mon, 16 Oct 2000 15:47:05 -0400
Subject: [Python-Dev] Post-2.0 strategy
In-Reply-To: <20001016153513.A14693@amarok.cnri.reston.va.us>
Message-ID: <LNBBLJKPBEHFEDALKOLCCEICHLAA.tim_one@email.msn.com>

[Andrew M. Kuchling]
> Then this is a good time to ask what strategy will be followed
> post-2.0.  Do you want a moratorium on massive checkins for a time
> while 2.0 shakes out ...

It's not a great time to ask, as we're still balls-to-the-wall *building*
the release and doing last-second checkins (things like NEWS, not code).  So
there's an absolute ban on any checkins until further notice (on
Python-Dev), excepting for those explicitly approved by Jeremy.

After that, I agree with Fred that we should make a 2.0.1 branch
simultaneous with the release.




From jeremy@beopen.com  Mon Oct 16 23:11:49 2000
From: jeremy@beopen.com (Jeremy Hylton)
Date: Mon, 16 Oct 2000 18:11:49 -0400 (EDT)
Subject: [Python-Dev] Python 2.1 Release Schedule (tentative)
Message-ID: <14827.32037.652156.120714@bitdiddle.concentric.net>

FYI: In anticpation of the Python 2.0 final release this evening, we
just created a new PEP describing the release schedule for Python 2.1.

Jeremy


PEP: 226
Title: Python 2.1 Release Schedule
Version: $Revision: 1.1 $
Author: Jeremy Hylton <jeremy@beopen.com>
Status: Incomplete
Type: Informational
Created: 16-Oct-2000
Python-Version: 2.1
Post-History:

Abstract

    This document describes the post Python 2.0 development and
    release schedule.  According to this schedule, Python 2.1 will be
    released in mid-March of 2001.  The schedule primarily concerns
    itself with PEP-size items.  Small bug fixes and changes will
    occur up until the first beta release.


Tentative Release Schedule

    16-Oct-2000: Python 2.0 final release
 
    These dates represent goals, not commitments.

    16-Dec-2000: 2.1 PEPs ready for review
    01-Feb-2001: First 2.1 beta release
    16-Mar-2001: 2.1 final release


Guidelines for making changes for Python 2.1

    The guidelines and schedule will be revised based on discussion in
    the python-dev@python.org mailing list.

    The PEP system was instituted late in the Python 2.0 development
    cycle and many changes did not follow the process described in PEP
    1.  The development process for 2.1, however, will follow the PEP
    process as documented.

    The first eight weeks following 2.0 final will be the design and
    review phase.  By the end of this period, any PEP that is proposed
    for 2.1 should be ready for review.  This means that the PEP is
    written and discussion has occurred on the python-dev@python.org
    and python-list@python.org mailing lists.

    The next six weeks will be spent reviewing the PEPs and
    implementing and testing the accepted PEPs.  When this period
    stops, we will end consideration of any incomplete PEPs.  Near the
    end of this period, there will be a feature freeze where any small
    features not worthy of a PEP will not be accepted.

    Before the final release, we will have six weeks of beta testing
    and a release candidate or two.


Bug fix releases before 2.1

    We may have to issue Python 2.0.1 for critical bug fixes.  If we
    need to issue a bug fix release, we will use a CVS branch. 


General guidelines for submitting patches and making changes

    Use good sense when committing changes.  You should know what we
    mean by good sense or we wouldn't have given you commit privileges
    <0.5 wink>.  Some specific examples of good sense include:

    - Do whatever the dictator tells you.

    - Discuss any controversial changes on python-dev first.  If you
      get a lot of +1 votes and no -1 votes, make the change.  If you
      get a some -1 votes, think twice; consider asking Guido what he
      thinks.

    - If the change is to code you contributed, it probably makes
      sense for you to fix it.

    - If the change affects code someone else wrote, it probably makes
      sense to ask him or her first.

    - You can use the SourceForge (SF) Patch Manager to submit a patch
      and assign it to someone for review.

    Any significant new feature must be described in a PEP and
    approved before it is checked in.

    Any significant code addition, such as a new module or large
    patch, must include test cases for the regression test and
    documentation.  A patch should not be checked in until the tests
    and documentation are ready.

    If you fix a bug, you should write a test case that would have
    caught the bug.

    If you commit a patch from the SF Patch Manager or fix a bug from
    the Jitterbug database, be sure to reference the patch/bug number
    in the CVS log message.  Also be sure to change the status in the
    patch manager or bug database (if you have access to the bug
    database).

    It is not acceptable for any checked in code to cause the
    regression test to fail.  If a checkin causes a failure, it must
    be fixed within 24 hours or it will be backed out.

    All contributed C code must be ANSI C.  If possible check it with
    two different compilers, e.g. gcc and MSVC.

    All contributed Python code must follow Guido's Python style
    guide.  http://www.python.org/doc/essays/styleguide.html

    It is understood that any code contributed will be released under
    an Open Source license.  Do not contribute code if it can't be
    released this way.


From greg@cosc.canterbury.ac.nz  Tue Oct 17 00:09:55 2000
From: greg@cosc.canterbury.ac.nz (Greg Ewing)
Date: Tue, 17 Oct 2000 12:09:55 +1300 (NZDT)
Subject: [Python-Dev] The buffer interface
In-Reply-To: <200010161808.NAA32318@cj20424-a.reston1.va.home.com>
Message-ID: <200010162309.MAA26975@s454.cosc.canterbury.ac.nz>

Guido:

> The buffer *API* doesn't guarantee enough about the lifetime of the
> pointers for the buffer *object* to be able to safely preserve those
> pointers, even if the buffer object holds on to the base object.

This seems like a fatal flaw to me, which should have
prevented the buffer object in its present form from
ever having been implemented.

I suggest that this problem MUST be fixed, or the
buffer object removed entirely.

Greg Ewing, Computer Science Dept, +--------------------------------------+
University of Canterbury,	   | A citizen of NewZealandCorp, a	  |
Christchurch, New Zealand	   | wholly-owned subsidiary of USA Inc.  |
greg@cosc.canterbury.ac.nz	   +--------------------------------------+


From gstein@lyra.org  Tue Oct 17 02:57:09 2000
From: gstein@lyra.org (Greg Stein)
Date: Mon, 16 Oct 2000 18:57:09 -0700
Subject: [Python-Dev] The buffer interface
In-Reply-To: <Pine.LNX.4.21.0010161135470.15198-100000@localhost.localdomain>; from jcollins@endtech.com on Mon, Oct 16, 2000 at 01:22:22PM -0700
References: <200010161808.NAA32318@cj20424-a.reston1.va.home.com> <Pine.LNX.4.21.0010161135470.15198-100000@localhost.localdomain>
Message-ID: <20001016185709.J25097@lyra.org>

On Mon, Oct 16, 2000 at 01:22:22PM -0700, Jeff Collins wrote:
>...
> I think that buffer object is fairly important.  They provide a mechanism
> for exposing arbitrary chunks of memory (eg, PyBuffer_FromMemory),
> something that no other python object does, AFIAK.  Perhaps clarifying the
> interface (such as the slice operator returning a buffer, as suggested
> below) and providing more hooks from Python for creating buffers (via
> newmodule, say) would be helpful.

There have been quite a few C extensions (and embedding Python!) where the
buffer objects have been used in this fashion. For example, if you have a
string argument that you wish to pass into Python, then you can avoid a copy
by wrapping a Buffer Object around it and passing that.

Many of the issues with the buffer object can be solved with simple changes.
For example, the "mutable object" thing is easily dealt with by having the
object not record the pointer, but just fetch it every time that it wants to
do an operation.
[ and if we extend the buffer API, we could potentially optimize the
  behavior to avoid the ptr refetch on each operation ]

I don't recall the motivation for returning strings. I believe it was based
on an attempt to make the buffer look as much like a string as possible (and
slices and concats return strings). That was a poor choice :-)  ... so,
again, some basic changes to return slices and concats as buffer objects
would make sense.

Extending the buffer() builtin to create writeable buffer objects has been a
reasonably common request. What seems to happen instead is that people
developing C extensions (which desire buffer objects as their params) just
add a new function to the extension to create buffer objects.

Re: the buffer API: At the time the "s"/"t" codes were introduced (before
1.5.2 was released), we had a very different concept of how Unicode objects
would be implemented. At that time, Unicode objects had no 8-bit
representation (just 16-bit chars), so the difference was important. I'm not
clued in enough on the ramifications of torching the difference in the API,
but it would be a nice simplification.

Buffers vs arrays: this is a harder question. Which is the "recommended
binary type [for series of bytes]" ? Buffers can refer to arbitrary memory.
Arrays maintain their own memory. I believe the two models are needed, so
I'd initially offer that both buffers and arrays need to be maintained.
However, given that... what is the purpose of the array if a buffer can
*also* maintain its own memory?

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/


From guido@python.org  Tue Oct 17 04:35:02 2000
From: guido@python.org (Guido van Rossum)
Date: Mon, 16 Oct 2000 22:35:02 -0500
Subject: [Python-Dev] Python 2.0 final release is out!
Message-ID: <200010170335.WAA07253@cj20424-a.reston1.va.home.com>

I am happy to announce that Python 2.0 is released.  I thank my
colleagues at BeOpen PythonLabs and the many volunteers in the Python
developer community for their incredible work on this release over the
past months.  Please pick up the new release at

    http://www.pythonlabs.com/products/python2.0/

There you will find a Windows installer, a source tarball, RedHat
RPMs, downloadable and online documentation, and a long list of new
features and fixed bugs.  Among the new features in Python 2.0 are:

  - Augmented assignment, e.g. x += 1
  - List comprehensions, e.g. [x**2 for x in range(10)]
  - Extended import statement, e.g. import Module as Name
  - Extended print statement, e.g. print >> file, "Hello"
  - Collection of cyclical garbage

For a fuller discussion of the changes in Python 2.0 since Python
1.5.2, please see the article "What's New in Python 2.0" by A.M.
Kuchling and Moshe Zadka:
http://starship.python.net/crew/amk/python/writing/new-python/

All major reported bugs have been fixed in this final release.  We've
gone through an extremely thorough set of beta releases followed by a
release candidate, and therefore we expect that this release will be
stable and virtually problem-free.  If you nevertheless run into a
bug, use the SourceForge bug tracker to report it:
http://sourceforge.net/bugs/?group_id=5470

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


From fdrake@beopen.com  Tue Oct 17 05:53:25 2000
From: fdrake@beopen.com (Fred L. Drake, Jr.)
Date: Tue, 17 Oct 2000 00:53:25 -0400 (EDT)
Subject: [Python-Dev] CVS repository open for business
Message-ID: <14827.56133.84421.68885@cj42289-a.reston1.va.home.com>

  The Python CVS repository is now open for further development.

  If critical patches are needed to the 2.0 release, they should be
developed against the branch tagged "release20-maint", and should be
posted at SourceForge and discussed here on python-dev before checking
them into the branch.
  Thanks to all the Python developers for your hard work and
contributions!


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member



From mal@lemburg.com  Tue Oct 17 09:16:56 2000
From: mal@lemburg.com (M.-A. Lemburg)
Date: Tue, 17 Oct 2000 10:16:56 +0200
Subject: [Python-Dev] The buffer interface
References: <200010161808.NAA32318@cj20424-a.reston1.va.home.com> <Pine.LNX.4.21.0010161135470.15198-100000@localhost.localdomain> <20001016185709.J25097@lyra.org>
Message-ID: <39EC0AF8.5FA79E97@lemburg.com>

Greg Stein wrote:
> 
> On Mon, Oct 16, 2000 at 01:22:22PM -0700, Jeff Collins wrote:
> >...
> > I think that buffer object is fairly important.  They provide a mechanism
> > for exposing arbitrary chunks of memory (eg, PyBuffer_FromMemory),
> > something that no other python object does, AFIAK.  Perhaps clarifying the
> > interface (such as the slice operator returning a buffer, as suggested
> > below) and providing more hooks from Python for creating buffers (via
> > newmodule, say) would be helpful.
> 
> There have been quite a few C extensions (and embedding Python!) where the
> buffer objects have been used in this fashion. For example, if you have a
> string argument that you wish to pass into Python, then you can avoid a copy
> by wrapping a Buffer Object around it and passing that.

Perhaps we ought to flesh out the current uses of buffer objects and
then decide how to proceed ?!

IMHO, the problem with buffer objects (apart from the sometimes strange
protocol behaviour) is that there too many "features" built into
it. Simplification and possibly diversification is needed: instead
of trying to achieve every possible C hack with buffer objects
we should try to come up with a reasonably small set of types
which allow only very basic tasks, e.g. 

1. wrapping C memory areas with the possibility of accessing the
   raw bytes in a read-only way (this should be buffer()),

2. providing a non-copying object reference type (I'd call this
   reference()) and

3. maintaining a writeable C memory buffer (arrays provide this feature).

The buffer object currently tries to do all three.

> Many of the issues with the buffer object can be solved with simple changes.
> For example, the "mutable object" thing is easily dealt with by having the
> object not record the pointer, but just fetch it every time that it wants to
> do an operation.
> [ and if we extend the buffer API, we could potentially optimize the
>   behavior to avoid the ptr refetch on each operation ]

Please don't extend the buffer API: the whole design is flawed
since it undermines data encapsulation in very dangerous ways.

If at all, we should consider a new API at abstract API level
which doesn't return raw C pointers, but real Python objects
(e.g. type 2 reference objects).
 
> I don't recall the motivation for returning strings. I believe it was based
> on an attempt to make the buffer look as much like a string as possible (and
> slices and concats return strings). That was a poor choice :-)  ... so,
> again, some basic changes to return slices and concats as buffer objects
> would make sense.

+1.
 
> Extending the buffer() builtin to create writeable buffer objects has been a
> reasonably common request. What seems to happen instead is that people
> developing C extensions (which desire buffer objects as their params) just
> add a new function to the extension to create buffer objects.

Please don't. Instead either suggest to use arrays or come up
with some new type with the sole purpose of providing read-write
access to a chunk of bytes.
 
> Re: the buffer API: At the time the "s"/"t" codes were introduced (before
> 1.5.2 was released), we had a very different concept of how Unicode objects
> would be implemented. At that time, Unicode objects had no 8-bit
> representation (just 16-bit chars), so the difference was important. I'm not
> clued in enough on the ramifications of torching the difference in the API,
> but it would be a nice simplification.

Well, think of it this way: Unicode was the first object to actually
try to make a difference between "s" and "t" -- and failed badly.
In the end, we reverted the decision to make any difference and
now special case Unicode objects in the getargs.c parser (so that
"s" and "t" work virtually the same for Unicode).

+1 on the idea of removing the difference altogether in 2.1.

If anyone needs to a special representation of an object, the object
should provide a clearly defined C API for this instead. E.g.
Unicode has lots of APIs to encode Unicode into quite a few
new repesentations.

> Buffers vs arrays: this is a harder question. Which is the "recommended
> binary type [for series of bytes]" ? Buffers can refer to arbitrary memory.
> Arrays maintain their own memory. I believe the two models are needed, so
> I'd initially offer that both buffers and arrays need to be maintained.
> However, given that... what is the purpose of the array if a buffer can
> *also* maintain its own memory?

Right and that's the problem: buffers shouldn't be able to
own memory. See above.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/


From barry@scottb.demon.co.uk  Tue Oct 17 09:40:52 2000
From: barry@scottb.demon.co.uk (Barry Scott)
Date: Tue, 17 Oct 2000 09:40:52 +0100
Subject: [Python-Dev] build problems large and small on FreeBSD
In-Reply-To: <14823.38174.143372.125749@bitdiddle.concentric.net>
Message-ID: <001201c03815$f54c4960$060210ac@private>

The FreeBSD ports collection had to be updated to support
importing C++ extensions with Python 1.5.2. (You get things
like cout not defined when importing).

Are the nessesary compile/link changes in 2.0?

		BArry



From gstein@lyra.org  Tue Oct 17 11:48:27 2000
From: gstein@lyra.org (Greg Stein)
Date: Tue, 17 Oct 2000 03:48:27 -0700
Subject: [Python-Dev] Re: [XML-SIG] PyXML home page on SF
In-Reply-To: <Pine.LNX.4.21.0010171130030.9897-100000@aries>; from Nicolas.Chauvat@logilab.fr on Tue, Oct 17, 2000 at 12:18:41PM +0200
References: <200010162335.BAA01015@loewis.home.cs.tu-berlin.de> <Pine.LNX.4.21.0010171130030.9897-100000@aries>
Message-ID: <20001017034827.F26804@lyra.org>

[ moving from xml-sig to python-dev ]

Reality check time...

On Tue, Oct 17, 2000 at 12:18:41PM +0200, Nicolas Chauvat wrote:
> [maintaining a pythonforge.org would take time and ressources]
> 
> Yes. But I understand a commercial company (BeOpen) has taken over python
> development. I think it is the kind of free services they could give
> back to the python community.

If VA Linux is already offering the service, then how does the community
benefit from BeOpen offering the same thing?

More importantly: how is BeOpen going to benefit from it? How do they get a
business return on that investment? That *will* come into play, you know.
Somebody has to pay for those sysadmins and hardware and connectivity.

> > > That would be pyxml.pythonforge.org, distutils.pythonforge.org, etc. :-)
> > 
> > I'd personally hope that python.org becomes accessible in that
> > way. You could probably have all of the current content there, and
> > then also have python.org/projects/pyxml; python.org/users/someone;
> > xml.python.org (and whatever other gimmicks they offer).

The last I heard, the intent was to move python.org from CNRI to a machine
at VA Linux. The content would then become available for the community to
work on; possibly through SourceForge facilities.

> > One advantage of taking things off SF is that responsiveness of that
> > system was really bad. That seems to have improved recently;
> 
> My concern is not about responsiveness as much as distribution (as in
> Internet is a distributed system). SourceForge is a great service. Good.
> Now are we to host every single open source project on SourceForge ? If we
> do so, the day SourceForge closes or changes its policy, or whatever,
> every single open source project will be halted or maybe discontinued.

There is no way that SF is ever going to close and take all of those
projects with it. VA Linux would be see their business instantly vaporized.
As ESR is fond to point out: VA Linux has built their business on trust from
the community. *ANY* failure to meet that trust will kill their biz.

> The people at SourceForge know their job: they provide a good service and
> the tools (code+doc) to implement that same service at other places.
> 
> Why wouldn't a community as big an active as python's put up ressources in
> common to offer such a useful service, but dedicated to python
> development ? There use to be a python.starship.net, maintained by
> volunteers, that is now hosted by BeOpen. Why not take the next step ?

python.starship.net has historically been a disaster area. Poorly maintained
or (even worse) maintained by a whole bunch of people. Have you ever seen
what happens when you give 20 people root access?

Then there was the time that a drive crashed. The machine was *gone* for
months.

Oh, and the network connectivity loss. A month offline, maybe?

The community is way to busy to run a service. Sorry.

That is why I like SF so much. They are ready and willing to run a service
and to fund that operation. And to all appearances, they are running it very
well (and continually upgrading it!).

> > if anybody is to host a similar server, they need to be aware that it
> > is probably hard to compete with SF in terms of provided services. For
> > example, I trust that SF has a reasonable backup strategy - they

They do. It is somewhere on their site. They have a complete backup
strategy. In fact, a while back, they lost a drive and restored most of it
from backup. I forget if there was any actual material lost.

> > simply can't risk a desaster. Anybody hosting a server for just a few
> > projects would not get the same sort of trust from me.
> 
> That's why I think we shouldn't look for someone able to host a server for
> a few projects but for some company(ies) able to put up the ressources for
> "python projects" and volunteers that help them.

Idealistic, but it won't happen. starship.net is my case in point.

> That would also make it easier for people to look for python ressources:
> code in development would be at something.python.org and 3rd party
> software at www.vex.net/parnassus. But I would agree that's a weak
> argument as long as www.python.org continues to be well-maintained with
> no broken links and stays the central hub for python information.

When python.org moves, then it will be maintained much better. I don't
recall the status of that, but I presume that Guido is still pushing to see
it happen.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/


From guido@python.org  Tue Oct 17 04:35:02 2000
From: guido@python.org (Guido van Rossum)
Date: Mon, 16 Oct 2000 22:35:02 -0500
Subject: [Python-Dev] Python 2.0 final release is out!
Message-ID: <mailman.971750281.20361.clpa-moderators@python.org>

I am happy to announce that Python 2.0 is released.  I thank my
colleagues at BeOpen PythonLabs and the many volunteers in the Python
developer community for their incredible work on this release over the
past months.  Please pick up the new release at

    http://www.pythonlabs.com/products/python2.0/

There you will find a Windows installer, a source tarball, RedHat
RPMs, downloadable and online documentation, and a long list of new
features and fixed bugs.  Among the new features in Python 2.0 are:

  - Augmented assignment, e.g. x += 1
  - List comprehensions, e.g. [x**2 for x in range(10)]
  - Extended import statement, e.g. import Module as Name
  - Extended print statement, e.g. print >> file, "Hello"
  - Collection of cyclical garbage

For a fuller discussion of the changes in Python 2.0 since Python
1.5.2, please see the article "What's New in Python 2.0" by A.M.
Kuchling and Moshe Zadka:
http://starship.python.net/crew/amk/python/writing/new-python/

All major reported bugs have been fixed in this final release.  We've
gone through an extremely thorough set of beta releases followed by a
release candidate, and therefore we expect that this release will be
stable and virtually problem-free.  If you nevertheless run into a
bug, use the SourceForge bug tracker to report it:
http://sourceforge.net/bugs/?group_id=5470

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



From guido@python.org  Tue Oct 17 15:06:00 2000
From: guido@python.org (Guido van Rossum)
Date: Tue, 17 Oct 2000 09:06:00 -0500
Subject: [Python-Dev] build problems large and small on FreeBSD
In-Reply-To: Your message of "Tue, 17 Oct 2000 09:40:52 +0100."
 <001201c03815$f54c4960$060210ac@private>
References: <001201c03815$f54c4960$060210ac@private>
Message-ID: <200010171406.JAA09272@cj20424-a.reston1.va.home.com>

> The FreeBSD ports collection had to be updated to support
> importing C++ extensions with Python 1.5.2. (You get things
> like cout not defined when importing).
> 
> Are the nessesary compile/link changes in 2.0?

Tell you what: I have no idea. :-(

I believe there were some changes to the Makefile and/or config file
to support C++, but I don't know if this works on FreeBSD.  I'm not a
big C++ user myself, so I rarely try this...

Can you try it?  If it doesn't work out of the box, let's sit down
together and figure out a fix.

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



From fdrake@beopen.com  Tue Oct 17 14:59:46 2000
From: fdrake@beopen.com (Fred L. Drake, Jr.)
Date: Tue, 17 Oct 2000 09:59:46 -0400 (EDT)
Subject: [Python-Dev] Re: [XML-SIG] PyXML home page on SF
In-Reply-To: <Pine.LNX.4.21.0010171130030.9897-100000@aries>
References: <200010162335.BAA01015@loewis.home.cs.tu-berlin.de>
 <Pine.LNX.4.21.0010171130030.9897-100000@aries>
Message-ID: <14828.23378.795196.804989@cj42289-a.reston1.va.home.com>

[Moved to python-dev, since the shift has begun.]

Nicolas Chauvat writes:
 > I'm sure several people from PythonLabs are on this list. What is their
 > opinion ?

  I rather like letting the SourceForge crew take care of running the
service.  Running a website that needs constant updates is no trivial
matter, and SourceForge is *much* more complex than that!
  I have a great deal of respect for the hard work that I know goes
into running SourceForge, and would rather see that effort bolstered
by volunteers & contributions (docs, code, whatever) by people who are
able, than to see the efforts splintered.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member



From Nicolas.Chauvat@logilab.fr  Tue Oct 17 15:07:36 2000
From: Nicolas.Chauvat@logilab.fr (Nicolas Chauvat)
Date: Tue, 17 Oct 2000 16:07:36 +0200 (CEST)
Subject: [Python-Dev] Re: [XML-SIG] PyXML home page on SF
In-Reply-To: <14828.23378.795196.804989@cj42289-a.reston1.va.home.com>
Message-ID: <Pine.LNX.4.21.0010171600440.10465-100000@aries>

>   I have a great deal of respect for the hard work that I know goes
> into running SourceForge, and would rather see that effort bolstered
> by volunteers & contributions (docs, code, whatever) by people who are
> able, than to see the efforts splintered.

Hum, maybe I did not explain myself correctly and I don't want a
misunderstanding: I never meant "let's create a SourceForge-like tool,
SourceForge is bad", but only "why not host a python specific service
using the SourceForge code and tools", as www.bioinformatics.org does for
projects related to bio-ingeneering.

--=20
Nicolas Chauvat

http://www.logilab.com - "Mais o=F9 est donc Ornicar ?" - LOGILAB, Paris (F=
rance)



From guido@python.org  Tue Oct 17 16:26:31 2000
From: guido@python.org (Guido van Rossum)
Date: Tue, 17 Oct 2000 10:26:31 -0500
Subject: [Python-Dev] Re: [XML-SIG] PyXML home page on SF
In-Reply-To: Your message of "Tue, 17 Oct 2000 16:07:36 +0200."
 <Pine.LNX.4.21.0010171600440.10465-100000@aries>
References: <Pine.LNX.4.21.0010171600440.10465-100000@aries>
Message-ID: <200010171526.KAA09461@cj20424-a.reston1.va.home.com>

> Hum, maybe I did not explain myself correctly and I don't want a
> misunderstanding: I never meant "let's create a SourceForge-like tool,
> SourceForge is bad", but only "why not host a python specific service
> using the SourceForge code and tools", as www.bioinformatics.org does for
> projects related to bio-ingeneering.

Why not indeed?  Why spend time running a service that SourceForge is
already providing, and very well at that?  This has come up
occasionally at BeOpen but the only argument for it that was ever
brought up (by the marketing folks, of course :-) was the hope that it
would help sell banner ads -- not that there would be an advantage for
the community.

What would be the advantage for the community or running our own?
What's wrong with using SourceForge?  I say, if it ain't broke don't
fix it.  (And then again, there may be a very good reason to run our
own, and maybe I just don't see it. :-)

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



From thomas@xs4all.net  Tue Oct 17 16:11:11 2000
From: thomas@xs4all.net (Thomas Wouters)
Date: Tue, 17 Oct 2000 17:11:11 +0200
Subject: [Python-Dev] Re: [XML-SIG] PyXML home page on SF
In-Reply-To: <200010171526.KAA09461@cj20424-a.reston1.va.home.com>; from guido@python.org on Tue, Oct 17, 2000 at 10:26:31AM -0500
References: <Pine.LNX.4.21.0010171600440.10465-100000@aries> <200010171526.KAA09461@cj20424-a.reston1.va.home.com>
Message-ID: <20001017171111.K12812@xs4all.nl>

On Tue, Oct 17, 2000 at 10:26:31AM -0500, Guido van Rossum wrote:

> > Hum, maybe I did not explain myself correctly and I don't want a
> > misunderstanding: I never meant "let's create a SourceForge-like tool,
> > SourceForge is bad", but only "why not host a python specific service
> > using the SourceForge code and tools", as www.bioinformatics.org does for
> > projects related to bio-ingeneering.

> What would be the advantage for the community or running our own?
> What's wrong with using SourceForge?  I say, if it ain't broke don't
> fix it.  (And then again, there may be a very good reason to run our
> own, and maybe I just don't see it. :-)

There is no advantage that I know of. I know a lot about keeping machines
and websites up and running (that's what I do for a living(*), after all)
and I can tell you you need a big (or very dedicated) sysadmin staff to be
able to offer anything as reliable as SourceForge.

So the website & CVS tree itself could be run on a low-end machine. Say a
PII-300 with 128 MB RAM. You need at least two, preferably three machines,
regardless of performance, to be able to offer 'reliable' services.
Preferably load-balanced by something like a smart switch (we use Alteon
Layer-4 ethernet switches for that task, and you can do cool things with
them. They're also pretty expensive.) And you need a way to back it up. A
tape library or DAT streamer of some kind. Preferably a separate machine to
do the actual backups. Live or fast-cycled backups can also be a lifesaver,
which either requires another machine or two with speedy disks, or storing
your data on something dedicated like a NetApp Filer. (Very cool machine, a
dedicated NFS and CIFS (SMB) fileserver with excellent live backups,
'snapshots', as many as you want/need. Only costs you diskspace. Oh, and
this quality comes at a price, too, of course.)

And then there's the reliable network access, reliable system room (with
reliable and preferably redundant power), and the 24/7 warning system that
wakes up stand-by sysadmins to fix problems.

And for the specialized hardware and software, you need a few people who
know how to handle them. You need several people anyway, to cover all bases
even in the face of illness, vacations and the famous bus accidents. We have
a crew of 12 now, with a few new additions, and even then we run into
trouble with vacations. I dare say we offer more reliable services than
SourceForge does, but we also cost more :-)

In short, the only advantage to not using SourceForge is that you can do
things SourceForge can't or won't. Run software SourceForge won't, for
instance. However, I would strongly suggest making such software
'non-essential', keeping most of the stuff on SourceForge, spend lots less
money on the technical setup, and suffer a bit when the service is down.

*) Where living is defined as 'making enough money to stay breathing and
work on Python', and 'work on Python' has higher importance, of course :-)

-- 
Thomas Wouters <thomas@xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!


From akuchlin@mems-exchange.org  Tue Oct 17 17:47:34 2000
From: akuchlin@mems-exchange.org (Andrew Kuchling)
Date: Tue, 17 Oct 2000 12:47:34 -0400
Subject: [Python-Dev] Publicity for 2.0 release?
Message-ID: <E13lZtm-0001b4-00@kronos.cnri.reston.va.us>

Is BeOpen doing any publicity for the release of 2.0?  For example,
issuing a press release and sending it to lots of different
publications, such as DDJ, Web Development, Windows programming magazines,
whatever that XML magazine is called, etc.?

(Hmm... www.beopen.com hasn't been updated to mention the new release
-- nor even 2.0c1.)

--amk


From pf@artcom-gmbh.de  Tue Oct 17 18:21:19 2000
From: pf@artcom-gmbh.de (Peter Funk)
Date: Tue, 17 Oct 2000 19:21:19 +0200 (MEST)
Subject: [Python-Dev] Publicity for 2.0 release?
In-Reply-To: <E13lZtm-0001b4-00@kronos.cnri.reston.va.us> from Andrew Kuchling at "Oct 17, 2000 12:47:34 pm"
Message-ID: <m13laQR-000Dm8C@artcom0.artcom-gmbh.de>

Andrew Kuchling:
> Is BeOpen doing any publicity for the release of 2.0?  For example,
> issuing a press release and sending it to lots of different
> publications, such as DDJ, Web Development, Windows programming magazines,
> whatever that XML magazine is called, etc.?
> 
> (Hmm... www.beopen.com hasn't been updated to mention the new release
> -- nor even 2.0c1.)

Really bad marketing! ;-)  But not as bad as it could have been:
Other places hopping into my mind were:
	http://slashdot.org/  (already done, see below)
	http://freshmeat.net/ (already done by Andrew Kuchling, 3249 hits)
	http://www.newsforge.com/ (didn't see Python mentioned there yet)
and not to forget 
	http://www.python.org/ (already done)

quoting from slashdot:
     """Python 2.0 Released

        Posted by timothy on 5:34 Tuesday 17 October 2000
        from the Perl-6-times-infinity-nyeahnyeah-nyeahnyeah dept.
        atallah writes: "It would appear that the long awaited Python 2.0 was
        finally released today. The front page of the Web site has the
        announcement." According to that announcement, Python 2.0 will receive
        minor-version updates around every 6 months, even as work begins on the
        shoot-for-the-moon Python 3000. For the curious, here's the list of what's new in 2.0; the list
        includes "full XML support and several forms of new syntax," as well as the BeOpen label. 

        ( Read More... | 164 comments )
     """

Regards, Peter
-- 
Peter Funk, Oldenburger Str.86, D-27777 Ganderkesee, Germany, Fax:+49 4222950260
office: +49 421 20419-0 (ArtCom GmbH, Grazer Str.8, D-28359 Bremen)


From akuchlin@mems-exchange.org  Tue Oct 17 18:33:22 2000
From: akuchlin@mems-exchange.org (Andrew Kuchling)
Date: Tue, 17 Oct 2000 13:33:22 -0400
Subject: [Python-Dev] Publicity for 2.0 release?
In-Reply-To: <m13laQR-000Dm8C@artcom0.artcom-gmbh.de>; from pf@artcom-gmbh.de on Tue, Oct 17, 2000 at 07:21:19PM +0200
References: <E13lZtm-0001b4-00@kronos.cnri.reston.va.us> <m13laQR-000Dm8C@artcom0.artcom-gmbh.de>
Message-ID: <20001017133322.A6158@kronos.cnri.reston.va.us>

On Tue, Oct 17, 2000 at 07:21:19PM +0200, Peter Funk wrote:
>	http://freshmeat.net/ (already done by Andrew Kuchling, 3249 hits)

By Jeremy, actually.  I'm not sure why it lists my name instead --
Freshmeat bug?

--amk


From hinsen@cnrs-orleans.fr  Tue Oct 17 21:27:10 2000
From: hinsen@cnrs-orleans.fr (Konrad Hinsen)
Date: Tue, 17 Oct 2000 22:27:10 +0200
Subject: [Python-Dev] Re: [Numpy-discussion] Re: numpy,  overflow, inf, ieee, and rich comparison
In-Reply-To: <39EB3D03.A00C78B6@jps.net> (message from Chris Barker on Mon, 16
 Oct 2000 10:38:11 -0700)
References: <LNBBLJKPBEHFEDALKOLCGEFLHLAA.tim_one@email.msn.com> <39EB3D03.A00C78B6@jps.net>
Message-ID: <200010172027.WAA11907@chinon.cnrs-orleans.fr>

> Are people doing the kind of numeric programming with "complex
> algorithms" using Python that Konrad refers to? More importantly, how
> many people?

At least one: me.

> >  Guido thinks that 2/3 returning 0 was a design mistake,
> > but not that math.sqrt(-1) raising an exception is a mistake.  Most Python
> > users won't know what to do with a complex number, so it's "an error" to
> > them.
>
> Guido's philosophy is clearly that Python defaults should be geared to
> "Most Python users". I agree, and as I wrote in an earlier post, the

It's difficult to say what "most Python users" want; it's not a static
community. I'd say the basic principle is "no bad surprises".  2/3 ==
0 is a bad surprise for anyone who knows elementary math but is not
familiar with certain programming languages, especially since the
program goes on silently with a "wrong" intermediate result.

> Maybe we can have true 754 compliance in Py3k, and we can all be happy!!

Py3k forever!

Konrad.
--
-------------------------------------------------------------------------------
Konrad Hinsen                            | E-Mail: hinsen@cnrs-orleans.fr
Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24
Rue Charles Sadron                       | Fax:  +33-2.38.63.15.17
45071 Orleans Cedex 2                    | Deutsch/Esperanto/English/
France                                   | Nederlands/Francais
-------------------------------------------------------------------------------


From Nicolas.Chauvat@logilab.fr  Wed Oct 18 09:35:02 2000
From: Nicolas.Chauvat@logilab.fr (Nicolas Chauvat)
Date: Wed, 18 Oct 2000 10:35:02 +0200 (CEST)
Subject: [Python-Dev] Re: [XML-SIG] PyXML home page on SF
In-Reply-To: <200010172151.XAA00871@loewis.home.cs.tu-berlin.de>
Message-ID: <Pine.LNX.4.21.0010181025220.12124-100000@aries>

On Tue, 17 Oct 2000, Martin v. Loewis wrote:

[about my suggestion concerning a SourceForge dedicated to python]

That was only a suggestion, not a demand as someone stated. I would love
to set up a pythonforge myself if I had the resources, unfortunately I
don't... maybe in a few months? Time will tell. For now I'll just go
back to hacking and keep quiet.

Cheers, :)

--=20
Nicolas Chauvat

http://www.logilab.com - "Mais o=F9 est donc Ornicar ?" - LOGILAB, Paris (F=
rance)



From barry@scottb.demon.co.uk  Wed Oct 18 10:57:04 2000
From: barry@scottb.demon.co.uk (Barry Scott)
Date: Wed, 18 Oct 2000 10:57:04 +0100
Subject: [Python-Dev] build problems large and small on FreeBSD
In-Reply-To: <200010171406.JAA09272@cj20424-a.reston1.va.home.com>
Message-ID: <001401c038e9$c4cabbd0$060210ac@private>

O.k. will do, hopefully this weekend.

		BArry

> -----Original Message-----
> From: guido@cj20424-a.reston1.va.home.com
> [mailto:guido@cj20424-a.reston1.va.home.com]On Behalf Of Guido van
> Rossum
> Sent: 17 October 2000 15:06
> To: Barry Scott
> Cc: jeremy@beopen.com; python-dev@python.org
> Subject: Re: [Python-Dev] build problems large and small on FreeBSD
> 
> 
> > The FreeBSD ports collection had to be updated to support
> > importing C++ extensions with Python 1.5.2. (You get things
> > like cout not defined when importing).
> > 
> > Are the nessesary compile/link changes in 2.0?
> 
> Tell you what: I have no idea. :-(
> 
> I believe there were some changes to the Makefile and/or config file
> to support C++, but I don't know if this works on FreeBSD.  I'm not a
> big C++ user myself, so I rarely try this...
> 
> Can you try it?  If it doesn't work out of the box, let's sit down
> together and figure out a fix.
> 
> --Guido van Rossum (home page: http://www.python.org/~guido/)
> 
> 


From mal@lemburg.com  Wed Oct 18 17:03:16 2000
From: mal@lemburg.com (M.-A. Lemburg)
Date: Wed, 18 Oct 2000 18:03:16 +0200
Subject: [Python-Dev] Ready for Python 2.1 ?
Message-ID: <39EDC9C4.7D61454@lemburg.com>

Before starting to work on postponed patches and checking them
in: is the current CVS tree ready for new checkins (tags applied,
etc.) ?

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/


From fdrake@beopen.com  Wed Oct 18 17:29:45 2000
From: fdrake@beopen.com (Fred L. Drake, Jr.)
Date: Wed, 18 Oct 2000 12:29:45 -0400 (EDT)
Subject: [Python-Dev] Ready for Python 2.1 ?
In-Reply-To: <39EDC9C4.7D61454@lemburg.com>
References: <39EDC9C4.7D61454@lemburg.com>
Message-ID: <14829.53241.51394.729109@cj42289-a.reston1.va.home.com>

M.-A. Lemburg writes:
 > Before starting to work on postponed patches and checking them
 > in: is the current CVS tree ready for new checkins (tags applied,
 > etc.) ?

  Yes; I posted a note re-opening the tree yesterday (or late Monday
night; I can't remember that far back).
  We've just been too tired to do a lot since the release.  ;)


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member



From tim_one@email.msn.com  Wed Oct 18 17:52:52 2000
From: tim_one@email.msn.com (Tim Peters)
Date: Wed, 18 Oct 2000 12:52:52 -0400
Subject: [Python-Dev] Ready for Python 2.1 ?
In-Reply-To: <14829.53241.51394.729109@cj42289-a.reston1.va.home.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCOEMMHLAA.tim_one@email.msn.com>

[Fred L. Drake, Jr.]
> ...
>   We've just been too tired to do a lot since the release.  ;)

LOL!  You're the very soul of diplomacy, Fred -- but I guess, overall, it
really is prudent not to mention all our recent suicide attempts <wink>.

my-wrists-are-killing-me-ly y'rs  - tim




From skip@mojam.com (Skip Montanaro)  Wed Oct 18 18:19:25 2000
From: skip@mojam.com (Skip Montanaro) (Skip Montanaro)
Date: Wed, 18 Oct 2000 12:19:25 -0500 (CDT)
Subject: [Python-Dev] Ready for Python 2.1 ?
In-Reply-To: <LNBBLJKPBEHFEDALKOLCOEMMHLAA.tim_one@email.msn.com>
References: <14829.53241.51394.729109@cj42289-a.reston1.va.home.com>
 <LNBBLJKPBEHFEDALKOLCOEMMHLAA.tim_one@email.msn.com>
Message-ID: <14829.56221.303087.523464@beluga.mojam.com>

    Tim> my-wrists-are-killing-me-ly y'rs  - tim

You need my typing watcher:

    http://www.musi-cal.com/~skip/python/watch.py

Only problem is I never figured out how to make it watch keystrokes
directly.  It detects mouse movement.  Since I do most of my typing in
Emacs, I fudged the keystroke thing by having the auto-save hook jiggle the
mouse a little...

I've tried, so far unsuccessfully, to make this a SourceForge project.  I've
even asked for help from SF, but their response wasn't helpful, and the
round-trip time for a response is too long to make pursuing that path
worthwhile.  The watch project is at

    http://sourceforge.net/projects/watch/

All I have is a CVSROOT/modules file.  Nothing I've tried has successfully
imported the one project file into cvs.

If anyone has any suggestions for kickstarting this thing, it would be much
appreciated.

Thx,

Skip



From thomas@xs4all.net  Wed Oct 18 19:43:19 2000
From: thomas@xs4all.net (Thomas Wouters)
Date: Wed, 18 Oct 2000 20:43:19 +0200
Subject: [Python-Dev] Ready for Python 2.1 ?
In-Reply-To: <14829.56221.303087.523464@beluga.mojam.com>; from skip@mojam.com on Wed, Oct 18, 2000 at 12:19:25PM -0500
References: <14829.53241.51394.729109@cj42289-a.reston1.va.home.com> <LNBBLJKPBEHFEDALKOLCOEMMHLAA.tim_one@email.msn.com> <14829.56221.303087.523464@beluga.mojam.com>
Message-ID: <20001018204319.L12812@xs4all.nl>

On Wed, Oct 18, 2000 at 12:19:25PM -0500, Skip Montanaro wrote:

>     Tim> my-wrists-are-killing-me-ly y'rs  - tim

> You need my typing watcher:

Given his remark about suicide attempts, I'm not sure if Tim really meant
'RSI' when he wrote that :-)

>     http://www.musi-cal.com/~skip/python/watch.py

> Only problem is I never figured out how to make it watch keystrokes
> directly.  It detects mouse movement.  Since I do most of my typing in
> Emacs, I fudged the keystroke thing by having the auto-save hook jiggle the
> mouse a little...

Funny, a colleague of mine has a similar tool. Also written in Python, I
think, though it may have been created in his Perl Period. On a linux box,
you can determine keystrokes by using /proc/interrupts. At least, if your
keyboard has an interrupt all for itself. (Pretty likely, really :)

-- 
Thomas Wouters <thomas@xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!


From skip@mojam.com (Skip Montanaro)  Wed Oct 18 20:11:20 2000
From: skip@mojam.com (Skip Montanaro) (Skip Montanaro)
Date: Wed, 18 Oct 2000 14:11:20 -0500 (CDT)
Subject: [Python-Dev] Ready for Python 2.1 ?
In-Reply-To: <20001018204319.L12812@xs4all.nl>
References: <14829.53241.51394.729109@cj42289-a.reston1.va.home.com>
 <LNBBLJKPBEHFEDALKOLCOEMMHLAA.tim_one@email.msn.com>
 <14829.56221.303087.523464@beluga.mojam.com>
 <20001018204319.L12812@xs4all.nl>
Message-ID: <14829.62936.109759.567547@beluga.mojam.com>

    Thomas> On a linux box, you can determine keystrokes by using
    Thomas> /proc/interrupts. At least, if your keyboard has an interrupt
    Thomas> all for itself. (Pretty likely, really :)

Thanks, Neil S. sent me a patch for that already.  I'll try to work it into
the code.  Anyone have any idea how to monitor keystrokes on Windows, Mac or
other Unix flavors?  I suspect I'll just have to bite the bullet and work in
platform-dependent code for this.

Skip


From esr@thyrsus.com  Wed Oct 18 20:36:01 2000
From: esr@thyrsus.com (Eric S. Raymond)
Date: Wed, 18 Oct 2000 15:36:01 -0400
Subject: [Python-Dev] Ready for Python 2.1 ?
In-Reply-To: <14829.62936.109759.567547@beluga.mojam.com>; from skip@mojam.com on Wed, Oct 18, 2000 at 02:11:20PM -0500
References: <14829.53241.51394.729109@cj42289-a.reston1.va.home.com> <LNBBLJKPBEHFEDALKOLCOEMMHLAA.tim_one@email.msn.com> <14829.56221.303087.523464@beluga.mojam.com> <20001018204319.L12812@xs4all.nl> <14829.62936.109759.567547@beluga.mojam.com>
Message-ID: <20001018153601.A18127@thyrsus.com>

Skip Montanaro <skip@mojam.com>:
> Thanks, Neil S. sent me a patch for that already.  I'll try to work it into
> the code.  Anyone have any idea how to monitor keystrokes on Windows, Mac or
> other Unix flavors?  I suspect I'll just have to bite the bullet and work in
> platform-dependent code for this.

Might this monitoring function be a candidate for the Python library when 
it's done?
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

A man with a gun is a citizen.  A man without a gun is a subject.


From cgw@fnal.gov  Wed Oct 18 20:53:09 2000
From: cgw@fnal.gov (Charles G Waldman)
Date: Wed, 18 Oct 2000 14:53:09 -0500 (CDT)
Subject: [Python-Dev] Ready for Python 2.1 ?
In-Reply-To: <14829.62936.109759.567547@beluga.mojam.com>
References: <14829.53241.51394.729109@cj42289-a.reston1.va.home.com>
 <LNBBLJKPBEHFEDALKOLCOEMMHLAA.tim_one@email.msn.com>
 <14829.56221.303087.523464@beluga.mojam.com>
 <20001018204319.L12812@xs4all.nl>
 <14829.62936.109759.567547@beluga.mojam.com>
Message-ID: <14829.65445.421622.258893@buffalo.fnal.gov>

Skip Montanaro writes:
 > 
 > Thanks, Neil S. sent me a patch for that already.  I'll try to work it into
 > the code.  Anyone have any idea how to monitor keystrokes on Windows, Mac or
 > other Unix flavors?  I suspect I'll just have to bite the bullet and work in
 > platform-dependent code for this.

Can't tell you about Windows or Mac, but for Unix I'd read the file
driver/timers.c in the XScreensaver distribution (www.jwz.org).  This
code is pretty sophisticated and runs on all the major Unix flavors.


From skip@mojam.com (Skip Montanaro)  Wed Oct 18 21:22:45 2000
From: skip@mojam.com (Skip Montanaro) (Skip Montanaro)
Date: Wed, 18 Oct 2000 15:22:45 -0500 (CDT)
Subject: [Python-Dev] Ready for Python 2.1 ?
In-Reply-To: <14829.65445.421622.258893@buffalo.fnal.gov>
References: <14829.53241.51394.729109@cj42289-a.reston1.va.home.com>
 <LNBBLJKPBEHFEDALKOLCOEMMHLAA.tim_one@email.msn.com>
 <14829.56221.303087.523464@beluga.mojam.com>
 <20001018204319.L12812@xs4all.nl>
 <14829.62936.109759.567547@beluga.mojam.com>
 <14829.65445.421622.258893@buffalo.fnal.gov>
Message-ID: <14830.1685.932659.181060@beluga.mojam.com>

    Charles> ... but for Unix I'd read the file driver/timers.c in the
    Charles> XScreensaver distribution (www.jwz.org).  This code is pretty
    Charles> sophisticated and runs on all the major Unix flavors.

Thanks, Charles.  I will check it out.

Those of you who are former (or current) od users will appreciate Jamie
Zawinski's home page even if you're not interested in this topic.  I revisit
his site periodically.  I'm never disappointed...

Skip


From est@hyperreal.org  Wed Oct 18 21:30:46 2000
From: est@hyperreal.org (est@hyperreal.org)
Date: Wed, 18 Oct 2000 13:30:46 -0700 (PDT)
Subject: [Python-Dev] Ready for Python 2.1 ?
In-Reply-To: <14830.1685.932659.181060@beluga.mojam.com> from Skip Montanaro
 at "Oct 18, 2000 03:22:45 pm"
Message-ID: <20001018203047.27215.qmail@hyperreal.org>

Skip Montanaro discourseth:
> 
> Those of you who are former (or current) od users will appreciate Jamie
> Zawinski's home page even if you're not interested in this topic.  I revisit
> his site periodically.  I'm never disappointed...

Looks more like emacs hexl-mode to me.

Hmm..I guess you got this thread off topic. :)

E


From martin@loewis.home.cs.tu-berlin.de  Wed Oct 18 22:09:36 2000
From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Wed, 18 Oct 2000 23:09:36 +0200
Subject: [Python-Dev] This Project Has Not Released Any Files
Message-ID: <200010182109.XAA00917@loewis.home.cs.tu-berlin.de>

What is the reason for not publishing Python 2.0 on SF for download?
SF certainly wouldn't be the primary source, but I think at least the
source distribution should be available there, with the release notes
telling where to get binary distributions (BeOpen, ActiveState, who
else?)

Regards,
Martin



From tim_one@email.msn.com  Wed Oct 18 22:34:38 2000
From: tim_one@email.msn.com (Tim Peters)
Date: Wed, 18 Oct 2000 17:34:38 -0400
Subject: [Python-Dev] This Project Has Not Released Any Files
In-Reply-To: <200010182109.XAA00917@loewis.home.cs.tu-berlin.de>
Message-ID: <LNBBLJKPBEHFEDALKOLCAENKHLAA.tim_one@email.msn.com>

[Martin v. Loewis]
> What is the reason for not publishing Python 2.0 on SF for download?

From BeOpen.com's POV, so long as they were paying major bills, they would
rather have download traffic tickle their ad banners than SF's ad banners.

From our (PythonLabs) POV, another publishing site is more work, and one URL
is about as good as any other.  Besides, rising to the top of SF's "most
active" list has not been an explicit life goal for any of us <wink>.

> SF certainly wouldn't be the primary source, but I think at least the
> source distribution should be available there, with the release notes
> telling where to get binary distributions (BeOpen, ActiveState, who
> else?)

I didn't see any advantage claimed for publishing on SF.  Without an
advantage, the work/benefit ratio is infinite.




From gstein@lyra.org  Wed Oct 18 23:44:13 2000
From: gstein@lyra.org (Greg Stein)
Date: Wed, 18 Oct 2000 15:44:13 -0700
Subject: [Python-Dev] This Project Has Not Released Any Files
In-Reply-To: <LNBBLJKPBEHFEDALKOLCAENKHLAA.tim_one@email.msn.com>; from tim_one@email.msn.com on Wed, Oct 18, 2000 at 05:34:38PM -0400
References: <200010182109.XAA00917@loewis.home.cs.tu-berlin.de> <LNBBLJKPBEHFEDALKOLCAENKHLAA.tim_one@email.msn.com>
Message-ID: <20001018154413.A31010@lyra.org>

On Wed, Oct 18, 2000 at 05:34:38PM -0400, Tim Peters wrote:
> [Martin v. Loewis]
> > What is the reason for not publishing Python 2.0 on SF for download?
> 
> >From BeOpen.com's POV, so long as they were paying major bills, they would
> rather have download traffic tickle their ad banners than SF's ad banners.
> 
> >From our (PythonLabs) POV, another publishing site is more work, and one URL
> is about as good as any other.  Besides, rising to the top of SF's "most
> active" list has not been an explicit life goal for any of us <wink>.

And here is where the larger community can help. Presuming that non-admins
can publish files, then we could take on the burden of publishing the files
via SF.

> > SF certainly wouldn't be the primary source, but I think at least the
> > source distribution should be available there, with the release notes
> > telling where to get binary distributions (BeOpen, ActiveState, who
> > else?)
> 
> I didn't see any advantage claimed for publishing on SF.  Without an
> advantage, the work/benefit ratio is infinite.

Work == 0 for you guys, presuming that non-admins can publish.

[ off to take a look... ]

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/


From akuchlin@mems-exchange.org  Thu Oct 19 17:20:37 2000
From: akuchlin@mems-exchange.org (Andrew Kuchling)
Date: Thu, 19 Oct 2000 12:20:37 -0400
Subject: [Python-Dev] 2.0 articles
Message-ID: <20001019122037.C21214@kronos.cnri.reston.va.us>

Before we all become focused on new features for Python 2.1, it would
be nice to do a bit more work on raising awareness of the new features
in 2.0.  There's little point in developing software if you don't
actually tell anyone about it, after all.

I'd like to suggest that people try to write some brief articles, just
a few pages long, each covering a particular feature in some detail.

Looking through the list of new stuff, the most significant features are:

* Unicode support.  (Perl's UTF-8 support still seems incomplete, with
  developers referring to it as "unusable", so we should definitely try and
  point out that we have working Unicode support right now.)

* Distutils: an introduction to writing setup scripts for simple
  Python modules, packages, and C extensions.

* The new XML tools.

* The new gettext support.

* Maybe the linuxaudiodev module, too.

Any other suggestions?

If the story of how a particular feature was implemented is
interesting, then that would also make a fine topic for a more
developer-oriented publication such as DDJ.  SRE or Unicode may be the
best candidates for this sort of thing, as their implementation
presented various tricky technical problems along the way.

Any volunteers?

--amk


From gvwilson@nevex.com  Thu Oct 19 17:53:31 2000
From: gvwilson@nevex.com (Greg Wilson)
Date: Thu, 19 Oct 2000 12:53:31 -0400 (EDT)
Subject: [Python-Dev] 2.0 articles
In-Reply-To: <20001019122037.C21214@kronos.cnri.reston.va.us>
Message-ID: <Pine.LNX.4.10.10010191237320.8628-100000@akbar.nevex.com>

> Andrew Kuchling wrote:
> Before we all become focused on new features for Python 2.1, it would be
> nice to do a bit more work on raising awareness of the new features in 2.0.  

"Doctor Dobb's Journal" would be very interested in articles --- 3000 words
(plus or minus), plus some code examples and diagrams.

> * Unicode support.  (Perl's UTF-8 support still seems incomplete, with
>   developers referring to it as "unusable", so we should definitely try and
>   point out that we have working Unicode support right now.)

Definitely --- the practical details of implementing Unicode, and a
Unicode-aware regular expression engine, would be very interesting to our
readers.  However, please steer clear of saying, "And anyway, Perl is broken."
(I just got a review copy of Hunt and Thomas's book on Ruby.  There are three
places in the first two chapters where they say, "And Ruby has more users in
Japan than Python."  I'll finish the book anyway.)

> * Distutils: an introduction to writing setup scripts for simple
>   Python modules, packages, and C extensions.

Possibly interesting; would be more so if Distutils could be applied/was being
applied to installation problems in other languages.

> * The new XML tools.

Definitely.

> * The new gettext support.
> * Maybe the linuxaudiodev module, too.

These are both probably too specialized...

> Any other suggestions?

The garbage collector: Java and Ruby both score points by having full garbage
collection, so its availability in Python 2.0 (along with a discussion of the
things that might break or change as a result) would be very interesting.

Thanks,
Greg (a contributing editor with DDJ)




From nas@arctrix.com  Thu Oct 19 11:09:52 2000
From: nas@arctrix.com (Neil Schemenauer)
Date: Thu, 19 Oct 2000 03:09:52 -0700
Subject: [Python-Dev] 2.0 articles
In-Reply-To: <Pine.LNX.4.10.10010191237320.8628-100000@akbar.nevex.com>; from gvwilson@nevex.com on Thu, Oct 19, 2000 at 12:53:31PM -0400
References: <20001019122037.C21214@kronos.cnri.reston.va.us> <Pine.LNX.4.10.10010191237320.8628-100000@akbar.nevex.com>
Message-ID: <20001019030952.A32671@glacier.fnational.com>

On Thu, Oct 19, 2000 at 12:53:31PM -0400, Greg Wilson wrote:
> The garbage collector: Java and Ruby both score points by having full garbage
> collection, so its availability in Python 2.0 (along with a discussion of the
> things that might break or change as a result) would be very interesting.

This is on my todo list.  I think there are some interesting
implementation issues.  Also, the article would be useful
documentation for python-dev type people.

  Neil


From akuchlin@mems-exchange.org  Thu Oct 19 18:32:08 2000
From: akuchlin@mems-exchange.org (Andrew Kuchling)
Date: Thu, 19 Oct 2000 13:32:08 -0400
Subject: [Python-Dev] 2.0 articles
In-Reply-To: <Pine.LNX.4.10.10010191237320.8628-100000@akbar.nevex.com>; from gvwilson@nevex.com on Thu, Oct 19, 2000 at 12:53:31PM -0400
References: <20001019122037.C21214@kronos.cnri.reston.va.us> <Pine.LNX.4.10.10010191237320.8628-100000@akbar.nevex.com>
Message-ID: <20001019133208.D21214@kronos.cnri.reston.va.us>

On Thu, Oct 19, 2000 at 12:53:31PM -0400, Greg Wilson wrote:
>"Doctor Dobb's Journal" would be very interested in articles --- 3000 words
>(plus or minus), plus some code examples and diagrams.

I was thinking more about on-line places such as
oreillynet.com/python/, but DDJ would be better still.

>The garbage collector: Java and Ruby both score points by having full garbage
>collection, so its availability in Python 2.0 (along with a discussion of the
>things that might break or change as a result) would be very interesting.

Arising out of lunch-time discussion, a comparison of how different
FFIs (Lisp, Java, Smalltalk, others?) deal with garbage collection
would be interesting, though perhaps unsuitable for DDJ, since the
topic is a rather unfocused one.

--amk



From martin@loewis.home.cs.tu-berlin.de  Thu Oct 19 18:31:58 2000
From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Thu, 19 Oct 2000 19:31:58 +0200
Subject: [Python-Dev] This Project Has Not Released Any Files
Message-ID: <200010191731.TAA01114@loewis.home.cs.tu-berlin.de>

[Tim Peters]
> From BeOpen.com's POV, so long as they were paying major bills, they
> would rather have download traffic tickle their ad banners than SF's
> ad banners.

Even though this should have been clear to me all the time, stating it
explicitly triggers alarms for me.

I just checked, and it appears that Python 2.0 is not available for
download via ftp. In particular, it is not available via ftp from
ftp.python.org! If it was there, mirrors all over the world would pick
it up and bring it in a location near me (ftp.fu-berlin.de would be
nearest) (*).

So while making it available on SF may indeed give no advantage,
making it available on python.org would provide users with alternative
download locations, so that I don't feel the bandwidth limitation that
Web download from pythonlabs.com produces. That would be a clear
advantage to me, at least.

Of course, having ftp mirrors would mean that many downloads do not
tickle anybody's ad banners - which would probably be in the interest
of other users as well, just not in the interest of BeOpen. So I'm
curious how this conflict of interest is resolved...

Regards,
Martin

(*) ftp://ftp.python.org/python/src/README does not even mention
Python 2.0, and ftp://ftp.python.org/python/src/README.ftp says

Note that some mirrors only collect the this directory (src), and the
doc and contrib siblings, while the ftp master site,
<URL:ftp://ftp.python.org/>, has much more.

"Much more" may be true, just nothing recent... I probably should ask
ftpmaster.python.org to put Python-2.0.tar.gz in that directory.


From akuchlin@mems-exchange.org  Thu Oct 19 18:42:19 2000
From: akuchlin@mems-exchange.org (Andrew Kuchling)
Date: Thu, 19 Oct 2000 13:42:19 -0400
Subject: [Python-Dev] This Project Has Not Released Any Files
In-Reply-To: <200010191731.TAA01114@loewis.home.cs.tu-berlin.de>; from martin@loewis.home.cs.tu-berlin.de on Thu, Oct 19, 2000 at 07:31:58PM +0200
References: <200010191731.TAA01114@loewis.home.cs.tu-berlin.de>
Message-ID: <20001019134219.A29218@kronos.cnri.reston.va.us>

On Thu, Oct 19, 2000 at 07:31:58PM +0200, Martin v. Loewis wrote:
>(*) ftp://ftp.python.org/python/src/README does not even mention
>Python 2.0, and ftp://ftp.python.org/python/src/README.ftp says

Unless one of the BeOpen Pythoneers is already going to do this, I'll
go ahead and drop the relevant files into places.  Guys?

While we're at it, how about making the filenames for the source code
consistent? 

-rw-r--r--    1 guido    psa       2533053 Apr 13  1999 py152.tgz
-rw-r--r--    1 1103     psa       2259957 Oct 31  1998 pyth151.tgz
-rw-r--r--    1 guido    psa       1907724 May 31  1995 python1.2.tar.gz
-rw-r--r--    1 guido    psa       2037062 Oct 12  1995 python1.3.tar.gz
-rw-r--r--    1 guido    psa       2252481 Oct 25  1996 python1.4.tar.gz
-rw-r--r--    1 guido    psa       2904353 Jan  3  1998 python1.5.tar.gz

I like pythonX.X.tar.gz best, and will change the filenames (leaving
bc-compat symlinks for py152.tgz and pyth151.tgz) unless vetoed.
Though isn't the standard GNU naming convention more like
python-1.5.tar.gz?

--amk


From esr@thyrsus.com  Thu Oct 19 19:05:48 2000
From: esr@thyrsus.com (Eric S. Raymond)
Date: Thu, 19 Oct 2000 14:05:48 -0400
Subject: [Python-Dev] This Project Has Not Released Any Files
In-Reply-To: <20001019134219.A29218@kronos.cnri.reston.va.us>; from akuchlin@mems-exchange.org on Thu, Oct 19, 2000 at 01:42:19PM -0400
References: <200010191731.TAA01114@loewis.home.cs.tu-berlin.de> <20001019134219.A29218@kronos.cnri.reston.va.us>
Message-ID: <20001019140548.A21315@thyrsus.com>

Andrew Kuchling <akuchlin@mems-exchange.org>:
> I like pythonX.X.tar.gz best, and will change the filenames (leaving
> bc-compat symlinks for py152.tgz and pyth151.tgz) unless vetoed.
> Though isn't the standard GNU naming convention more like
> python-1.5.tar.gz?

It is, and I wish we'd move to it as did the Perl guys.  It makes life
substantially easier to have really uniform naming conventions,
especially for programs like the Metalabs file clerk.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Don't ever think you know what's right for the other person.
He might start thinking he knows what's right for you.
	-- Paul Williams, `Das Energi'


From mwh21@cam.ac.uk  Thu Oct 19 19:01:29 2000
From: mwh21@cam.ac.uk (Michael Hudson)
Date: 19 Oct 2000 19:01:29 +0100
Subject: [Python-Dev] 2.0 articles
In-Reply-To: Andrew Kuchling's message of "Thu, 19 Oct 2000 12:20:37 -0400"
References: <20001019122037.C21214@kronos.cnri.reston.va.us>
Message-ID: <m3d7gwsoau.fsf@atrus.jesus.cam.ac.uk>

Andrew Kuchling <akuchlin@mems-exchange.org> writes:

> Before we all become focused on new features for Python 2.1, it would
> be nice to do a bit more work on raising awareness of the new features
> in 2.0.  There's little point in developing software if you don't
> actually tell anyone about it, after all.
> 
> I'd like to suggest that people try to write some brief articles, just
> a few pages long, each covering a particular feature in some detail.
[snip]
> Any volunteers?

It's not as exciting as Unicode or XML, but I've thrashed out a few
hundred words on the new "setdefault" dictionary method.  It's up
here:

http://starship.python.net/crew/mwh/hacks/setdefault.html

Tell me what you think!  There's the beginning of a longer example in
a comment at the bottom, but I felt it was getting a bit long-winded
to be of interest.

Cheers,
M.

-- 
  If i don't understand lisp,  it would be wise to not bray about
  how lisp is stupid or otherwise criticize, because my stupidity 
  would be archived and open for all in the know to see.
                                                -- Xah, comp.lang.lisp



From gstein@lyra.org  Thu Oct 19 19:52:53 2000
From: gstein@lyra.org (Greg Stein)
Date: Thu, 19 Oct 2000 11:52:53 -0700
Subject: [Python-Dev] This Project Has Not Released Any Files
In-Reply-To: <200010191731.TAA01114@loewis.home.cs.tu-berlin.de>; from martin@loewis.home.cs.tu-berlin.de on Thu, Oct 19, 2000 at 07:31:58PM +0200
References: <200010191731.TAA01114@loewis.home.cs.tu-berlin.de>
Message-ID: <20001019115253.W31108@lyra.org>

On Thu, Oct 19, 2000 at 07:31:58PM +0200, Martin v. Loewis wrote:
>...
> Of course, having ftp mirrors would mean that many downloads do not
> tickle anybody's ad banners - which would probably be in the interest
> of other users as well, just not in the interest of BeOpen. So I'm
> curious how this conflict of interest is resolved...

Stating that a "conflict of interest" even EXISTS is a rather sorry
statement on things.

-g

-- 
Greg Stein, http://www.lyra.org/


From gstein@lyra.org  Thu Oct 19 19:54:36 2000
From: gstein@lyra.org (Greg Stein)
Date: Thu, 19 Oct 2000 11:54:36 -0700
Subject: [Python-Dev] This Project Has Not Released Any Files
In-Reply-To: <20001019134219.A29218@kronos.cnri.reston.va.us>; from akuchlin@mems-exchange.org on Thu, Oct 19, 2000 at 01:42:19PM -0400
References: <200010191731.TAA01114@loewis.home.cs.tu-berlin.de> <20001019134219.A29218@kronos.cnri.reston.va.us>
Message-ID: <20001019115436.X31108@lyra.org>

On Thu, Oct 19, 2000 at 01:42:19PM -0400, Andrew Kuchling wrote:
> On Thu, Oct 19, 2000 at 07:31:58PM +0200, Martin v. Loewis wrote:
> >(*) ftp://ftp.python.org/python/src/README does not even mention
> >Python 2.0, and ftp://ftp.python.org/python/src/README.ftp says
> 
> Unless one of the BeOpen Pythoneers is already going to do this, I'll
> go ahead and drop the relevant files into places.  Guys?

Please... just do it.

>...
> I like pythonX.X.tar.gz best, and will change the filenames (leaving
> bc-compat symlinks for py152.tgz and pyth151.tgz) unless vetoed.
> Though isn't the standard GNU naming convention more like
> python-1.5.tar.gz?

I'm with Eric -- go for the GNU standard.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/


From akuchlin@mems-exchange.org  Thu Oct 19 20:11:42 2000
From: akuchlin@mems-exchange.org (Andrew Kuchling)
Date: Thu, 19 Oct 2000 15:11:42 -0400
Subject: [Python-Dev] This Project Has Not Released Any Files
In-Reply-To: <20001019115436.X31108@lyra.org>; from gstein@lyra.org on Thu, Oct 19, 2000 at 11:54:36AM -0700
References: <200010191731.TAA01114@loewis.home.cs.tu-berlin.de> <20001019134219.A29218@kronos.cnri.reston.va.us> <20001019115436.X31108@lyra.org>
Message-ID: <20001019151142.A29651@kronos.cnri.reston.va.us>

On Thu, Oct 19, 2000 at 11:54:36AM -0700, Greg Stein wrote:
>On Thu, Oct 19, 2000 at 01:42:19PM -0400, Andrew Kuchling wrote:
>> Unless one of the BeOpen Pythoneers is already going to do this, I'll
>> go ahead and drop the relevant files into places.  Guys?

>Please... just do it.

I charged ahead and did it anyway; the Pythoneers can spank me for it
later.  (Worse, maybe they'll do something *bad* to me...)  There were
already doc/1.6/ and doc/2.0/ directories, and binaries (Windows,
RPMs) were in /pub/python/2.0/, along with the source. 

So I only touched /pub/python/src/.  All the releases and betas are
now consistently named python-X.Y.Z.tar.gz.  I've left symlinks in
place for the original filenames of the 1.5.1, 1.5.2 and 1.6 final
releases, but didn't bother making links for releases older than 1.5.1
or for beta versions, so any FTP URLs pointing directly to those files
will be broken.

--amk


From jeremy@beopen.com  Fri Oct 20 17:28:19 2000
From: jeremy@beopen.com (Jeremy Hylton)
Date: Fri, 20 Oct 2000 12:28:19 -0400 (EDT)
Subject: [Python-Dev] This Project Has Not Released Any Files
In-Reply-To: <20001019115436.X31108@lyra.org>
References: <200010191731.TAA01114@loewis.home.cs.tu-berlin.de>
 <20001019134219.A29218@kronos.cnri.reston.va.us>
 <20001019115436.X31108@lyra.org>
Message-ID: <14832.29347.622325.95025@bitdiddle.concentric.net>

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

  GS> On Thu, Oct 19, 2000 at 01:42:19PM -0400, Andrew Kuchling wrote:
  >> On Thu, Oct 19, 2000 at 07:31:58PM +0200, Martin v. Loewis wrote:
  >> >(*) ftp://ftp.python.org/python/src/README does not even mention
  >> >Python 2.0, and ftp://ftp.python.org/python/src/README.ftp says
  >>
  >> Unless one of the BeOpen Pythoneers is already going to do this,
  >> I'll go ahead and drop the relevant files into places.  Guys?

  GS> Please... just do it.

In the interest of making the distribution as widely available as
possible, I've placed files on SourceForge and at
http://www.python.org/2.0/

  >> ...  I like pythonX.X.tar.gz best, and will change the filenames
  >> (leaving bc-compat symlinks for py152.tgz and pyth151.tgz) unless
  >> vetoed.  Though isn't the standard GNU naming convention more
  >> like python-1.5.tar.gz?

  GS> I'm with Eric -- go for the GNU standard.

I used the file name conventions that we used throughout the 2.0
release cycle, e.g. Python-2.0.tar.gz.  I don't know if that's the GNU
standard or not (didn't realize it was a standard; don't know where to
find said standard; or is it just a custom?)

Jeremy


From jeremy@beopen.com  Fri Oct 20 17:31:47 2000
From: jeremy@beopen.com (Jeremy Hylton)
Date: Fri, 20 Oct 2000 12:31:47 -0400 (EDT)
Subject: [Python-Dev] 2.0 articles
In-Reply-To: <20001019133208.D21214@kronos.cnri.reston.va.us>
References: <20001019122037.C21214@kronos.cnri.reston.va.us>
 <Pine.LNX.4.10.10010191237320.8628-100000@akbar.nevex.com>
 <20001019133208.D21214@kronos.cnri.reston.va.us>
Message-ID: <14832.29555.123226.831103@bitdiddle.concentric.net>

>>>>> "AMK" == Andrew Kuchling <akuchlin@mems-exchange.org> writes:

  AMK> On Thu, Oct 19, 2000 at 12:53:31PM -0400, Greg Wilson wrote:
  >> "Doctor Dobb's Journal" would be very interested in articles ---
  >> 3000 words (plus or minus), plus some code examples and diagrams.

  AMK> I was thinking more about on-line places such as
  AMK> oreillynet.com/python/, but DDJ would be better still.

And, of course, there's the Python conference: http://python9.org/

  >> The garbage collector: Java and Ruby both score points by having
  >> full garbage collection, so its availability in Python 2.0 (along
  >> with a discussion of the things that might break or change as a
  >> result) would be very interesting.

  AMK> Arising out of lunch-time discussion, a comparison of how
  AMK> different FFIs (Lisp, Java, Smalltalk, others?) deal with
  AMK> garbage collection would be interesting, though perhaps
  AMK> unsuitable for DDJ, since the topic is a rather unfocused one.

A comparison of different FFIs with respect to garbage collection
might be interesting; hard to say without seeing what the conclusions
are.

Jeremy


From akuchlin@mems-exchange.org  Fri Oct 20 17:26:56 2000
From: akuchlin@mems-exchange.org (Andrew Kuchling)
Date: Fri, 20 Oct 2000 12:26:56 -0400
Subject: [Python-Dev] This Project Has Not Released Any Files
In-Reply-To: <14832.29347.622325.95025@bitdiddle.concentric.net>; from jeremy@alum.mit.edu on Fri, Oct 20, 2000 at 12:28:19PM -0400
References: <200010191731.TAA01114@loewis.home.cs.tu-berlin.de> <20001019134219.A29218@kronos.cnri.reston.va.us> <20001019115436.X31108@lyra.org> <14832.29347.622325.95025@bitdiddle.concentric.net>
Message-ID: <20001020122656.A9679@kronos.cnri.reston.va.us>

On Fri, Oct 20, 2000 at 12:28:19PM -0400, Jeremy Hylton wrote:
>release cycle, e.g. Python-2.0.tar.gz.  I don't know if that's the GNU
>standard or not (didn't realize it was a standard; don't know where to
>find said standard; or is it just a custom?)

See http://www.cs.utah.edu/dept/old/texinfo/standards/standards.html#SEC24
Though I think here the standard is just codifying an existing custom
that's proved convenient.

www.fsf.org seems unresponsive at the moment, hence the strange link;
is *every* Web site in the world breaking today for some reason?

--amk




From akuchlin@mems-exchange.org  Fri Oct 20 17:28:10 2000
From: akuchlin@mems-exchange.org (Andrew Kuchling)
Date: Fri, 20 Oct 2000 12:28:10 -0400
Subject: [Python-Dev] 2.0 articles
In-Reply-To: <14832.29555.123226.831103@bitdiddle.concentric.net>; from jeremy@alum.mit.edu on Fri, Oct 20, 2000 at 12:31:47PM -0400
References: <20001019122037.C21214@kronos.cnri.reston.va.us> <Pine.LNX.4.10.10010191237320.8628-100000@akbar.nevex.com> <20001019133208.D21214@kronos.cnri.reston.va.us> <14832.29555.123226.831103@bitdiddle.concentric.net>
Message-ID: <20001020122810.B9679@kronos.cnri.reston.va.us>

On Fri, Oct 20, 2000 at 12:31:47PM -0400, Jeremy Hylton wrote:
>And, of course, there's the Python conference: http://python9.org/

That's preaching to the converted, though.  

--amk


From fdrake@acm.org  Fri Oct 20 17:51:44 2000
From: fdrake@acm.org (Fred L. Drake, Jr.)
Date: Fri, 20 Oct 2000 12:51:44 -0400 (EDT)
Subject: [Python-Dev] This Project Has Not Released Any Files
In-Reply-To: <14832.29347.622325.95025@bitdiddle.concentric.net>
References: <200010191731.TAA01114@loewis.home.cs.tu-berlin.de>
 <20001019134219.A29218@kronos.cnri.reston.va.us>
 <20001019115436.X31108@lyra.org>
 <14832.29347.622325.95025@bitdiddle.concentric.net>
Message-ID: <14832.30752.210553.712758@cj42289-a.reston1.va.home.com>

Jeremy Hylton writes:
 > In the interest of making the distribution as widely available as
 > possible, I've placed files on SourceForge and at
 > http://www.python.org/2.0/

  There's a separate python-rpms "Package"; the RPM files should go
there (I think).


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at acm.org>
PythonLabs Team Member



From thomas@xs4all.net  Fri Oct 20 21:21:18 2000
From: thomas@xs4all.net (Thomas Wouters)
Date: Fri, 20 Oct 2000 22:21:18 +0200
Subject: [Python-Dev] Re: Compiling python 2.0
In-Reply-To: <m37l73s8r3.fsf@atrus.jesus.cam.ac.uk>; from mwh21@cam.ac.uk on Fri, Oct 20, 2000 at 06:49:36PM +0100
References: <L3JH5.990$yK.3812548@nnrp3.proxad.net> <m37l73s8r3.fsf@atrus.jesus.cam.ac.uk>
Message-ID: <20001020222118.M12812@xs4all.nl>

On Fri, Oct 20, 2000 at 06:49:36PM +0100, Michael Hudson wrote:
> "Jean-Claude Levieux" <jclevieux@sud2000.com> writes:

> > I just tried to compile Python 2.0.
> > on BSDI BSD/OS 4.0.1

[ Sorry, missed the original message. Used the Archive to find it, tho ]

> Random guess, but you are using a ANSI C compiler, aren't you?  Python
> 2.0 now demands that.

BSDI uses gcc, so that's not the problem. Neither are these three warnings:

/usr/include/math.h:177: warning: function declaration isn't a prototype
/usr/include/math.h:257: warning: function declaration isn't a prototype
/usr/include/wchar.h:17: warning: function declaration isn't a prototype

(or any other warnings regarding 'function decl isn't a prototype)

They are a result of Python using '-Wstrict-prototypes' by default, if the
compiler is gcc. It just means BSDI declares a few functions without
specifying argument lists (prototypes) and has nothing to do with Python
(other than that Python always defines CFLAGS to contain
-Wstrict-prototypes.) There isn't an easy way to get this 'fixed',
unfortunately. If you want to quench the warnings, you'll have to edit
=2E/Makefile, Objects/Makefile, Parser/Makefile, Python/Makefile,
and ./Modules/Makefile.pre. (Do not edit ./Modules/Makefile directly,
because it's overwritten by the 'makesetup' script, which parses the Setup
file.)

As for the other error, that's really an error :(

=2E./libpython2.0.a(fileobject.o): In function =1Fportable_fseek':
/usr/home/thomas/Python-2.0/Objects/fileobject.c:274: undefined
reference to `TELL64'

The problem is that BSDI has an 'off_t' type that is larger than the 'long'
type, and Python's configure makes the flawed assumption that this means
BSDI supports large files (larger than 2Gb.) However, BSDI doesn't. This bug
is even present with BSDI 4.1, and probably more platforms. You can fix this
by editing './config.h' after running './configure', and commenting out the
HAVE_LARGEFILE_SUPPORT line; changing this:

#define HAVE_LARGEFILE_SUPPORT 1

into something like this:

/* #define HAVE_LARGEFILE_SUPPORT 1 */

(You can just remove the line as well.) The downside of both these 'hacks'
(excuse me, 'hotfixes'), is that you'll have to reedit the files again after
running configure again (or something that runs configure, like
'config.status'.)

I see a total of three bugs here: Python adds -Wstrict-prototypes even
though it can generate a lot of warnings that aren't related to Python;
there is no way to override the CFLAGS variable (you can pass it to
configure, and it uses it at first, but then just overwrites it); and
mis-detecting large file support. I can't decide which of the last two is
the biggest bug :-)

I would write a patch for the lot of 'm, but I'm in the middle of getting
ready to head to London for the Apache conference (any other Pythonistas
going ? :) and Have I Got News For You is about to start on BBC1. If you
don't do it, Jean-Claude, I'll submit bugreports on these when I'm back,
next Thursday.

(Oh, another hint: *disable threads* when compiling Python for BSDI 4.0.1.
You can leave them on for 4.1, but 4.0.1 has very broken threads, and it
will cause lots of problems in the signal module if you leave them on. You
can disable them by using '--with-threads=3Dno' -- this is also listed in t=
he
README, by the way. And note that BSDI 4.1 only has the large file support
problem, none of the others, and I strongly suggest upgrading for other
reasons as well.)

Python-dev: CC'd because this is material for a bugfix-release. There are
likely to be other platforms hit by the large filesupport misdetection.
Don't think this is enough to warrant a bugfix release (it's not *that*
brownbaggy) but it should definately go in if there is one ;P If I or
someone else didn't fix it by the time a bugfix release is considered,
please hit me. I also appologize for not properly testing Python 2.0 on BSDI
4.0.1 or 4.1... We still have those machines, but we are using less and less
of them. Out of sight, out of mind, and I'm happier using FreeBSD and Linux
:)

BSDI-isn't-all-bad--it's-just-that-by-now-Linux-and-FreeBSD-have-all-
	-those-good-sides-too-ly y'rs,

--=20
Thomas Wouters <thomas@xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me sp=
read!


From trentm@ActiveState.com  Fri Oct 20 21:54:59 2000
From: trentm@ActiveState.com (Trent Mick)
Date: Fri, 20 Oct 2000 13:54:59 -0700
Subject: [Python-Dev] Re: Compiling python 2.0
In-Reply-To: <20001020222118.M12812@xs4all.nl>; from thomas@xs4all.net on Fri, Oct 20, 2000 at 10:21:18PM +0200
References: <L3JH5.990$yK.3812548@nnrp3.proxad.net> <m37l73s8r3.fsf@atrus.jesus.cam.ac.uk> <20001020222118.M12812@xs4all.nl>
Message-ID: <20001020135459.C1562@ActiveState.com>

On Fri, Oct 20, 2000 at 10:21:18PM +0200, Thomas Wouters wrote:=0D
> As for the other error, that's really an error :(=0D
> =0D
> ../libpython2.0.a(fileobject.o): In function =1Fportable_fseek':=0D
> /usr/home/thomas/Python-2.0/Objects/fileobject.c:274: undefined=0D
> reference to `TELL64'=0D
> =0D
> The problem is that BSDI has an 'off_t' type that is larger than the 'lon=
g'=0D
> type, and Python's configure makes the flawed assumption that this means=
=0D
> BSDI supports large files (larger than 2Gb.) However, BSDI doesn't. This =
bug=0D
> is even present with BSDI 4.1, and probably more platforms. You can fix t=
his=0D
> by editing './config.h' after running './configure', and commenting out t=
he=0D
> HAVE_LARGEFILE_SUPPORT line; changing this:=0D
> =0D
> #define HAVE_LARGEFILE_SUPPORT 1=0D
> =0D
> into something like this:=0D
> =0D
> /* #define HAVE_LARGEFILE_SUPPORT 1 */=0D
> =0D
> (You can just remove the line as well.) The downside of both these 'hacks=
'=0D
> (excuse me, 'hotfixes'), is that you'll have to reedit the files again af=
ter=0D
> running configure again (or something that runs configure, like=0D
> 'config.status'.)=0D
=0D
This one isthe saem problem that showed up for NetBSD1.4.2 and OpenBSD (I s=
ee=0D
a pattern)=0D
http://sourceforge.net/bugs/?func=3Ddetailbug&bug_id=3D112289&group_id=3D54=
70=0D
=0D
It was fixed by adding a hack in fileobject.c to *define* TELL64.=0D
http://sourceforge.net/patch/index.php?func=3Ddetailpatch&patch_id=3D101558=
&group_id=3D5470=0D
=0D
For the quickfix, the same hack could be used for BSDI.=0D
=0D
As you suggest Thomas, the proper fix is to patch configure.in such that it=
=0D
does not report that these system support largefiles.=0D
=0D
I don't have the time to do this right away, nor do I have one of these box=
es=0D
on which to test it. I can try to make a patch though. We don't you file a=
=0D
bug and assign it to me.=0D
=0D
Trent=0D
=0D
=0D
-- =0D
Trent Mick=0D
TrentM@ActiveState.com=0D


From martin@loewis.home.cs.tu-berlin.de  Fri Oct 20 21:54:02 2000
From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Fri, 20 Oct 2000 22:54:02 +0200
Subject: [Python-Dev] This Project Has Released Files
Message-ID: <200010202054.WAA01567@loewis.home.cs.tu-berlin.de>

> In the interest of making the distribution as widely available as
> possible, I've placed files on SourceForge and at
> http://www.python.org/2.0/

Thanks! also to anybody else contributing to the release process, in
particular to amk for his ongoing maintainance of various pieces on
python.org, and his efforts in getting the word out.

Regards,
Martin


From cgw@fnal.gov  Fri Oct 13 16:11:03 2000
From: cgw@fnal.gov (Charles G Waldman)
Date: Fri, 13 Oct 2000 10:11:03 -0500 (CDT)
Subject: [Python-Dev] can't build with threads on OSF/1
Message-ID: <14823.9735.525711.927269@buffalo.fnal.gov>

Sorry, I don't have time to investigate this fully right now.  Maybe
this weekend.  For now this is just a heads-up.  Hopefully, something
is just misconfigured on this system.

The machine in question is running OSF1 V4.0 878 alpha

I can only build Python from current CVS sources on OSF/1 if I specify
--without-thread.   If I don't specify this I get the following errors
at link time:

Unresolved:
__pthread_mutex_init
__pthread_mutex_destroy
__pthread_mutex_lock
__pthread_mutex_unlock
__pthread_cond_init
__pthread_cond_destroy
__pthread_cond_signal
__pthread_cond_wait
__pthread_create
__pthread_detach


Below find the output of cc -V as well as the output of ./configure
and make (sorry for the flood,  I assume too much detail is better
than not enough)

creating cache ./config.cache
checking MACHDEP... osf1V4
checking for --without-gcc... 
checking for --with-cxx=<compiler>... no
checking for gcc... cc
checking whether the C compiler (cc   ) works... yes
checking whether the C compiler (cc   ) is a cross-compiler... no
checking whether we are using GNU C... no
checking whether cc accepts -g... yes
checking for --with-suffix... 
checking LINKCC... $(PURIFY) $(CC)
checking LDLIBRARY... 
checking for ranlib... ranlib
checking for ar... ar
checking how to run the C preprocessor... cc -E
checking for AIX... no
checking for minix/config.h... no
checking whether cc accepts -OPT:Olimit=0... no
checking whether cc accepts -Olimit 1500... yes
checking for ANSI C header files... yes
checking for dlfcn.h... yes
checking for fcntl.h... yes
checking for limits.h... yes
checking for locale.h... yes
checking for ncurses.h... no
checking for poll.h... yes
checking for pthread.h... yes
checking for signal.h... yes
checking for stdarg.h... yes
checking for stddef.h... yes
checking for stdlib.h... yes
checking for thread.h... no
checking for unistd.h... yes
checking for utime.h... yes
checking for sys/audioio.h... no
checking for sys/file.h... yes
checking for sys/lock.h... yes
checking for db_185.h... no
checking for db.h... yes
checking for sys/param.h... yes
checking for sys/select.h... yes
checking for sys/socket.h... yes
checking for sys/time.h... yes
checking for sys/times.h... yes
checking for sys/un.h... yes
checking for sys/utsname.h... yes
checking for sys/wait.h... yes
checking for pty.h... yes
checking for libutil.h... no
checking for ndbm.h... yes
checking for db1/ndbm.h... no
checking for gdbm/ndbm.h... no
checking for dirent.h that defines DIR... yes
checking for opendir in -ldir... no
checking for clock_t in time.h... yes
checking for mode_t... yes
checking for off_t... yes
checking for pid_t... yes
checking return type of signal handlers... void
checking for size_t... yes
checking for uid_t in sys/types.h... yes
checking size of int... 4
checking size of long... 8
checking size of void *... 8
checking size of char... 1
checking size of short... 2
checking size of float... 4
checking size of double... 8
checking size of fpos_t... 8
checking for long long support... yes
checking size of long long... 8
checking for uintptr_t support... no
checking size of off_t... 8
checking whether to enable large file support... no
checking size of time_t... 4
checking for pthread_t... yes
checking size of pthread_t... 8
checking for --with-next-framework... no
checking for --with-dyld... no
checking SO... .so
checking LDSHARED... ld -shared -expect_unresolved "*"
checking CCSHARED... 
checking LINKFORSHARED... 
checking for dlopen in -ldl... no
checking for shl_load in -ldld... no
checking for --with-pydebug... no
checking for t_open in -lnsl... no
checking for socket in -lsocket... no
checking for --with-libs... no
checking for --with-dec-threads... no
checking for --with-threads... yes
checking for mach/cthreads.h... no
checking for --with-pth... no
checking for pthread_create in -lpthread... no
checking for pthread_detach... no
checking for kernel/OS.h... no
checking for pthread_create in -lpthreads... yes
checking for usconfig in -lmpc... no
checking for thr_create in -lthread... no
checking for --with-cycle-gc... yes
checking for --with-libdb... yes
checking for dbopen... no
checking for --with-wctype-functions... no
checking for --with-sgi-dl... no
checking for --with-dl-dld... no
checking for dlopen... yes
checking DYNLOADFILE... dynload_shlib.o
checking for alarm... yes
checking for chown... yes
checking for clock... yes
checking for confstr... yes
checking for ctermid... yes
checking for ctermid_r... no
checking for execv... yes
checking for flock... yes
checking for fork... yes
checking for fsync... yes
checking for fdatasync... yes
checking for fpathconf... yes
checking for ftime... yes
checking for ftruncate... yes
checking for getgroups... yes
checking for getlogin... yes
checking for getpeername... yes
checking for getpid... yes
checking for getpwent... yes
checking for getwd... yes
checking for kill... yes
checking for link... yes
checking for lstat... yes
checking for mkfifo... yes
checking for mktime... yes
checking for mremap... no
checking for nice... yes
checking for pathconf... yes
checking for pause... yes
checking for plock... yes
checking for poll... yes
checking for pthread_init... no
checking for putenv... yes
checking for readlink... yes
checking for select... yes
checking for setegid... yes
checking for seteuid... yes
checking for setgid... yes
checking for setlocale... yes
checking for setregid... yes
checking for setreuid... yes
checking for setsid... yes
checking for setpgid... yes
checking for setuid... yes
checking for setvbuf... yes
checking for sigaction... yes
checking for siginterrupt... yes
checking for sigrelse... yes
checking for strftime... yes
checking for strptime... yes
checking for symlink... yes
checking for sysconf... yes
checking for tcgetpgrp... yes
checking for tcsetpgrp... yes
checking for tempnam... yes
checking for timegm... no
checking for times... yes
checking for tmpfile... yes
checking for tmpnam... yes
checking for tmpnam_r... no
checking for truncate... yes
checking for uname... yes
checking for waitpid... yes
checking for _getpty... no
checking for openpty... yes
checking for forkpty... yes
checking for fseek64... no
checking for fseeko... no
checking for fstatvfs... yes
checking for ftell64... no
checking for ftello... no
checking for statvfs... yes
checking for dup2... yes
checking for getcwd... yes
checking for strdup... yes
checking for strerror... yes
checking for memmove... yes
checking for getpgrp... yes
checking for setpgrp... yes
checking for gettimeofday... yes
checking whether time.h and sys/time.h may both be included... yes
checking whether struct tm is in sys/time.h or time.h... time.h
checking for member tm_zone in aggregate type struct tm... yes
checking for time.h that defines altzone... no
checking whether sys/select.h and sys/time.h may both be included... yes
checking whether char is unsigned... no
checking for working const... yes
checking for inline... __inline
checking for working volatile... yes
checking for working signed char... yes
checking for prototypes... yes
checking for variable length prototypes and stdarg.h... yes
checking for bad exec* prototypes... no
checking for bad static forward... no
checking whether va_list is an array... no
checking for gethostbyname_r... yes
checking gethostbyname_r with 6 args... yes
checking for __fpu_control... no
checking for __fpu_control in -lieee... no
checking for --with-fpectl... no
checking for --with-libm=STRING... default LIBM="-lm"
checking for --with-libc=STRING... default LIBC=""
checking for hypot... yes
checking for genuine getopt... yes
checking what malloc(0) returns... null
checking for wchar.h... yes
checking for usable wchar_t... no
checking whether byte ordering is bigendian... no
checking whether right shift extends the sign bit... yes
checking for socklen_t... no
updating cache ./config.cache
creating ./config.status
creating Makefile
creating Objects/Makefile
creating Parser/Makefile
creating Grammar/Makefile
creating Python/Makefile
creating Modules/Makefile.pre
creating Modules/Setup.config
creating config.h


(cd Modules; make -f Makefile.pre Makefile)
+ cp ./Setup.in Setup 
rm -rf ../libpython2.0.a
/bin/sh ./makesetup Setup.config Setup.local Setup
making Makefile in subdirectory .
`Makefile' is up to date.
making Makefile in subdirectory Parser
`Makefile' is up to date.
making Makefile in subdirectory Grammar
`Makefile' is up to date.
making Makefile in subdirectory Objects
`Makefile' is up to date.
making Makefile in subdirectory Python
`Makefile' is up to date.
making Makefile in subdirectory Modules
`Makefile' is up to date.
(rm -f Modules/hassignal; cd Modules; make hassignal)
rm -f hassignal
for i in threadmodule.o  gcmodule.o  bsddbmodule.o  regexmodule.o regexpr.o  pcremodule.o pypcre.o  posixmodule.o  signalmodule.o  _sre.o  arraymodule.o  cmathmodule.o  mathmodule.o  stropmodule.o  structmodule.o  timemodule.o  operator.o  _codecsmodule.o  unicodedata.o unicodedatabase.o  ucnhash.o  _localemodule.o  fcntlmodule.o  pwdmodule.o  grpmodule.o  errnomodule.o  selectmodule.o  socketmodule.o  mmapmodule.o  md5module.o md5c.o  shamodule.o  rotormodule.o  newmodule.o  binascii.o  parsermodule.o  cStringIO.o  cPickle.o config.o getpath.o main.o getbuildinfo.o; do  if test "$i" = "signalmodule.o"; then  echo yes >hassignal; break;  fi;  done
cd Parser ; make OPT="-O -Olimit 1500" VERSION="2.0"  prefix="/usr/local" exec_prefix="/usr/local" all
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c pgenmain.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c acceler.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c grammar1.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c listnode.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c node.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c parser.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c parsetok.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c tokenizer.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c bitset.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c metagrammar.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c firstsets.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c grammar.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c pgen.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c printgrammar.c
cc -O -Olimit 1500 pgenmain.o acceler.o grammar1.o  listnode.o node.o parser.o  parsetok.o tokenizer.o bitset.o  metagrammar.o firstsets.o grammar.o pgen.o printgrammar.o -lpthreads -o pgen
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c myreadline.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c intrcheck.c
cc: Warning: /usr/include/unistd.h, line 243: The redefinition of the macro "_POSIX_THREADS" conflicts with a current definition because the replacement lists differ.  The redefinition is now in effect.
#define	_POSIX_THREADS		/* 1003.1c (pthreads) comformant */
-------------------------------------------------------------------^
cd Grammar ; make OPT="-O -Olimit 1500" VERSION="2.0"  prefix="/usr/local" exec_prefix="/usr/local" all
../Parser/pgen ./Grammar
Compiling (meta-) parse tree into NFA grammar
Making DFA for 'single_input' ...
Making DFA for 'file_input' ...
Making DFA for 'eval_input' ...
Making DFA for 'funcdef' ...
Making DFA for 'parameters' ...
Making DFA for 'varargslist' ...
Making DFA for 'fpdef' ...
Making DFA for 'fplist' ...
Making DFA for 'stmt' ...
Making DFA for 'simple_stmt' ...
Making DFA for 'small_stmt' ...
Making DFA for 'expr_stmt' ...
Making DFA for 'augassign' ...
Making DFA for 'print_stmt' ...
Making DFA for 'del_stmt' ...
Making DFA for 'pass_stmt' ...
Making DFA for 'flow_stmt' ...
Making DFA for 'break_stmt' ...
Making DFA for 'continue_stmt' ...
Making DFA for 'return_stmt' ...
Making DFA for 'raise_stmt' ...
Making DFA for 'import_stmt' ...
Making DFA for 'import_as_name' ...
Making DFA for 'dotted_as_name' ...
Making DFA for 'dotted_name' ...
Making DFA for 'global_stmt' ...
Making DFA for 'exec_stmt' ...
Making DFA for 'assert_stmt' ...
Making DFA for 'compound_stmt' ...
Making DFA for 'if_stmt' ...
Making DFA for 'while_stmt' ...
Making DFA for 'for_stmt' ...
Making DFA for 'try_stmt' ...
Making DFA for 'except_clause' ...
Making DFA for 'suite' ...
Making DFA for 'test' ...
Making DFA for 'and_test' ...
Making DFA for 'not_test' ...
Making DFA for 'comparison' ...
Making DFA for 'comp_op' ...
Making DFA for 'expr' ...
Making DFA for 'xor_expr' ...
Making DFA for 'and_expr' ...
Making DFA for 'shift_expr' ...
Making DFA for 'arith_expr' ...
Making DFA for 'term' ...
Making DFA for 'factor' ...
Making DFA for 'power' ...
Making DFA for 'atom' ...
Making DFA for 'listmaker' ...
Making DFA for 'lambdef' ...
Making DFA for 'trailer' ...
Making DFA for 'subscriptlist' ...
Making DFA for 'subscript' ...
Making DFA for 'sliceop' ...
Making DFA for 'exprlist' ...
Making DFA for 'testlist' ...
Making DFA for 'dictmaker' ...
Making DFA for 'classdef' ...
Making DFA for 'arglist' ...
Making DFA for 'argument' ...
Making DFA for 'list_iter' ...
Making DFA for 'list_for' ...
Making DFA for 'list_if' ...
Adding FIRST sets ...
Writing graminit.c ...
Writing graminit.h ...
cp graminit.h ./../Include/graminit.h
cp graminit.c ./../Python/graminit.c
cd Objects ; make OPT="-O -Olimit 1500" VERSION="2.0"  prefix="/usr/local" exec_prefix="/usr/local" all
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c abstract.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c bufferobject.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c classobject.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c cobject.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c complexobject.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c fileobject.c
cc: Warning: /usr/include/unistd.h, line 243: The redefinition of the macro "_POSIX_THREADS" conflicts with a current definition because the replacement lists differ.  The redefinition is now in effect.
#define	_POSIX_THREADS		/* 1003.1c (pthreads) comformant */
-------------------------------------------------------------------^
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c floatobject.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c frameobject.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c funcobject.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c intobject.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c listobject.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c longobject.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c dictobject.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c methodobject.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c moduleobject.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c object.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c rangeobject.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c sliceobject.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c stringobject.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c tupleobject.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c typeobject.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c unicodeobject.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c unicodectype.c
cd Python ; make OPT="-O -Olimit 1500" VERSION="2.0"  prefix="/usr/local" exec_prefix="/usr/local" all
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c bltinmodule.c
cc: Warning: /usr/include/unistd.h, line 243: The redefinition of the macro "_POSIX_THREADS" conflicts with a current definition because the replacement lists differ.  The redefinition is now in effect.
#define	_POSIX_THREADS		/* 1003.1c (pthreads) comformant */
-------------------------------------------------------------------^
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c exceptions.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ceval.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c compile.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c codecs.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c errors.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c frozen.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c frozenmain.c
cc: Warning: /usr/include/unistd.h, line 243: The redefinition of the macro "_POSIX_THREADS" conflicts with a current definition because the replacement lists differ.  The redefinition is now in effect.
#define	_POSIX_THREADS		/* 1003.1c (pthreads) comformant */
-------------------------------------------------------------------^
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c getargs.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c getcompiler.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c getcopyright.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c getmtime.c
cc -c -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -DPLATFORM='"osf1V4"'  ./getplatform.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c getversion.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c graminit.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c import.c
cc: Warning: /usr/include/unistd.h, line 243: The redefinition of the macro "_POSIX_THREADS" conflicts with a current definition because the replacement lists differ.  The redefinition is now in effect.
#define	_POSIX_THREADS		/* 1003.1c (pthreads) comformant */
-------------------------------------------------------------------^
cc -c -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -I/ ./importdl.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c marshal.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c modsupport.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c mystrtoul.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c pyfpe.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c pystate.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c pythonrun.c
cc: Warning: /usr/include/unistd.h, line 243: The redefinition of the macro "_POSIX_THREADS" conflicts with a current definition because the replacement lists differ.  The redefinition is now in effect.
#define	_POSIX_THREADS		/* 1003.1c (pthreads) comformant */
-------------------------------------------------------------------^
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c structmember.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c sysmodule.c
cc: Warning: /usr/include/unistd.h, line 243: The redefinition of the macro "_POSIX_THREADS" conflicts with a current definition because the replacement lists differ.  The redefinition is now in effect.
#define	_POSIX_THREADS		/* 1003.1c (pthreads) comformant */
-------------------------------------------------------------------^
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c traceback.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c dynload_shlib.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c thread.c
cc: Warning: /usr/include/unistd.h, line 243: The redefinition of the macro "_POSIX_THREADS" conflicts with a current definition because the replacement lists differ.  The redefinition is now in effect.
#define	_POSIX_THREADS		/* 1003.1c (pthreads) comformant */
-------------------------------------------------------------------^
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c sigcheck.c
cd Modules ; make OPT="-O -Olimit 1500" VERSION="2.0"  prefix="/usr/local" exec_prefix="/usr/local" all
cc  -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./threadmodule.c
cc  -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./gcmodule.c
cc  -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./bsddbmodule.c
cc  -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./regexmodule.c
cc  -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./regexpr.c
cc  -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./pcremodule.c
cc  -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./pypcre.c
cc  -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./posixmodule.c
cc: Warning: /usr/include/unistd.h, line 243: The redefinition of the macro "_POSIX_THREADS" conflicts with a current definition because the replacement lists differ.  The redefinition is now in effect.
#define	_POSIX_THREADS		/* 1003.1c (pthreads) comformant */
-------------------------------------------------------------------^
cc  -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./signalmodule.c
cc: Warning: /usr/include/unistd.h, line 243: The redefinition of the macro "_POSIX_THREADS" conflicts with a current definition because the replacement lists differ.  The redefinition is now in effect.
#define	_POSIX_THREADS		/* 1003.1c (pthreads) comformant */
-------------------------------------------------------------------^
cc  -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./_sre.c
cc  -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./arraymodule.c
cc  -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./cmathmodule.c
cc  -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./mathmodule.c
cc  -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./stropmodule.c
cc  -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./structmodule.c
cc  -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./timemodule.c
cc: Warning: /usr/include/unistd.h, line 243: The redefinition of the macro "_POSIX_THREADS" conflicts with a current definition because the replacement lists differ.  The redefinition is now in effect.
#define	_POSIX_THREADS		/* 1003.1c (pthreads) comformant */
-------------------------------------------------------------------^
cc  -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./operator.c
cc  -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./_codecsmodule.c
cc  -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./unicodedatabase.c
cc  -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./unicodedata.c
cc  -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./ucnhash.c
cc  -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./_localemodule.c
cc  -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./fcntlmodule.c
cc: Warning: /usr/include/unistd.h, line 243: The redefinition of the macro "_POSIX_THREADS" conflicts with a current definition because the replacement lists differ.  The redefinition is now in effect.
#define	_POSIX_THREADS		/* 1003.1c (pthreads) comformant */
-------------------------------------------------------------------^
cc  -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./pwdmodule.c
cc  -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./grpmodule.c
cc  -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./errnomodule.c
cc  -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./selectmodule.c
cc: Warning: /usr/include/unistd.h, line 243: The redefinition of the macro "_POSIX_THREADS" conflicts with a current definition because the replacement lists differ.  The redefinition is now in effect.
#define	_POSIX_THREADS		/* 1003.1c (pthreads) comformant */
-------------------------------------------------------------------^
cc  -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./socketmodule.c
cc: Warning: /usr/include/unistd.h, line 243: The redefinition of the macro "_POSIX_THREADS" conflicts with a current definition because the replacement lists differ.  The redefinition is now in effect.
#define	_POSIX_THREADS		/* 1003.1c (pthreads) comformant */
-------------------------------------------------------------------^
cc  -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./mmapmodule.c
cc: Warning: /usr/include/unistd.h, line 243: The redefinition of the macro "_POSIX_THREADS" conflicts with a current definition because the replacement lists differ.  The redefinition is now in effect.
#define	_POSIX_THREADS		/* 1003.1c (pthreads) comformant */
-------------------------------------------------------------------^
cc  -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./md5module.c
cc  -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./md5c.c
cc  -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./shamodule.c
cc  -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./rotormodule.c
cc  -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./newmodule.c
cc  -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./binascii.c
cc  -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./parsermodule.c
cc  -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./cStringIO.c
cc  -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./cPickle.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c config.c
cc -c -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -DPYTHONPATH='":plat-osf1V4:lib-tk"'  -DPREFIX='"/usr/local"'  -DEXEC_PREFIX='"/usr/local"'  -DVERSION='"2.0"'  -DVPATH='""'  ./getpath.c
cc: Warning: /usr/include/unistd.h, line 243: The redefinition of the macro "_POSIX_THREADS" conflicts with a current definition because the replacement lists differ.  The redefinition is now in effect.
#define	_POSIX_THREADS		/* 1003.1c (pthreads) comformant */
-------------------------------------------------------------------^
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c main.c
cc: Warning: /usr/include/unistd.h, line 243: The redefinition of the macro "_POSIX_THREADS" conflicts with a current definition because the replacement lists differ.  The redefinition is now in effect.
#define	_POSIX_THREADS		/* 1003.1c (pthreads) comformant */
-------------------------------------------------------------------^
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c getbuildinfo.c
if test ! -f libpython2.0.a;  then for i in Parser Grammar Objects Python Modules; do rm -f $i/add2lib; done; true;  else true; fi
for i in Parser Grammar Objects Python Modules; do  (cd $i; make VERSION="2.0" add2lib); done
ar cr ../libpython2.0.a acceler.o grammar1.o  listnode.o node.o parser.o  parsetok.o tokenizer.o bitset.o  metagrammar.o myreadline.o
if test ! -f ../Modules/hassignal;  then echo adding intrcheck.o; ar r ../libpython2.0.a intrcheck.o;  else echo leaving intrcheck.o out; fi
leaving intrcheck.o out
touch add2lib
ar cr ../libpython2.0.a abstract.o bufferobject.o  classobject.o cobject.o complexobject.o  fileobject.o floatobject.o  frameobject.o funcobject.o intobject.o listobject.o  longobject.o dictobject.o methodobject.o  moduleobject.o object.o rangeobject.o  sliceobject.o stringobject.o  tupleobject.o typeobject.o  unicodeobject.o unicodectype.o
touch add2lib
ar cr ../libpython2.0.a bltinmodule.o exceptions.o  ceval.o compile.o codecs.o  errors.o  frozen.o frozenmain.o  getargs.o getcompiler.o getcopyright.o getmtime.o  getplatform.o getversion.o graminit.o  import.o importdl.o  marshal.o modsupport.o mystrtoul.o  pyfpe.o pystate.o pythonrun.o  structmember.o sysmodule.o  traceback.o  dynload_shlib.o  thread.o
if test ! -f ../Modules/hassignal;  then echo adding sigcheck.o; ar r ../libpython2.0.a sigcheck.o;  else echo leaving sigcheck.o out; fi
leaving sigcheck.o out
touch add2lib
if test -f hassignal;  then echo removing sigcheck.o intrcheck.o;  ar d ../libpython2.0.a sigcheck.o intrcheck.o 2>/dev/null;  else echo leaving sigcheck.o intrcheck.o in; fi
removing sigcheck.o intrcheck.o
*** Exit 2 (ignored)
ar cr ../libpython2.0.a threadmodule.o  gcmodule.o  bsddbmodule.o  regexmodule.o regexpr.o  pcremodule.o pypcre.o  posixmodule.o  signalmodule.o  _sre.o  arraymodule.o  cmathmodule.o  mathmodule.o  stropmodule.o  structmodule.o  timemodule.o  operator.o  _codecsmodule.o  unicodedata.o unicodedatabase.o  ucnhash.o  _localemodule.o  fcntlmodule.o  pwdmodule.o  grpmodule.o  errnomodule.o  selectmodule.o  socketmodule.o  mmapmodule.o  md5module.o md5c.o  shamodule.o  rotormodule.o  newmodule.o  binascii.o  parsermodule.o  cStringIO.o  cPickle.o config.o getpath.o main.o getbuildinfo.o
touch add2lib
echo 0 >buildno
cd Modules; make OPT="-O -Olimit 1500" python.o
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c python.c
expr `cat buildno` + 1 >buildno1
mv -f buildno1 buildno
cc -c -O -Olimit 1500 -I. -DHAVE_CONFIG_H -DBUILD=`cat buildno`  ./Modules/getbuildinfo.c
ar cr libpython2.0.a getbuildinfo.o
ranlib libpython2.0.a
true
cd Modules;  make OPT="-O -Olimit 1500" VERSION="2.0"  prefix="/usr/local" exec_prefix="/usr/local"  LIBRARY=../libpython2.0.a link
 cc   python.o  ../libpython2.0.a -ldb                                 -lpthreads -lm  -o python 
ld:
Unresolved:
__pthread_mutex_init
__pthread_mutex_destroy
__pthread_mutex_lock
__pthread_mutex_unlock
__pthread_cond_init
__pthread_cond_destroy
__pthread_cond_signal
__pthread_cond_wait
__pthread_create
__pthread_detach
*** Exit 1
Stop.
*** Exit 1
Stop.


DEC C V5.6-079 on Digital UNIX V4.0 (Rev. 878)
/usr/lib/cmplrs/cc/ld:
	$RCSfile: crt0.s,v $ $Revision: 1.1.21.11 $ (DEC) $Date: 1995/09/06 19:54:27 $
	$RCSfile: ld.c,v $ $Revision: 4.3.123.2 $ (DEC) $Date: 1998/10/06 19:53:55 $
	$RCSfile: doup.c,v $ $Revision: 1.1.3.2 $ (DEC) $Date: 1994/10/20 14:19:31 $
	$RCSfile: pass1.c,v $ $Revision: 4.3.59.5 $ (DEC) $Date: 1997/06/27 15:58:18 $
	$RCSfile: obj_file.c,v $ $Revision: 4.2.38.3 $ (DEC) $Date: 1997/05/06 13:00:05 $
	$RCSfile: file_tbl.c,v $ $Revision: 4.2.38.2 $ (DEC) $Date: 1996/07/08 14:08:20 $
	$RCSfile: fdmap.c,v $ $Revision: 4.2.18.2 $ (DEC) $Date: 1996/07/08 14:08:13 $
	$RCSfile: ext_tbl.c,v $ $Revision: 4.2.80.3 $ (DEC) $Date: 1997/03/17 15:01:44 $
	$RCSfile: extmap.c,v $ $Revision: 4.2.28.2 $ (DEC) $Date: 1996/07/08 14:08:07 $
	$RCSfile: read.c,v $ $Revision: 4.2.64.4 $ (DEC) $Date: 1997/09/30 18:52:59 $
	$RCSfile: read_malloc.c,v $ $Revision: 1.1.44.4 $ (DEC) $Date: 1997/09/30 18:53:01 $
	$RCSfile: layout.c,v $ $Revision: 4.2.111.9 $ (DEC) $Date: 1997/09/12 17:35:22 $
	$RCSfile: relocsym.c,v $ $Revision: 4.2.20.2 $ (DEC) $Date: 1997/02/26 20:47:45 $
	$RCSfile: write.c,v $ $Revision: 4.3.51.3 $ (DEC) $Date: 1996/09/18 17:56:40 $
	$RCSfile: pass2.c,v $ $Revision: 4.3.90.3 $ (DEC) $Date: 1997/03/17 15:03:09 $
	$RCSfile: extlink.c,v $ $Revision: 4.2.7.3 $ (DEC) $Date: 1994/08/05 17:55:56 $
	$RCSfile: tracesym.c,v $ $Revision: 4.2.7.3 $ (DEC) $Date: 1994/08/05 17:59:20 $
	$RCSfile: dn_tbl.c,v $ $Revision: 4.2.7.3 $ (DEC) $Date: 1994/08/05 17:54:50 $
	$RCSfile: dnmap.c,v $ $Revision: 4.2.6.3 $ (DEC) $Date: 1994/09/02 16:10:47 $
	$RCSfile: dynutil.c,v $ $Revision: 4.2.97.2 $ (DEC) $Date: 1998/10/06 19:53:44 $
	$RCSfile: mipscoff.c,v $ $Revision: 4.3.62.3 $ (DEC) $Date: 1997/03/17 15:02:52 $
	$RCSfile: dsoindirect.c,v $ $Revision: 4.2.15.2 $ (DEC) $Date: 1995/02/08 15:21:38 $
	$RCSfile: dsosymbol_table.c,v $ $Revision: 4.3.29.2 $ (DEC) $Date: 1995/10/26 17:16:39 $
	$RCSfile: dsomisc.c,v $ $Revision: 4.2.6.2 $ (DEC) $Date: 1994/08/05 17:55:23 $
	$RCSfile: dsomain.c,v $ $Revision: 4.2.16.3 $ (DEC) $Date: 1994/09/02 16:10:46 $
	$RCSfile: literal.c,v $ $Revision: 4.2.19.2 $ (DEC) $Date: 1995/08/31 18:10:41 $
	$RCSfile: elfhash.c,v $ $Revision: 4.1.25.2 $ (DEC) $Date: 1996/07/08 14:07:40 $
	$RCSfile: register.c,v $ $Revision: 4.2.22.5 $ (DEC) $Date: 1995/05/23 18:46:26 $
	$RCSfile: elf.c,v $ $Revision: 4.3.51.4 $ (DEC) $Date: 1997/05/06 13:00:03 $
	$RCSfile: uldgnum.c,v $ $Revision: 1.1.13.2 $ (DEC) $Date: 1994/10/20 16:22:50 $
	$RCSfile: op.c,v $ $Revision: 1.1.10.2 $ (DEC) $Date: 1994/08/05 17:57:05 $
	$RCSfile: dsoalphainst.c,v $ $Revision: 1.1.13.2 $ (DEC) $Date: 1996/02/02 21:50:45 $
	$RCSfile: alphaop_utils.c,v $ $Revision: 1.1.6.2 $ (DEC) $Date: 1994/08/05 17:54:48 $
	$RCSfile: smap.c,v $ $Revision: 1.1.4.2 $ (DEC) $Date: 1994/08/05 17:59:15 $
	$RCSfile: match.c,v $ $Revision: 4.2.29.3 $ (DEC) $Date: 1997/09/23 18:58:00 $
	$RCSfile: relocate.c,v $ $Revision: 1.1.82.6 $ (DEC) $Date: 1997/09/23 18:58:07 $
	$RCSfile: mgot.c,v $ $Revision: 1.1.46.2 $ (DEC) $Date: 1996/07/08 14:09:29 $
	$RCSfile: gprof.c,v $ $Revision: 1.1.21.2 $ (DEC) $Date: 1996/07/08 14:08:30 $
	$RCSfile: trampoline.c,v $ $Revision: 1.1.23.3 $ (DEC) $Date: 1997/06/20 18:46:07 $
	$RCSfile: gpinfo.c,v $ $Revision: 1.1.11.2 $ (DEC) $Date: 1996/07/08 14:08:23 $
	$RCSfile: stats.c,v $ $Revision: 1.1.8.2 $ (DEC) $Date: 1996/07/08 14:11:02 $
	$RCSfile: obj.c,v $ $Revision: 4.3.48.4 $ (DEC) $Date: 1997/05/29 19:26:42 $
	$RCSfile: wh1.c,v $ $Revision: 1.1.5.5 $ (DEC) $Date: 1995/11/03 18:57:55 $
	$RCSfile: cmrlc_produce.c,v $ $Revision: 1.1.17.3 $ (DEC) $Date: 1997/02/07 20:42:03 $
	$RCSfile: cmrlc_basic.c,v $ $Revision: 1.1.5.2 $ (DEC) $Date: 1995/02/15 16:45:57 $
	$RCSfile: decompresswh1.alpha.s,v $ $Revision: 1.1.2.3 $ (DEC) $Date: 1994/11/15 16:30:26 $
	$RCSfile: allocate.c,v $ $Revision: 1.1.3.3 $ (DEC) $Date: 1994/05/25 19:19:04 $
	$RCSfile: cmrlc_heur.c,v $ $Revision: 1.1.6.2 $ (DEC) $Date: 1995/09/07 17:18:18 $
	$RCSfile: ldgetname.c,v $ $Revision: 4.3.5.2 $ (DEC) $Date: 1994/05/26 18:09:48 $
	$RCSfile: scncomment.c,v $ $Revision: 4.1.12.2 $ (DEC) $Date: 1994/05/04 20:03:47 $
	$RCSfile: lderr.c,v $ $Revision: 1.1.2.2 $ (DEC) $Date: 1995/11/29 19:43:44 $
	$RCSfile: exit.c,v $ $Revision: 4.2.13.8 $ (DEC) $Date: 1996/04/22 20:54:54 $
	$RCSfile: signal.c,v $ $Revision: 4.3.9.2 $ (DEC) $Date: 1995/09/12 17:44:41 $
	$RCSfile: flsbuf.c,v $ $Revision: 4.2.15.2 $ (DEC) $Date: 1996/09/18 19:45:36 $
	$RCSfile: fopen.c,v $ $Revision: 4.2.11.3 $ (DEC) $Date: 1995/06/12 20:40:14 $
	$RCSfile: fprintf.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/04/04 21:28:13 $
	$RCSfile: scanf.c,v $ $Revision: 4.2.10.2 $ (DEC) $Date: 1994/04/05 15:45:13 $
	$RCSfile: printf.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/04/05 15:26:18 $
	$RCSfile: sprintf.c,v $ $Revision: 4.2.13.3 $ (DEC) $Date: 1995/12/14 23:46:41 $
	$RCSfile: fgets.c,v $ $Revision: 4.2.10.2 $ (DEC) $Date: 1994/11/23 20:11:27 $
	$RCSfile: NLSsetup.c,v $ $Revision: 1.1.13.7 $ (DEC) $Date: 1996/01/15 23:46:55 $
	$RCSfile: atoi.c,v $ $Revision: 4.2.10.2 $ (DEC) $Date: 1994/11/07 19:18:55 $
	$RCSfile: atol.c,v $ $Revision: 4.2.10.2 $ (DEC) $Date: 1994/11/07 19:19:01 $
	$RCSfile: malloc.c,v $ $Revision: 4.2.59.2 $ (DEC) $Date: 1998/04/09 14:55:23 $
	$RCSfile: system.c,v $ $Revision: 4.3.13.2 $ (DEC) $Date: 1994/08/03 14:34:15 $
	$RCSfile: strncmp.c,v $ $Revision: 4.2.11.4 $ (DEC) $Date: 1994/04/20 16:56:44 $
	$RCSfile: errlst.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/11/23 19:19:49 $
	$RCSfile: calloc.c,v $ $Revision: 4.2.8.3 $ (DEC) $Date: 1994/04/05 21:09:32 $
	$RCSfile: strncpy.c,v $ $Revision: 4.2.7.2 $ (DEC) $Date: 1994/04/05 15:48:58 $
	$RCSfile: abort.c,v $ $Revision: 4.2.11.3 $ (DEC) $Date: 1995/06/12 20:38:42 $
	$RCSfile: vfprintf.c,v $ $Revision: 4.2.7.2 $ (DEC) $Date: 1994/04/05 16:15:00 $
	$RCSfile: sysconf.c,v $ $Revision: 4.3.27.2 $ (DEC) $Date: 1996/12/03 21:50:05 $
	$RCSfile: qsort.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/11/23 19:23:30 $
	$RCSfile: filbuf.c,v $ $Revision: 4.2.13.3 $ (DEC) $Date: 1995/06/12 20:39:59 $
	$RCSfile: isspace.c,v $ $Revision: 4.2.8.3 $ (DEC) $Date: 1994/05/31 18:13:48 $
	$RCSfile: time.c,v $ $Revision: 4.2.7.2 $ (DEC) $Date: 1994/04/05 16:12:12 $
	$RCSfile: strncat.c,v $ $Revision: 4.2.10.2 $ (DEC) $Date: 1996/02/16 21:06:27 $
	$RCSfile: Ustrtok.c,v $ $Revision: 1.1.2.2 $ (DEC) $Date: 1994/11/23 19:18:34 $
	$RCSfile: strtok.c,v $ $Revision: 4.2.7.2 $ (DEC) $Date: 1994/04/05 15:49:33 $
	$RCSfile: strtol.c,v $ $Revision: 4.3.13.2 $ (DEC) $Date: 1994/08/03 14:33:56 $
	$RCSfile: fseek.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/04/04 21:28:42 $
	$RCSfile: ftell.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/04/04 21:28:58 $
	$RCSfile: strcspn.c,v $ $Revision: 4.2.7.2 $ (DEC) $Date: 1994/04/05 15:48:25 $
	$RCSfile: cfork.c,v $ $Revision: 1.1.3.7 $ (DEC) $Date: 1996/01/24 16:16:02 $
	$RCSfile: brks.c,v $ $Revision: 1.1.2.4 $ (DEC) $Date: 1995/08/30 19:21:18 $
	$RCSfile: nano_timers.c,v $ $Revision: 4.3.14.3 $ (DEC) $Date: 1995/06/12 20:42:02 $
	$RCSfile: assert.c,v $ $Revision: 4.2.9.3 $ (DEC) $Date: 1994/04/05 21:09:04 $
	$RCSfile: mktemp.c,v $ $Revision: 4.2.10.2 $ (DEC) $Date: 1995/08/29 17:56:51 $
	$RCSfile: fread.c,v $ $Revision: 4.3.12.3 $ (DEC) $Date: 1995/07/28 14:53:14 $
	$RCSfile: strdup.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/11/23 19:24:39 $
	$RCSfile: strcasecmp.c,v $ $Revision: 4.2.11.2 $ (DEC) $Date: 1994/11/10 14:57:27 $
	$RCSfile: a64l.c,v $ $Revision: 4.2.9.6 $ (DEC) $Date: 1995/06/28 16:00:16 $
	$RCSfile: sigops.c,v $ $Revision: 4.2.10.2 $ (DEC) $Date: 1994/04/05 15:47:12 $
	$RCSfile: tis.c,v $ $Revision: 1.1.14.5 $ (DEC) $Date: 1997/05/02 19:32:15 $
	$RCSfile: init_libc.c,v $ $Revision: 1.1.32.2 $ (DEC) $Date: 1998/08/06 21:11:39 $
	$RCSfile: ldr_atexit.c,v $ $Revision: 4.2.17.2 $ (DEC) $Date: 1998/03/23 20:01:58 $
	$RCSfile: write_nc.c,v $ $Revision: 1.1.7.2 $ (DEC) $Date: 1997/09/23 14:15:37 $
	$RCSfile: close_nc.c,v $ $Revision: 1.1.7.2 $ (DEC) $Date: 1997/09/23 14:15:32 $
	$RCSfile: isatty.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/04/04 21:44:10 $
	$RCSfile: tis_pthread.c,v $ $Revision: 1.1.5.3 $ (DEC) $Date: 1996/12/18 20:37:50 $
	$RCSfile: open_nc.c,v $ $Revision: 1.1.7.2 $ (DEC) $Date: 1997/09/23 14:15:33 $
	$RCSfile: findiop.c,v $ $Revision: 4.2.12.4 $ (DEC) $Date: 1995/06/12 20:40:02 $
	$RCSfile: doprnt.c,v $ $Revision: 4.2.58.2 $ (DEC) $Date: 1998/07/29 16:22:47 $
	$RCSfile: doscan.c,v $ $Revision: 4.3.40.2 $ (DEC) $Date: 1998/06/15 20:58:58 $
	$RCSfile: ecvt.c,v $ $Revision: 4.2.19.2 $ (DEC) $Date: 1996/04/17 17:50:54 $
	$RCSfile: errno.c,v $ $Revision: 1.1.8.4 $ (DEC) $Date: 1994/04/05 22:09:26 $
	$RCSfile: mallocdata.c,v $ $Revision: 1.1.4.4 $ (DEC) $Date: 1996/02/08 19:08:30 $
	$RCSfile: waitpid.c,v $ $Revision: 4.2.9.3 $ (DEC) $Date: 1995/10/30 21:48:36 $
	$RCSfile: raise.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1995/10/27 19:40:45 $
	$RCSfile: siglist.c,v $ $Revision: 4.2.9.3 $ (DEC) $Date: 1995/02/08 22:02:42 $
	$RCSfile: read_nc.c,v $ $Revision: 1.1.7.2 $ (DEC) $Date: 1997/09/23 14:15:35 $
	$RCSfile: iswctype.c,v $ $Revision: 1.1.12.2 $ (DEC) $Date: 1994/11/23 19:21:20 $
	$RCSfile: strspn.c,v $ $Revision: 4.2.7.2 $ (DEC) $Date: 1994/04/05 15:49:15 $
	$RCSfile: strpbrk.c,v $ $Revision: 4.2.7.2 $ (DEC) $Date: 1994/04/05 15:49:04 $
	$RCSfile: atfork.c,v $ $Revision: 1.1.2.4 $ (DEC) $Date: 1995/08/25 20:52:45 $
	$RCSfile: catopen.c,v $ $Revision: 4.3.18.5 $ (DEC) $Date: 1995/09/25 21:03:54 $
	$RCSfile: catgets.c,v $ $Revision: 4.2.10.3 $ (DEC) $Date: 1994/04/05 21:09:37 $
	$RCSfile: rec_mutex.c,v $ $Revision: 1.1.8.2 $ (DEC) $Date: 1997/06/24 19:15:05 $
	$RCSfile: sleep.c,v $ $Revision: 4.2.9.5 $ (DEC) $Date: 1995/10/31 15:54:41 $
	$RCSfile: schyield.s,v $ $Revision: 1.1.2.2 $ (DEC) $Date: 1995/09/27 17:08:25 $
	$RCSfile: tis_rwlock.c,v $ $Revision: 1.1.5.2 $ (DEC) $Date: 1996/12/03 20:38:25 $
	$RCSfile: ldr_dummy.c,v $ $Revision: 4.2.15.2 $ (DEC) $Date: 1997/10/13 21:06:11 $
	$RCSfile: ldr_status.c,v $ $Revision: 4.2.8.3 $ (DEC) $Date: 1994/04/05 15:05:50 $
	$RCSfile: sched_yield.c,v $ $Revision: 1.1.2.2 $ (DEC) $Date: 1995/11/16 21:59:12 $
	$RCSfile: Ufwrite.c,v $ $Revision: 1.1.2.2 $ (DEC) $Date: 1994/11/23 20:11:24 $
	$RCSfile: fwrite.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/11/23 20:11:38 $
	$RCSfile: __getmbcurmax.c,v $ $Revision: 1.1.7.2 $ (DEC) $Date: 1994/04/05 16:51:10 $
	$RCSfile: wcstombs.c,v $ $Revision: 4.2.7.3 $ (DEC) $Date: 1994/05/31 18:15:14 $
	$RCSfile: wctomb.c,v $ $Revision: 4.2.11.2 $ (DEC) $Date: 1997/07/15 17:35:42 $
	$RCSfile: localeconv.c,v $ $Revision: 4.2.7.3 $ (DEC) $Date: 1994/05/31 18:14:20 $
	$RCSfile: wcslen.c,v $ $Revision: 4.2.9.3 $ (DEC) $Date: 1995/03/09 18:40:34 $
	$RCSfile: mblen.c,v $ $Revision: 4.2.7.3 $ (DEC) $Date: 1994/05/31 18:14:22 $
	$RCSfile: mbtowc.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1995/02/09 15:37:35 $
	$RCSfile: strtod.c,v $ $Revision: 4.2.15.3 $ (DEC) $Date: 1994/08/16 20:01:29 $
	$RCSfile: strtoul.c,v $ $Revision: 4.2.12.2 $ (DEC) $Date: 1994/08/03 14:34:11 $
	$RCSfile: strstr.c,v $ $Revision: 4.2.7.2 $ (DEC) $Date: 1994/04/05 15:49:20 $
	$RCSfile: ungetwc.c,v $ $Revision: 4.2.12.3 $ (DEC) $Date: 1995/05/04 20:48:07 $
	$RCSfile: setlocale.c,v $ $Revision: 4.4.18.4 $ (DEC) $Date: 1995/04/27 20:15:29 $
	$RCSfile: getenv.c,v $ $Revision: 4.2.11.4 $ (DEC) $Date: 1995/06/12 20:40:24 $
	$RCSfile: basename.c,v $ $Revision: 4.2.12.2 $ (DEC) $Date: 1996/09/16 19:39:28 $
	$RCSfile: __ispriv.c,v $ $Revision: 1.1.9.2 $ (DEC) $Date: 1995/09/25 21:03:53 $
	$RCSfile: bsearch.c,v $ $Revision: 4.2.6.3 $ (DEC) $Date: 1994/04/05 21:09:30 $
	$RCSfile: __mbtopc.c,v $ $Revision: 1.1.7.4 $ (DEC) $Date: 1994/05/31 18:12:22 $
	$RCSfile: __lc_load.c,v $ $Revision: 1.1.9.2 $ (DEC) $Date: 1994/11/10 14:56:05 $
	$RCSfile: __lc_dlopen.c,v $ $Revision: 1.1.2.6 $ (DEC) $Date: 1995/06/12 20:38:38 $
	$RCSfile: __lc_dlsym.c,v $ $Revision: 1.1.2.5 $ (DEC) $Date: 1995/06/12 20:38:40 $
	$RCSfile: setjmp_incl.s,v $ $Revision: 1.1.4.5 $ (DEC) $Date: 1994/05/13 18:07:02 $
	$RCSfile: alpha_unwind.c,v $ $Revision: 1.1.19.6 $ (DEC) $Date: 1997/08/04 17:50:22 $
	$RCSfile: ldr_load.c,v $ $Revision: 1.1.3.5 $ (DEC) $Date: 1995/04/28 14:20:17 $
	$RCSfile: tzset.c,v $ $Revision: 1.1.24.2 $ (DEC) $Date: 1997/08/04 17:11:53 $
	$RCSfile: perror.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/04/05 15:25:26 $
	$RCSfile: fputs.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/11/23 20:11:33 $
	 habitat_id = realtime_12:1991
	$RCSfile: allocator.c,v $ $Revision: 1.1.2.2 $ (DEC) $Date: 1992/12/03 19:08:59 $
	$RCSfile: nmach_user.c,v $ $Revision: 4.2.2.2 $ (DEC) $Date: 1993/01/15 18:03:56 $
	$RCSfile: mach_error.c,v $ $Revision: 4.2 $ (DEC) $Date: 1991/09/20 04:10:59 $
	$RCSfile: msg.c,v $ $Revision: 4.2.2.2 $ (DEC) $Date: 93/03/02 16:10:03 $
	$RCSfile: mig_support.c,v $ $Revision: 4.2 $ (DEC) $Date: 1991/09/20 04:11:14 $
	$RCSfile: mach_init.c,v $ $Revision: 4.2.6.2 $ (DEC) $Date: 1995/07/11 20:50:08 $
/usr/lib/cmplrs/cc/ftoc:
	$RCSfile: crt0.s,v $ $Revision: 1.1.21.11 $ (DEC) $Date: 1995/09/06 19:54:27 $
	$RCSfile: exit.c,v $ $Revision: 4.2.13.8 $ (DEC) $Date: 1996/04/22 20:54:54 $
	$RCSfile: fread.c,v $ $Revision: 4.3.12.3 $ (DEC) $Date: 1995/07/28 14:53:14 $
	$RCSfile: flsbuf.c,v $ $Revision: 4.2.17.2 $ (DEC) $Date: 1996/10/07 18:02:48 $
	$RCSfile: fopen.c,v $ $Revision: 4.2.11.3 $ (DEC) $Date: 1995/06/12 20:40:14 $
	$RCSfile: fprintf.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/04/04 21:28:13 $
	$RCSfile: printf.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/04/05 15:26:18 $
	$RCSfile: perror.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/04/05 15:25:26 $
	$RCSfile: qsort.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/11/23 19:23:30 $
	$RCSfile: malloc.c,v $ $Revision: 4.2.47.3 $ (DEC) $Date: 1997/06/17 14:20:56 $
	$RCSfile: sigops.c,v $ $Revision: 4.2.10.2 $ (DEC) $Date: 1994/04/05 15:47:12 $
	$RCSfile: tis.c,v $ $Revision: 1.1.14.5 $ (DEC) $Date: 1997/05/02 19:32:15 $
	$RCSfile: init_libc.c,v $ $Revision: 1.1.21.3 $ (DEC) $Date: 1997/03/06 18:54:43 $
	$RCSfile: ldr_atexit.c,v $ $Revision: 4.2.11.4 $ (DEC) $Date: 1995/06/12 20:41:35 $
	$RCSfile: filbuf.c,v $ $Revision: 4.2.13.3 $ (DEC) $Date: 1995/06/12 20:39:59 $
	$RCSfile: tis_pthread.c,v $ $Revision: 1.1.5.3 $ (DEC) $Date: 1996/12/18 20:37:50 $
	$RCSfile: write_nc.c,v $ $Revision: 1.1.7.2 $ (DEC) $Date: 1997/09/23 14:15:37 $
	$RCSfile: close_nc.c,v $ $Revision: 1.1.7.2 $ (DEC) $Date: 1997/09/23 14:15:32 $
	$RCSfile: isatty.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/04/04 21:44:10 $
	$RCSfile: open_nc.c,v $ $Revision: 1.1.7.2 $ (DEC) $Date: 1997/09/23 14:15:33 $
	$RCSfile: findiop.c,v $ $Revision: 4.2.12.4 $ (DEC) $Date: 1995/06/12 20:40:02 $
	$RCSfile: doprnt.c,v $ $Revision: 4.2.43.3 $ (DEC) $Date: 1997/09/26 15:41:30 $
	$RCSfile: errlst.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/11/23 19:19:49 $
	$RCSfile: catopen.c,v $ $Revision: 4.3.18.5 $ (DEC) $Date: 1995/09/25 21:03:54 $
	$RCSfile: catgets.c,v $ $Revision: 4.2.10.3 $ (DEC) $Date: 1994/04/05 21:09:37 $
	$RCSfile: sprintf.c,v $ $Revision: 4.2.13.3 $ (DEC) $Date: 1995/12/14 23:46:41 $
	$RCSfile: abort.c,v $ $Revision: 4.2.11.3 $ (DEC) $Date: 1995/06/12 20:38:42 $
	$RCSfile: brks.c,v $ $Revision: 1.1.2.4 $ (DEC) $Date: 1995/08/30 19:21:18 $
	$RCSfile: mallocdata.c,v $ $Revision: 1.1.4.4 $ (DEC) $Date: 1996/02/08 19:08:30 $
	$RCSfile: sleep.c,v $ $Revision: 4.2.9.5 $ (DEC) $Date: 1995/10/31 15:54:41 $
	$RCSfile: schyield.s,v $ $Revision: 1.1.2.2 $ (DEC) $Date: 1995/09/27 17:08:25 $
	$RCSfile: calloc.c,v $ $Revision: 4.2.8.3 $ (DEC) $Date: 1994/04/05 21:09:32 $
	$RCSfile: tis_rwlock.c,v $ $Revision: 1.1.5.2 $ (DEC) $Date: 1996/12/03 20:38:25 $
	$RCSfile: ldr_dummy.c,v $ $Revision: 4.2.15.2 $ (DEC) $Date: 1997/10/13 21:06:11 $
	$RCSfile: ldr_status.c,v $ $Revision: 4.2.8.3 $ (DEC) $Date: 1994/04/05 15:05:50 $
	$RCSfile: read_nc.c,v $ $Revision: 1.1.7.2 $ (DEC) $Date: 1997/09/23 14:15:35 $
	$RCSfile: Ufwrite.c,v $ $Revision: 1.1.2.2 $ (DEC) $Date: 1994/11/23 20:11:24 $
	$RCSfile: fwrite.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/11/23 20:11:38 $
	$RCSfile: __getmbcurmax.c,v $ $Revision: 1.1.7.2 $ (DEC) $Date: 1994/04/05 16:51:10 $
	$RCSfile: wcstombs.c,v $ $Revision: 4.2.7.3 $ (DEC) $Date: 1994/05/31 18:15:14 $
	$RCSfile: wctomb.c,v $ $Revision: 4.2.11.2 $ (DEC) $Date: 1997/07/15 17:35:42 $
	$RCSfile: ecvt.c,v $ $Revision: 4.2.21.2 $ (DEC) $Date: 1996/06/28 16:44:57 $
	$RCSfile: localeconv.c,v $ $Revision: 4.2.7.3 $ (DEC) $Date: 1994/05/31 18:14:20 $
	$RCSfile: NLSsetup.c,v $ $Revision: 1.1.13.7 $ (DEC) $Date: 1996/01/15 23:46:55 $
	$RCSfile: wcslen.c,v $ $Revision: 4.2.9.3 $ (DEC) $Date: 1995/03/09 18:40:34 $
	$RCSfile: setlocale.c,v $ $Revision: 4.4.18.4 $ (DEC) $Date: 1995/04/27 20:15:29 $
	$RCSfile: getenv.c,v $ $Revision: 4.2.11.4 $ (DEC) $Date: 1995/06/12 20:40:24 $
	$RCSfile: errno.c,v $ $Revision: 1.1.8.4 $ (DEC) $Date: 1994/04/05 22:09:26 $
	$RCSfile: strdup.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/11/23 19:24:39 $
	$RCSfile: basename.c,v $ $Revision: 4.2.12.2 $ (DEC) $Date: 1996/09/16 19:39:28 $
	$RCSfile: __ispriv.c,v $ $Revision: 1.1.9.2 $ (DEC) $Date: 1995/09/25 21:03:53 $
	$RCSfile: bsearch.c,v $ $Revision: 4.2.6.3 $ (DEC) $Date: 1994/04/05 21:09:30 $
	$RCSfile: raise.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1995/10/27 19:40:45 $
	$RCSfile: time.c,v $ $Revision: 4.2.7.2 $ (DEC) $Date: 1994/04/05 16:12:12 $
	$RCSfile: strncpy.c,v $ $Revision: 4.2.7.2 $ (DEC) $Date: 1994/04/05 15:48:58 $
	$RCSfile: strncat.c,v $ $Revision: 4.2.10.2 $ (DEC) $Date: 1996/02/16 21:06:27 $
	$RCSfile: __lc_load.c,v $ $Revision: 1.1.9.2 $ (DEC) $Date: 1994/11/10 14:56:05 $
	$RCSfile: __lc_dlopen.c,v $ $Revision: 1.1.2.6 $ (DEC) $Date: 1995/06/12 20:38:38 $
	$RCSfile: __lc_dlsym.c,v $ $Revision: 1.1.2.5 $ (DEC) $Date: 1995/06/12 20:38:40 $
	$RCSfile: ldr_load.c,v $ $Revision: 1.1.3.5 $ (DEC) $Date: 1995/04/28 14:20:17 $
	$RCSfile: tzset.c,v $ $Revision: 1.1.24.2 $ (DEC) $Date: 1997/08/04 17:11:53 $
	$RCSfile: assert.c,v $ $Revision: 4.2.9.3 $ (DEC) $Date: 1994/04/05 21:09:04 $
/usr/lib/cmplrs/cc/cord:
	$RCSfile: crt0.s,v $ $Revision: 1.1.21.11 $ (DEC) $Date: 1995/09/06 19:54:27 $
	$RCSfile: ldgetpd.c,v $ $Revision: 4.3.6.2 $ (DEC) $Date: 1995/01/25 20:38:36 $
	$RCSfile: cmrlc_produce.c,v $ $Revision: 1.1.17.3 $ (DEC) $Date: 1997/02/07 20:42:03 $
	$RCSfile: cmrlc_basic.c,v $ $Revision: 1.1.5.2 $ (DEC) $Date: 1995/02/15 16:45:57 $
	$RCSfile: cmrlc_consume.c,v $ $Revision: 1.1.11.2 $ (DEC) $Date: 1995/06/21 19:46:04 $
	$RCSfile: lderr.c,v $ $Revision: 1.1.2.2 $ (DEC) $Date: 1995/11/29 19:43:44 $
	$RCSfile: obj.c,v $ $Revision: 4.3.48.4 $ (DEC) $Date: 1997/05/29 19:26:42 $
	$RCSfile: allocate.c,v $ $Revision: 1.1.3.3 $ (DEC) $Date: 1994/05/25 19:19:04 $
	$RCSfile: ldgetname.c,v $ $Revision: 4.3.5.2 $ (DEC) $Date: 1994/05/26 18:09:48 $
	$RCSfile: cmrlc_heur.c,v $ $Revision: 1.1.6.2 $ (DEC) $Date: 1995/09/07 17:18:18 $
	$RCSfile: scncomment.c,v $ $Revision: 4.1.12.2 $ (DEC) $Date: 1994/05/04 20:03:47 $
	$RCSfile: wh1.c,v $ $Revision: 1.1.5.5 $ (DEC) $Date: 1995/11/03 18:57:55 $
	$RCSfile: decompresswh1.alpha.s,v $ $Revision: 1.1.2.3 $ (DEC) $Date: 1994/11/15 16:30:26 $
	$RCSfile: exit.c,v $ $Revision: 4.2.13.8 $ (DEC) $Date: 1996/04/22 20:54:54 $
	$RCSfile: assert.c,v $ $Revision: 4.2.9.3 $ (DEC) $Date: 1994/04/05 21:09:04 $
	$RCSfile: strncmp.c,v $ $Revision: 4.2.11.4 $ (DEC) $Date: 1994/04/20 16:56:44 $
	$RCSfile: strdup.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/11/23 19:24:39 $
	$RCSfile: fread.c,v $ $Revision: 4.3.12.3 $ (DEC) $Date: 1995/07/28 14:53:14 $
	$RCSfile: fwrite.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/11/23 20:11:38 $
	$RCSfile: flsbuf.c,v $ $Revision: 4.2.17.2 $ (DEC) $Date: 1996/10/07 18:02:48 $
	$RCSfile: fopen.c,v $ $Revision: 4.2.11.3 $ (DEC) $Date: 1995/06/12 20:40:14 $
	$RCSfile: fprintf.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/04/04 21:28:13 $
	$RCSfile: printf.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/04/05 15:26:18 $
	$RCSfile: sprintf.c,v $ $Revision: 4.2.13.3 $ (DEC) $Date: 1995/12/14 23:46:41 $
	$RCSfile: vfprintf.c,v $ $Revision: 4.2.7.2 $ (DEC) $Date: 1994/04/05 16:15:00 $
	$RCSfile: fgets.c,v $ $Revision: 4.2.10.2 $ (DEC) $Date: 1994/11/23 20:11:27 $
	$RCSfile: fseek.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/04/04 21:28:42 $
	$RCSfile: ftell.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/04/04 21:28:58 $
	$RCSfile: fdopen.c,v $ $Revision: 4.2.9.3 $ (DEC) $Date: 1994/04/05 22:09:55 $
	$RCSfile: atoi.c,v $ $Revision: 4.2.10.2 $ (DEC) $Date: 1994/11/07 19:18:55 $
	$RCSfile: malloc.c,v $ $Revision: 4.2.47.3 $ (DEC) $Date: 1997/06/17 14:20:56 $
	$RCSfile: calloc.c,v $ $Revision: 4.2.8.3 $ (DEC) $Date: 1994/04/05 21:09:32 $
	$RCSfile: qsort.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/11/23 19:23:30 $
	$RCSfile: abort.c,v $ $Revision: 4.2.11.3 $ (DEC) $Date: 1995/06/12 20:38:42 $
	$RCSfile: time.c,v $ $Revision: 4.2.7.2 $ (DEC) $Date: 1994/04/05 16:12:12 $
	$RCSfile: atol.c,v $ $Revision: 4.2.10.2 $ (DEC) $Date: 1994/11/07 19:19:01 $
	$RCSfile: strcspn.c,v $ $Revision: 4.2.7.2 $ (DEC) $Date: 1994/04/05 15:48:25 $
	$RCSfile: strncpy.c,v $ $Revision: 4.2.7.2 $ (DEC) $Date: 1994/04/05 15:48:58 $
	$RCSfile: a64l.c,v $ $Revision: 4.2.9.6 $ (DEC) $Date: 1995/06/28 16:00:16 $
	$RCSfile: signal.c,v $ $Revision: 4.3.9.2 $ (DEC) $Date: 1995/09/12 17:44:41 $
	$RCSfile: mktemp.c,v $ $Revision: 4.2.10.2 $ (DEC) $Date: 1995/08/29 17:56:51 $
	$RCSfile: brks.c,v $ $Revision: 1.1.2.4 $ (DEC) $Date: 1995/08/30 19:21:18 $
	$RCSfile: NLSsetup.c,v $ $Revision: 1.1.13.7 $ (DEC) $Date: 1996/01/15 23:46:55 $
	$RCSfile: strcasecmp.c,v $ $Revision: 4.2.11.2 $ (DEC) $Date: 1994/11/10 14:57:27 $
	$RCSfile: sigops.c,v $ $Revision: 4.2.10.2 $ (DEC) $Date: 1994/04/05 15:47:12 $
	$RCSfile: tis.c,v $ $Revision: 1.1.14.5 $ (DEC) $Date: 1997/05/02 19:32:15 $
	$RCSfile: init_libc.c,v $ $Revision: 1.1.21.3 $ (DEC) $Date: 1997/03/06 18:54:43 $
	$RCSfile: ldr_atexit.c,v $ $Revision: 4.2.11.4 $ (DEC) $Date: 1995/06/12 20:41:35 $
	$RCSfile: catopen.c,v $ $Revision: 4.3.18.5 $ (DEC) $Date: 1995/09/25 21:03:54 $
	$RCSfile: catgets.c,v $ $Revision: 4.2.10.3 $ (DEC) $Date: 1994/04/05 21:09:37 $
	$RCSfile: write_nc.c,v $ $Revision: 1.1.7.2 $ (DEC) $Date: 1997/09/23 14:15:37 $
	$RCSfile: filbuf.c,v $ $Revision: 4.2.13.3 $ (DEC) $Date: 1995/06/12 20:39:59 $
	$RCSfile: tis_pthread.c,v $ $Revision: 1.1.5.3 $ (DEC) $Date: 1996/12/18 20:37:50 $
	$RCSfile: close_nc.c,v $ $Revision: 1.1.7.2 $ (DEC) $Date: 1997/09/23 14:15:32 $
	$RCSfile: isatty.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/04/04 21:44:10 $
	$RCSfile: open_nc.c,v $ $Revision: 1.1.7.2 $ (DEC) $Date: 1997/09/23 14:15:33 $
	$RCSfile: findiop.c,v $ $Revision: 4.2.12.4 $ (DEC) $Date: 1995/06/12 20:40:02 $
	$RCSfile: doprnt.c,v $ $Revision: 4.2.43.3 $ (DEC) $Date: 1997/09/26 15:41:30 $
	$RCSfile: ecvt.c,v $ $Revision: 4.2.21.2 $ (DEC) $Date: 1996/06/28 16:44:57 $
	$RCSfile: errno.c,v $ $Revision: 1.1.8.4 $ (DEC) $Date: 1994/04/05 22:09:26 $
	$RCSfile: fcntl_nc.c,v $ $Revision: 1.1.2.2 $ (DEC) $Date: 1995/10/30 21:48:23 $
	$RCSfile: mallocdata.c,v $ $Revision: 1.1.4.4 $ (DEC) $Date: 1996/02/08 19:08:30 $
	$RCSfile: raise.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1995/10/27 19:40:45 $
	$RCSfile: rec_mutex.c,v $ $Revision: 1.1.8.2 $ (DEC) $Date: 1997/06/24 19:15:05 $
	$RCSfile: sleep.c,v $ $Revision: 4.2.9.5 $ (DEC) $Date: 1995/10/31 15:54:41 $
	$RCSfile: schyield.s,v $ $Revision: 1.1.2.2 $ (DEC) $Date: 1995/09/27 17:08:25 $
	$RCSfile: tis_rwlock.c,v $ $Revision: 1.1.5.2 $ (DEC) $Date: 1996/12/03 20:38:25 $
	$RCSfile: ldr_dummy.c,v $ $Revision: 4.2.15.2 $ (DEC) $Date: 1997/10/13 21:06:11 $
	$RCSfile: ldr_status.c,v $ $Revision: 4.2.8.3 $ (DEC) $Date: 1994/04/05 15:05:50 $
	$RCSfile: setlocale.c,v $ $Revision: 4.4.18.4 $ (DEC) $Date: 1995/04/27 20:15:29 $
	$RCSfile: getenv.c,v $ $Revision: 4.2.11.4 $ (DEC) $Date: 1995/06/12 20:40:24 $
	$RCSfile: basename.c,v $ $Revision: 4.2.12.2 $ (DEC) $Date: 1996/09/16 19:39:28 $
	$RCSfile: __ispriv.c,v $ $Revision: 1.1.9.2 $ (DEC) $Date: 1995/09/25 21:03:53 $
	$RCSfile: bsearch.c,v $ $Revision: 4.2.6.3 $ (DEC) $Date: 1994/04/05 21:09:30 $
	$RCSfile: read_nc.c,v $ $Revision: 1.1.7.2 $ (DEC) $Date: 1997/09/23 14:15:35 $
	$RCSfile: Ufwrite.c,v $ $Revision: 1.1.2.2 $ (DEC) $Date: 1994/11/23 20:11:24 $
	$RCSfile: fwrite.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/11/23 20:11:38 $
	$RCSfile: __getmbcurmax.c,v $ $Revision: 1.1.7.2 $ (DEC) $Date: 1994/04/05 16:51:10 $
	$RCSfile: wcstombs.c,v $ $Revision: 4.2.7.3 $ (DEC) $Date: 1994/05/31 18:15:14 $
	$RCSfile: wctomb.c,v $ $Revision: 4.2.11.2 $ (DEC) $Date: 1997/07/15 17:35:42 $
	$RCSfile: localeconv.c,v $ $Revision: 4.2.7.3 $ (DEC) $Date: 1994/05/31 18:14:20 $
	$RCSfile: wcslen.c,v $ $Revision: 4.2.9.3 $ (DEC) $Date: 1995/03/09 18:40:34 $
	$RCSfile: strncat.c,v $ $Revision: 4.2.10.2 $ (DEC) $Date: 1996/02/16 21:06:27 $
	$RCSfile: __lc_load.c,v $ $Revision: 1.1.9.2 $ (DEC) $Date: 1994/11/10 14:56:05 $
	$RCSfile: __lc_dlopen.c,v $ $Revision: 1.1.2.6 $ (DEC) $Date: 1995/06/12 20:38:38 $
	$RCSfile: __lc_dlsym.c,v $ $Revision: 1.1.2.5 $ (DEC) $Date: 1995/06/12 20:38:40 $
	$RCSfile: ldr_load.c,v $ $Revision: 1.1.3.5 $ (DEC) $Date: 1995/04/28 14:20:17 $
	$RCSfile: tzset.c,v $ $Revision: 1.1.24.2 $ (DEC) $Date: 1997/08/04 17:11:53 $
	 ldtbread.c: 1.1 1/7/82
/usr/lib/cmplrs/cc/crt0.o:
	$RCSfile: crt0.s,v $ $Revision: 1.1.21.11 $ (DEC) $Date: 1995/09/06 19:54:27 $
cc  (cc)
	Digital UNIX Compiler Driver 3.11



From mal@lemburg.com  Mon Oct 23 14:35:40 2000
From: mal@lemburg.com (M.-A. Lemburg)
Date: Mon, 23 Oct 2000 15:35:40 +0200
Subject: [Python-Dev] Starship down ?
Message-ID: <39F43EAC.1A518A27@lemburg.com>

Sorry for using this list, but the crew list sits on starship
as well...

The starship.python.net server seems to be down. Could someone
with sysadmin access please fix this ?!

Thanks,
-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/


From effbot@telia.com  Mon Oct 23 18:44:49 2000
From: effbot@telia.com (Fredrik Lundh)
Date: Mon, 23 Oct 2000 19:44:49 +0200
Subject: [Python-Dev] FYI: ajuba solutions (formerly scriptics) acquired by interwoven
Message-ID: <003201c03d18$f384a5c0$3c6340d5@hagrid>

looks like Tcl's parent company has ceased to be:

    http://biz.yahoo.com/bw/001020/ca_interwo.html

    "The Ajuba team will be assimilated into Interwoven's
    existing technical staff much as the Neonyoyo team
    was immediately after its acquisition in June. The Ajuba
    product line will be discontinued."

</F>



From guido@python.org  Mon Oct 23 21:12:49 2000
From: guido@python.org (Guido van Rossum)
Date: Mon, 23 Oct 2000 15:12:49 -0500
Subject: [Python-Dev] Starship down ?
In-Reply-To: Your message of "Mon, 23 Oct 2000 15:35:40 +0200."
 <39F43EAC.1A518A27@lemburg.com>
References: <39F43EAC.1A518A27@lemburg.com>
Message-ID: <200010232012.PAA12261@cj20424-a.reston1.va.home.com>

> The starship.python.net server seems to be down. Could someone
> with sysadmin access please fix this ?!

Yeah, this is very unfortunate.  It's the same problem that's keeping
pytholabs.com down.  The BeOpen systems staff is working on it, but I
don't know what the problem is or when it will be fixed.

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


From esr@thyrsus.com  Mon Oct 23 20:40:16 2000
From: esr@thyrsus.com (Eric S. Raymond)
Date: Mon, 23 Oct 2000 15:40:16 -0400
Subject: [Python-Dev] FYI: ajuba solutions (formerly scriptics) acquired by interwoven
In-Reply-To: <003201c03d18$f384a5c0$3c6340d5@hagrid>; from effbot@telia.com on Mon, Oct 23, 2000 at 07:44:49PM +0200
References: <003201c03d18$f384a5c0$3c6340d5@hagrid>
Message-ID: <20001023154016.A2722@thyrsus.com>

Fredrik Lundh <effbot@telia.com>:
> looks like Tcl's parent company has ceased to be:

This raises anew a question I've been meaning to bring up for the last
week: is it finally time to move away from Python's dependence on
Tcl/Tk for GUI support?

It seems to me that the Tcl world has been in increasing disarray for
the last two years.  Its growth doesn't seem to have matched Perl's or
Python's; no strong community site analogous to python.org or CPAN has
emerged; and John Osterhout's attempt to commercialize the language
have led to a series of false starts and erratic moves.  And Osterhout
cheerfully acknowledges that on a technical level that Tcl has been
pushed past the natural limits of applicability for its design
approach.  

Tcl's long-term prognosis looks, to me, increasingly poor.  Which suggests
to me that some move toqwards making Python less dependent on Tk would be
a good thing.

I understand that we can't simply drop Tkinter.  But I think it might be worth
another look at alternatives (notably wxPython) to consider bringing one
into the core distribution during 2.x, so that later on we can plan to
move Tk to "unsupported -- legacy".
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

You need only reflect that one of the best ways to get yourself 
a reputation as a dangerous citizen these days is to go about 
repeating the very phrases which our founding fathers used in the 
great struggle for independence.
	-- Attributed to Charles Austin Beard (1874-1948)


From guido@python.org  Mon Oct 23 22:08:13 2000
From: guido@python.org (Guido van Rossum)
Date: Mon, 23 Oct 2000 16:08:13 -0500
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: Your message of "Mon, 23 Oct 2000 15:40:16 -0400."
 <20001023154016.A2722@thyrsus.com>
References: <003201c03d18$f384a5c0$3c6340d5@hagrid>
 <20001023154016.A2722@thyrsus.com>
Message-ID: <200010232108.QAA12524@cj20424-a.reston1.va.home.com>

[ESR]
> This raises anew a question I've been meaning to bring up for the last
> week: is it finally time to move away from Python's dependence on
> Tcl/Tk for GUI support?
> 
> It seems to me that the Tcl world has been in increasing disarray for
> the last two years.  Its growth doesn't seem to have matched Perl's or
> Python's; no strong community site analogous to python.org or CPAN has
> emerged; and John Osterhout's attempt to commercialize the language
> have led to a series of false starts and erratic moves.  And Osterhout
> cheerfully acknowledges that on a technical level that Tcl has been
> pushed past the natural limits of applicability for its design
> approach.  
> 
> Tcl's long-term prognosis looks, to me, increasingly poor.  Which
> suggests to me that some move toqwards making Python less dependent
> on Tk would be a good thing.
> 
> I understand that we can't simply drop Tkinter.  But I think it
> might be worth another look at alternatives (notably wxPython) to
> consider bringing one into the core distribution during 2.x, so that
> later on we can plan to move Tk to "unsupported -- legacy".

Yes, it may be time to have this discussion again.

Of course, Tcl/Tk still has a much larger following than wxWindows,
and it is more stable too.  (For example, it's easy to cause crashes
-- not just exceptions -- by leaving out an initialization call in
wxPython.)

Plus, Tk has two very high quality widgets: the Canvas and Text
widgets are unsurpassed in functionality and robustness by other
widget sets.  You can draw more lines or characters per second in most
toolkits, but few toolkits offer the convenience of marks and tags,
not having to deal with refresh events, being able to group objects,
move them around, change attributes, etc., etc., etc.

The Scintilla text widget comes close (and surpasses Tkinter in some
respects, while coming short in others), but I know of no widget in a
popular widget set that offers anything close to the Canvas widget.

There are other choices too, all of which have Python support already:
gtk, qt, and the Mozilla toolkit (whose name I forget -- maybe David
Ascher can fill me in).

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


From akuchlin@mems-exchange.org  Mon Oct 23 21:21:18 2000
From: akuchlin@mems-exchange.org (Andrew Kuchling)
Date: Mon, 23 Oct 2000 16:21:18 -0400
Subject: [Python-Dev] FYI: ajuba solutions (formerly scriptics) acquired by interwoven
In-Reply-To: <20001023154016.A2722@thyrsus.com>; from esr@thyrsus.com on Mon, Oct 23, 2000 at 03:40:16PM -0400
References: <003201c03d18$f384a5c0$3c6340d5@hagrid> <20001023154016.A2722@thyrsus.com>
Message-ID: <20001023162118.B18005@kronos.cnri.reston.va.us>

Fredrik Lundh <effbot@telia.com> wrote:
> looks like Tcl's parent company has ceased to be:

I checked out comp.lang.tcl after hearing about this.  Ousterhout
posted to say that an official statement will be coming out today or
tomorrow, so I wouldn't conclude that Tcl is dead just yet; we'll see
what he says the core team is going to do...

On Mon, Oct 23, 2000 at 03:40:16PM -0400, Eric S. Raymond wrote:
>This raises anew a question I've been meaning to bring up for the last
>week: is it finally time to move away from Python's dependence on
>Tcl/Tk for GUI support?

It seems to me that supporting MacOS is the big problem for
cross-platform GUIs.  There are several different systems such as Qt
that aim for portability across Windows and Unix, but add in the MacOS
and the options really decrease.  How good is wxWindows support for
MacOS?

Or will MacOS X fix the problem?  I know MacOS X uses a BSD-based
underlying kernel, but don't know if it will support X Windows out of
the box.  If people can only use MacOS-specific GUI APIs, then
software such as Tk would still need to be ported specially to MacOS X.

--amk


From akuchlin@mems-exchange.org  Mon Oct 23 21:30:11 2000
From: akuchlin@mems-exchange.org (Andrew Kuchling)
Date: Mon, 23 Oct 2000 16:30:11 -0400
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: <200010232108.QAA12524@cj20424-a.reston1.va.home.com>; from guido@python.org on Mon, Oct 23, 2000 at 04:08:13PM -0500
References: <003201c03d18$f384a5c0$3c6340d5@hagrid> <20001023154016.A2722@thyrsus.com> <200010232108.QAA12524@cj20424-a.reston1.va.home.com>
Message-ID: <20001023163011.C18005@kronos.cnri.reston.va.us>

On Mon, Oct 23, 2000 at 04:08:13PM -0500, Guido van Rossum wrote:
>The Scintilla text widget comes close (and surpasses Tkinter in some
>respects, while coming short in others), but I know of no widget in a
>popular widget set that offers anything close to the Canvas widget.

I believe the GNOME (not GTk's, but GNOME's) canvas widget began as a
fork of the Tk widget that was then substantially enhanced to be a
general-purpose display engine, with antialiasing, alpha compositing,
more attention to performance, and other fancy features.  I don't know
if the corresponding text widget (which is Pango, www.pango.org, I
think) is equally featureful.

--amk


From gvwilson@nevex.com  Mon Oct 23 21:33:48 2000
From: gvwilson@nevex.com (Greg Wilson)
Date: Mon, 23 Oct 2000 16:33:48 -0400 (EDT)
Subject: [Python-Dev] Re: ajuba solutions (formerly scriptics) acquired by interwoven
In-Reply-To: <20001023154016.A2722@thyrsus.com>
Message-ID: <Pine.LNX.4.10.10010231624060.31805-100000@akbar.nevex.com>

> Fredrik Lundh <effbot@telia.com>:
> > looks like Tcl's parent company has ceased to be:

> Eric Raymond:
> This raises anew a question I've been meaning to bring up for the last week:
> is it finally time to move away from Python's dependence on Tcl/Tk for GUI
> support?

Yes please.

> It seems to me that the Tcl world has been in increasing disarray for the
> last two years.  Its growth doesn't seem to have matched Perl's or Python's;
> no strong community site analogous to python.org or CPAN has emerged;

I have been told by two different publishers that they can't even give Tcl books
away any longer.  It's also interesting that the new Ruby book from Hunt and
Thomas clearly positions Ruby as an alternative to Python, rather than Tcl or
Perl (I saw three mentions in the first ten minutes of the fact that Ruby is
more widely used in Japan than Python).  Also interesting that the Ruby GUI
toolkit they describe is Tk-based...

> I understand that we can't simply drop Tkinter.  But I think it might be
> worth another look at alternatives (notably wxPython) to consider bringing
> one into the core distribution during 2.x, so that later on we can plan to
> move Tk to "unsupported -- legacy".

I thought about using wxPython in the most recent run of my Python course, but
decided to stick to Tkinter because:

- There isn't a wxWindows/wxPython book (matters a lot when organizations are
  trying to decide what to adopt for long-term use).

- Tkinter came packaged with the 1.5.2 installer, wxPython didn't.

- There aren't as many tools on top of wxPython as there are on top of Tkinter.
  In particular, I think that a vector drawing package on top of wxPython that
  did what Sketch does, but on Windows as well as Linux, would make a great
  subject for a book on Python, non-trivial OO, and HCI (hint, hint...)

Thanks,
Greg



From effbot@telia.com  Mon Oct 23 22:02:58 2000
From: effbot@telia.com (Fredrik Lundh)
Date: Mon, 23 Oct 2000 23:02:58 +0200
Subject: [Python-Dev] FYI: ajuba solutions (formerly scriptics) acquired by interwoven
References: <003201c03d18$f384a5c0$3c6340d5@hagrid> <20001023154016.A2722@thyrsus.com> <20001023162118.B18005@kronos.cnri.reston.va.us>
Message-ID: <001e01c03d34$d11bd5f0$3c6340d5@hagrid>

andrew wrote:
> I checked out comp.lang.tcl after hearing about this.  Ousterhout
> posted to say that an official statement will be coming out today or
> tomorrow, so I wouldn't conclude that Tcl is dead just yet; we'll see
> what he says the core team is going to do...

from an open-source perspective, Tcl might be more alive
than ever:

http://sourceforge.net/projects/tcl
http://sourceforge.net/projects/tktoolkit

and trust me, the Python 2.0/Tk8.4/Tkinter3000 combo
will rock ;-)

</F>



From esr@thyrsus.com  Mon Oct 23 22:15:03 2000
From: esr@thyrsus.com (Eric S. Raymond)
Date: Mon, 23 Oct 2000 17:15:03 -0400
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: <200010232108.QAA12524@cj20424-a.reston1.va.home.com>; from guido@python.org on Mon, Oct 23, 2000 at 04:08:13PM -0500
References: <003201c03d18$f384a5c0$3c6340d5@hagrid> <20001023154016.A2722@thyrsus.com> <200010232108.QAA12524@cj20424-a.reston1.va.home.com>
Message-ID: <20001023171503.B2889@thyrsus.com>

Guido van Rossum <guido@python.org>:
> There are other choices too, all of which have Python support already:
> gtk, qt, and the Mozilla toolkit (whose name I forget -- maybe David
> Ascher can fill me in).

I'm glad you brought up GTK+.  Of all the alternatives you mentioned,
it seems to me the most likely to attract long-term cross-platform
support by lots of developers (GNOME, Nautilus and Sun Microsystems
seem like a tough trio to beat on this score).  Thus, GTK+ may be be
the safest alternative in terms of being least likely to strand us N
years down the road.

The GTK+ API seems like a nice clean design, and there is already a Python
binding.  Any comment from anybody on how stable it is?  Are the text and
canvas widgets anywhere near competitive with Tk's?  There are hints
of a wxWindows-based port to Windows on the GTK+ site; is there a Mac port?
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

.. a government and its agents are under no general duty to 
provide public services, such as police protection, to any 
particular individual citizen...
        -- Warren v. District of Columbia, 444 A.2d 1 (D.C. App.181)


From trentm@ActiveState.com  Mon Oct 23 22:06:41 2000
From: trentm@ActiveState.com (Trent Mick)
Date: Mon, 23 Oct 2000 14:06:41 -0700
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: <200010232108.QAA12524@cj20424-a.reston1.va.home.com>; from guido@python.org on Mon, Oct 23, 2000 at 04:08:13PM -0500
References: <003201c03d18$f384a5c0$3c6340d5@hagrid> <20001023154016.A2722@thyrsus.com> <200010232108.QAA12524@cj20424-a.reston1.va.home.com>
Message-ID: <20001023140641.A3899@ActiveState.com>

On Mon, Oct 23, 2000 at 04:08:13PM -0500, Guido van Rossum wrote:
> There are other choices too, all of which have Python support already:
...
> and the Mozilla toolkit (whose name I forget -- maybe David
> Ascher can fill me in).

XUL. Though slappin' a GUI together in XUL is not all the same as for
the other toolkits. Layout with XML, functionality with JavaScript and Python
(and/or Perl of C++).


Trent


-- 
Trent Mick
TrentM@ActiveState.com


From effbot@telia.com  Mon Oct 23 22:33:02 2000
From: effbot@telia.com (Fredrik Lundh)
Date: Mon, 23 Oct 2000 23:33:02 +0200
Subject: [Python-Dev] FYI: ajuba solutions (formerly scriptics) acquired by interwoven
References: <003201c03d18$f384a5c0$3c6340d5@hagrid> <20001023154016.A2722@thyrsus.com> <20001023162118.B18005@kronos.cnri.reston.va.us>
Message-ID: <004201c03d38$d4836e20$3c6340d5@hagrid>

andrew wrote:
> I checked out comp.lang.tcl after hearing about this.  Ousterhout
> posted to say that an official statement will be coming out today or
> tomorrow, so I wouldn't conclude that Tcl is dead just yet; we'll see
> what he says the core team is going to do...

they just updated their site:

http://www.ajubasolutions.com/company/whatsnew.html

    "Tcl is not a core technology at Interwoven, and
    Interwoven will not invest in the development of
    Tcl. However, Ajuba has transferred responsibility
    for Tcl core development to the newly formed Tcl
    Core Team /.../ We expect the Tcl Core Team to
    evolve Tcl at a much faster rate than any single
    organization could achieve by itself. 

    "Over the next few weeks Ajuba will release in open-
    source form many of the Tcl packages that we deve-
    loped for our products. Stay tuned for more info...

</F>



From akuchlin@mems-exchange.org  Mon Oct 23 22:26:18 2000
From: akuchlin@mems-exchange.org (Andrew Kuchling)
Date: Mon, 23 Oct 2000 17:26:18 -0400
Subject: [Python-Dev] Re: ajuba acquired by interwoven
In-Reply-To: <Pine.LNX.4.10.10010231624060.31805-100000@akbar.nevex.com>; from gvwilson@nevex.com on Mon, Oct 23, 2000 at 04:33:48PM -0400
References: <20001023154016.A2722@thyrsus.com> <Pine.LNX.4.10.10010231624060.31805-100000@akbar.nevex.com>
Message-ID: <20001023172618.A23898@kronos.cnri.reston.va.us>

Some details begin to emerge at 
http://www.ajubasolutions.com/company/whatsnew.html

It looks like some of their proprietary code will be released as open
source, possibly including the TclPro development environment.  The
new company will not be funding Tcl/Tk development, and instead it's
up to the 14 members of the recently-formed Tcl core team.  I don't
know if any of those people are being paid to work on Tcl, but
probably at least some of them are.  I expect this will cause a good
deal disruption, perhaps even a fatal amount, particularly if core
developers such as Jeffrey Hobbs no longer work on Tcl full-time.

--amk


From esr@thyrsus.com  Mon Oct 23 22:58:20 2000
From: esr@thyrsus.com (Eric S. Raymond)
Date: Mon, 23 Oct 2000 17:58:20 -0400
Subject: [Python-Dev] Re: ajuba acquired by interwoven
In-Reply-To: <20001023172618.A23898@kronos.cnri.reston.va.us>; from akuchlin@mems-exchange.org on Mon, Oct 23, 2000 at 05:26:18PM -0400
References: <20001023154016.A2722@thyrsus.com> <Pine.LNX.4.10.10010231624060.31805-100000@akbar.nevex.com> <20001023172618.A23898@kronos.cnri.reston.va.us>
Message-ID: <20001023175820.A3117@thyrsus.com>

Andrew Kuchling <akuchlin@mems-exchange.org>:
> Some details begin to emerge at 
> http://www.ajubasolutions.com/company/whatsnew.html
> 
> It looks like some of their proprietary code will be released as open
> source, possibly including the TclPro development environment.  The
> new company will not be funding Tcl/Tk development, and instead it's
> up to the 14 members of the recently-formed Tcl core team.  I don't
> know if any of those people are being paid to work on Tcl, but
> probably at least some of them are.  I expect this will cause a good
> deal disruption, perhaps even a fatal amount, particularly if core
> developers such as Jeffrey Hobbs no longer work on Tcl full-time.

Not necessarily...

Good for Tcl: they *have* a core team now

Bad for Tcl: at 14 it's too big, unless there's some inner core of no
	more than three or four architects.

Good for Tcl: Much of the proprietary code will go open.

Bad for Tcl: Not clear whether the two Ajuba employees "replaced" are
		on the new core team. Not clear whether their time 
		available will increase or decrease.

Good for Tcl: Osterhout's rather lame attempts to develop under a mixed 
		model have almost certainly come to an end in favor of
		an Apache-like model funded by big Tcl users.

With good leadership, they could manage the transition to something
resembling the Apache Software Foundation's organization.  If so, Tcl
might actually improve.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Rifles, muskets, long-bows and hand-grenades are inherently democratic
weapons.  A complex weapon makes the strong stronger, while a simple
weapon -- so long as there is no answer to it -- gives claws to the
weak.
        -- George Orwell, "You and the Atom Bomb", 1945


From robin@alldunn.com  Tue Oct 24 00:03:44 2000
From: robin@alldunn.com (Robin Dunn)
Date: Mon, 23 Oct 2000 16:03:44 -0700
Subject: [Python-Dev] Re: ajuba solutions (formerly scriptics) acquired by interwoven
References: <Pine.LNX.4.10.10010231624060.31805-100000@akbar.nevex.com>
Message-ID: <036501c03d45$81aefae0$3225d2d1@ARES>

I'm not on python-dev so please be sure to copy me on replies.


"Greg Wilson" <gvwilson@nevex.com> wrote:
>
> I thought about using wxPython in the most recent run of my Python course,
but
> decided to stick to Tkinter because:
>
> - There isn't a wxWindows/wxPython book (matters a lot when organizations
are
>   trying to decide what to adopt for long-term use).
>

This is something I am hoping to change in the near future.  I have a lot of
ideas, have been putting an outline together, and have a phone conference
with a potential publisher tomorrow.

> - Tkinter came packaged with the 1.5.2 installer, wxPython didn't.
>
> - There aren't as many tools on top of wxPython as there are on top of
Tkinter.
>   In particular, I think that a vector drawing package on top of wxPython
that
>   did what Sketch does, but on Windows as well as Linux, would make a
great
>   subject for a book on Python, non-trivial OO, and HCI (hint, hint...)

Hint received and understood...


"Andrew Kuchling" akuchlin@mems-exchange.org wrote:
>
> It seems to me that supporting MacOS is the big problem for
> cross-platform GUIs.  There are several different systems such as Qt
> that aim for portability across Windows and Unix, but add in the MacOS
> and the options really decrease.  How good is wxWindows support for
> MacOS?

My understanding is that the version in CVS is nearly up to date with the
features in the MSW and GTK versions, though I haven't had a chance to use
it myself.  It's in use in at least a few commercial applications around the
world.

The next step I guess is getting it wrapped up in wxPython, which should
just be a matter of porting some of the low level startup and helper code,
and putting some ifdef's in the SWIG interface files for things that may be
different in the Mac version of wxWindows.  Unfortunately, given the current
state of the amount of my spare time and relative Mac-illiterate-ness, it's
either going to require someone else to work on it and be wxPython-Mac's
champion, or somebody needs to fund my ramp-up and development time so I can
cut back on other things.  The good news is that I have been loaned a Mac
and CodeWarior and such to play with, I just haven't found the time to play
much lately.



"Guido van Rossum" guido@python.org wrote:
> Plus, Tk has two very high quality widgets: the Canvas and Text
> widgets are unsurpassed in functionality and robustness by other
> widget sets.  You can draw more lines or characters per second in most
> toolkits, but few toolkits offer the convenience of marks and tags,
> not having to deal with refresh events, being able to group objects,
> move them around, change attributes, etc., etc., etc.
>
> The Scintilla text widget comes close (and surpasses Tkinter in some
> respects, while coming short in others),

Just in case anybody didn't know already, wxWindows/wxPython has a wrapper
around Scintilla available called wxStyledTextCtrl.

> but I know of no widget in a
> popular widget set that offers anything close to the Canvas widget.

wxWindows has a canvas widget in development right now.  I've been trying to
nudge the developers working on it towards features found in the tk canvas
and the GNOME canvas widget.  I have high hopes for it but I'm not sure how
long it will be before it gets to the same level as the others.


--
Robin Dunn
Software Craftsman
robin@AllDunn.com
http://wxPython.org     Java give you jitters?
http://wxPROs.com        Relax with wxPython!




From esr@thyrsus.com  Tue Oct 24 00:29:54 2000
From: esr@thyrsus.com (Eric S. Raymond)
Date: Mon, 23 Oct 2000 19:29:54 -0400
Subject: [Python-Dev] Re: ajuba solutions (formerly scriptics) acquired by interwoven
In-Reply-To: <036501c03d45$81aefae0$3225d2d1@ARES>; from robin@alldunn.com on Mon, Oct 23, 2000 at 04:03:44PM -0700
References: <Pine.LNX.4.10.10010231624060.31805-100000@akbar.nevex.com> <036501c03d45$81aefae0$3225d2d1@ARES>
Message-ID: <20001023192954.A3313@thyrsus.com>

Robin Dunn <robin@alldunn.com>:
>                                      Unfortunately, given the current
> state of the amount of my spare time and relative Mac-illiterate-ness, it's
> either going to require someone else to work on it and be wxPython-Mac's
> champion, or somebody needs to fund my ramp-up and development time so I can
> cut back on other things.

This is exactly what CoSource and SourceXchange are for.  Post your Mac port
as a project there and see who ponies up money.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

  "...quemadmodum gladius neminem occidit, occidentis telum est."
[...a sword never kills anybody; it's a tool in the killer's hand.]
        -- (Lucius Annaeus) Seneca "the Younger" (ca. 4 BC-65 AD),


From MarkH@ActiveState.com  Tue Oct 24 00:19:33 2000
From: MarkH@ActiveState.com (Mark Hammond)
Date: Tue, 24 Oct 2000 10:19:33 +1100
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: <20001023140641.A3899@ActiveState.com>
Message-ID: <ECEPKNMJLHAPFFJHDOJBMEJGDOAA.MarkH@ActiveState.com>

Trimmed all CCs

[Guido]
> and the Mozilla toolkit (whose name I forget -- maybe David
> Ascher can fill me in).

[Trent "David Ascher" Mick responds]
> XUL. Though slappin' a GUI together in XUL is not all the same as for
> the other toolkits. Layout with XML, functionality with
> JavaScript and Python (and/or Perl of C++).

As a fairly irrelevant (at this point in time) observation:

Something about the Mozilla XUL engine seems "right".  It is large and
complex, but their XML based layout engine, and powerful "code-less" widget
creation has a lot of potential IMO.

It is very very new and rough.  It is very tightly bound with Mozilla
itself and javascript, although efforts are underway to separate it from
both.  It is huge, and constantly changing.  It has been designed for
tomorrow, and struggles along today.  But it may well turn out to be and
expressive and compelling model for the future.

So, if we can just continue to disagree for the next 2 or 3 years, it may
well become something worth considering ;-)

Mark.



From robin@alldunn.com  Tue Oct 24 00:56:59 2000
From: robin@alldunn.com (Robin Dunn)
Date: Mon, 23 Oct 2000 16:56:59 -0700
Subject: [Python-Dev] Re: ajuba solutions (formerly scriptics) acquired by interwoven
References: <Pine.LNX.4.10.10010231624060.31805-100000@akbar.nevex.com> <036501c03d45$81aefae0$3225d2d1@ARES> <20001023192954.A3313@thyrsus.com>
Message-ID: <038601c03d4c$ef14f1f0$3225d2d1@ARES>

>
> This is exactly what CoSource and SourceXchange are for.  Post your Mac
port
> as a project there and see who ponies up money.

Now why didn't I think of that???  Thanks for the idea!

--
Robin Dunn
Software Craftsman
robin@AllDunn.com
http://wxPython.org     Java give you jitters?
http://wxPROs.com        Relax with wxPython!




From DavidA@ActiveState.com  Tue Oct 24 05:00:51 2000
From: DavidA@ActiveState.com (David Ascher)
Date: Mon, 23 Oct 2000 21:00:51 -0700 (Pacific Daylight Time)
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: <200010232108.QAA12524@cj20424-a.reston1.va.home.com>
Message-ID: <Pine.WNT.4.21.0010231545180.1476-100000@loom>

> The Scintilla text widget comes close (and surpasses Tkinter in some
> respects, while coming short in others), but I know of no widget in a
> popular widget set that offers anything close to the Canvas widget.
> 
> There are other choices too, all of which have Python support already:
> gtk, qt, and the Mozilla toolkit (whose name I forget -- maybe David
> Ascher can fill me in).

The mozilla toolkits has more names than I care to remember.  =)  The most
generic name is XPFE, although there are some parts of it with nicer names
like XUL (pronounced Zool) and XBL.  It also heavily uses XML, DTDs, CSS,
etc.

Mozilla is definitely a long-term investment in our part.  For example,
currently it's not possible to have Python code inline in the XUL
(XML) code, and JavaScript is the only option there.  We'll be working w/
the Netscape and Mozilla crowds to fix that, but it's not there yet.

That said, Mozilla does have a fairly strong vision for the future, allows
some of the benefits of the web technologies to transfer to the GUI world
(designers, not coders, can do the UI work).

In terms of the closest equivalent to the Canvas widget, apart from XUL
itself, which is very hierarchical, there is the promise of SVG support,
which will give you a lot more than the Canvas.  That, too, is not quite
ready for prime time yet.

Hope this is helpful,

--david




From cgw@fnal.gov  Tue Oct 24 05:32:04 2000
From: cgw@fnal.gov (Charles G Waldman)
Date: Mon, 23 Oct 2000 23:32:04 -0500 (CDT)
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: <Pine.WNT.4.21.0010231545180.1476-100000@loom>
References: <200010232108.QAA12524@cj20424-a.reston1.va.home.com>
 <Pine.WNT.4.21.0010231545180.1476-100000@loom>
Message-ID: <14837.4292.807070.848419@buffalo.fnal.gov>

David Ascher writes:
 > 
 > That said, Mozilla does have a fairly strong vision for the future, allows
 > some of the benefits of the web technologies to transfer to the GUI world
 > (designers, not coders, can do the UI work).

Sounds great for the future, but I want to inject a few of my
unsolicated, opinionated observations - today, in 2000, the Mozilla
stuff is *far* from usable.  If you want to produce nice, professional
looking GUI apps which fit nicely with the desktop (rather that having
their own completely different look-and-feel) it's hard to beat Gtk+
or Tkinter.  Tkinter is still quite viable, especially if
cross-plaform support is important.  Some of the examples in Grayson's
book are quite beautiful.  It will be a long time until
XPFE/XUL/whatchamacallit gets to this level of viability.

Also consider that Sun (and HP?) now ship Gnome by default, rather
than CDE (or so I hear, anyway).  I predict that Gnome compatibility
will become more and more of a desirable feature.

Evidence of the above is the "Galeon" project.  It's widely perceived
that Mozilla has a nice rendering engine (Gecko) wrapped up in a
dreadful GUI (XPFE).  So the Galeon project places the Gecko engine
inside a Gtk+/Gnome GUI, which provides a much more pleasant user
experience.

There's also a (preliminary) port of Gtk+ to Win32:
http://www.gimp.org/~tml/gimp/win32/

And, finally, IMO, the work being done on PyGtk is of high quality.
I'm using it currently in production code.


From DavidA@ActiveState.com  Tue Oct 24 06:12:14 2000
From: DavidA@ActiveState.com (David Ascher)
Date: Mon, 23 Oct 2000 22:12:14 -0700 (Pacific Daylight Time)
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: <14837.4292.807070.848419@buffalo.fnal.gov>
Message-ID: <Pine.WNT.4.21.0010232209570.612-100000@cr469175-a>

> There's also a (preliminary) port of Gtk+ to Win32:
> http://www.gimp.org/~tml/gimp/win32/

FWIW, the last time I checked, this was useless.  I'd be glad to be wrong,
but I'm not holding my breath.  Not surprisingly, the GTK crowd, which is
rooted in Linux tradition (!), has little interest in Win32 ports, and
even less experience in that world.  Until that happens, a lot of
platform-agnostic projects and vendors will have a hard time w/ GTK.

I don't mean to diss GTK, just pointing out that cross-platform solutions
are important to a whole lot of communities (Python included).

--david



From tim_one@email.msn.com  Tue Oct 24 06:20:07 2000
From: tim_one@email.msn.com (Tim Peters)
Date: Tue, 24 Oct 2000 01:20:07 -0400
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: <200010232108.QAA12524@cj20424-a.reston1.va.home.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCEEIAHMAA.tim_one@email.msn.com>

[ESR]
> ...
> and John Osterhout's attempt to commercialize the language have led to
> a series of false starts and erratic moves.

We don't want to criticize anyone for that:  PythonLabs' attempts *not* to
commercialize Python may yet make Tcl's path look as straight and true as a
laser beam <blink>.

obliquely y'rs  - tim




From tim_one@email.msn.com  Tue Oct 24 06:31:07 2000
From: tim_one@email.msn.com (Tim Peters)
Date: Tue, 24 Oct 2000 01:31:07 -0400
Subject: [Python-Dev] Starship down ?
In-Reply-To: <200010232012.PAA12261@cj20424-a.reston1.va.home.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCAEIBHMAA.tim_one@email.msn.com>

[MAL]
> The starship.python.net server seems to be down. Could someone
> with sysadmin access please fix this ?!

[GvR]
> Yeah, this is very unfortunate.  It's the same problem that's keeping
> pytholabs.com down.  The BeOpen systems staff is working on it, but I
> don't know what the problem is or when it will be fixed.

FYI, pythonlabs.com is up again, but Starship is still down.  We only said
it's the same problem because we didn't know what either problem was.  And,
we still don't!

long-distance-ly y'rs  - tim




From cgw@fnal.gov  Tue Oct 24 06:34:23 2000
From: cgw@fnal.gov (Charles G Waldman)
Date: Tue, 24 Oct 2000 00:34:23 -0500 (CDT)
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: <Pine.WNT.4.21.0010232209570.612-100000@cr469175-a>
References: <14837.4292.807070.848419@buffalo.fnal.gov>
 <Pine.WNT.4.21.0010232209570.612-100000@cr469175-a>
Message-ID: <14837.8031.342286.639052@buffalo.fnal.gov>

David Ascher writes:

 >cgw> There's also a (preliminary) port of Gtk+ to Win32:
 >cgw> http://www.gimp.org/~tml/gimp/win32/
 > 
 > FWIW, the last time I checked, this was useless.

That's what I meant by "preliminary" ;-)

 > I don't mean to diss GTK, just pointing out that cross-platform solutions
 > are important to a whole lot of communities (Python included).

Right.  Cross-platform is very important, but so is native
look-and-feel, and this is where (IMO) XPFE falls flat on its face.
Something like WxWindows, which uses Gtk+ on *nix and MFC (?) on Win,
seems like it could be a real winner.  If the x-platform GUI doesn't
use native dialog boxes and filechoosers, users REALLY notice this and
they will just hate it.  (Yes, this is based on observations of actual
paying customers).

I have a little bit of experience with cross-platform development -
having used a lot of these tools - at my last job, after evaluating
just about everything, we bought into (against my advice!) a doomed
commercial product called Visix Galaxy (for which I immediately
created a set of Python bindings).  The problem with all of these
things, of course, is that the more cross-platform they are, the more
"lowest-common-denominator" they are forced to become.

Tkinter, with widgets like Canvas, was really pretty amazing - for its
day - feature-rich *and x-platform.  But even this broke down if you
started using fancy features like drawing with dashed lines - works on
X, not on Windows (last time I checked, anyway) - the more you start
pushing the limits of the toolkit, the more the portability breaks
down.

Tkinter-is-dead-long-live-Tkinter'ly yrs, 
				     -C


From MarkH@ActiveState.com  Tue Oct 24 06:48:34 2000
From: MarkH@ActiveState.com (Mark Hammond)
Date: Tue, 24 Oct 2000 16:48:34 +1100
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: <14837.8031.342286.639052@buffalo.fnal.gov>
Message-ID: <ECEPKNMJLHAPFFJHDOJBEEKEDOAA.MarkH@ActiveState.com>

> Right.  Cross-platform is very important, but so is native
> look-and-feel, and this is where (IMO) XPFE falls flat on its face.

Actually, my experience with XPFE from a look-and-feel POV has been pretty
positive.  It is true they have re-implemented most widgets rather than use
native ones, and also true that you can make these widgets look nothing
like native LAF - but generally, my experience with Mozilla and the
"classic" skin is that it is close enough that it is very hard to tell.  It
looks more like "subtle enhancements", in the same way IE provides "subtle
enhancements"

> seems like it could be a real winner.  If the x-platform GUI doesn't
> use native dialog boxes and filechoosers, users REALLY notice this and

Agreed.  However, XPFE works fine here IMO.

Again, I do not want to propose XPFE as viable today, and I agree it may
never be viable.  Most other critisisms posted are valid, but I don't think
that LAF is one such problem with XPFE.

Mark.



From paul@prescod.net  Tue Oct 24 07:29:42 2000
From: paul@prescod.net (Paul Prescod)
Date: Mon, 23 Oct 2000 23:29:42 -0700
Subject: [Python-Dev] FYI: ajuba solutions (formerly scriptics) acquired by
 interwoven
References: <003201c03d18$f384a5c0$3c6340d5@hagrid> <20001023154016.A2722@thyrsus.com> <20001023162118.B18005@kronos.cnri.reston.va.us> <001e01c03d34$d11bd5f0$3c6340d5@hagrid>
Message-ID: <39F52C56.214B28A1@prescod.net>

Fredrik Lundh wrote:
> 
>...
> 
> http://sourceforge.net/projects/tcl
> http://sourceforge.net/projects/tktoolkit
> 
> and trust me, the Python 2.0/Tk8.4/Tkinter3000 combo
> will rock ;-)

Perhaps this could be an opportunity to split Tcl and Tk more cleanly.
People like Fredrick and his Perl/Ruby/... equivalents could get more
deeply involved in setting direction. It would be interesting to
contrast the number of Tcl versus Tk users right now.
-- 
 Paul Prescod - Not encumbered by corporate consensus
Simplicity does not precede complexity, but follows it. 
	- http://www.cs.yale.edu/homes/perlis-alan/quotes.html


From paul@prescod.net  Tue Oct 24 07:40:49 2000
From: paul@prescod.net (Paul Prescod)
Date: Mon, 23 Oct 2000 23:40:49 -0700
Subject: [Python-Dev] Gradual migration
Message-ID: <39F52EF1.A201C6D9@prescod.net>

Python 3K. It is the repository for our hopes and dreams. We tend to
invoke it in three different situations:

 1. in delaying discussions of gee-whiz features (e.g. static type
checking)

 2. in delaying hairy implementation re-factoring that we don't
want to undertake right now.

 3. in delaying painful backwards-compatibility breakage

I think it is somewhat debatable whether we really need to or should do
these three things all at once but that's a separate discussion for
another day. (the other experiment may inform our decision)

I want to focus on "3" -- breakage. Rather than delaying painful
backwards-compatibility breakage I thing we should make it less painful.
We should decide where we are going long before we ask our users to move
there. I think we should start including alternatives to syntaxes and
features that we know are broken. Once people move to the alternatives
we can "reassign" or remove the original syntax with much less pain.

In other words, rather than telling people "here's a new version, your
code is broken, sorry." We should tell them: "we're going to break code.
Here's an alternative syntax that you can use that will be interpreted
the same in the old and new versions -- please move to this new syntax
as quickly as possible."

I'll outline some examples of the strategy. You may or may not like
details of the particular proposals but you might still agree with the
strategy. Also, I don't claim that all of the proposals are fully
fleshed-out...again, it's the strategy I'm most interested in. I don't
even agree with every feature change I describe below -- they are just
some I've heard of for Python 3000. In other words ** this is not a
design document for Python 3000! **

Separating byte arrays from strings:

 1. immediately introduce two new functions:

   binopen("foo").read() -> byte array
   stropen("foo","UTF-8".read() -> u"...."

 2. warn about string literals that have embedded non-Unicode characters

 3. deprecate extension modules that return "old fashioned" string
arrays

 4. after a period where all strings have been restricted to
Unicode-compatibility, merge the Unicode and string types.

 5. deprecate the special Unicode u"" syntax as an imperialist
anachronism



Reclaiming the division operator from truncating integer division:

 1. immediately introduce new functions: div() that does division as we
wish it was.

 2. add a warning mode to Python (long overdue)

 3. with the warning mode on, old-fashioned division triggers a
deprecation warning.

 4. after three years as a warning situation we expect all in-use Python
scripts to have been upgraded to use the new operations and to
explicitly truncate integer division when that is what is wanted.

 5. at that point we can re-assign the division operator to be a
floating point division if we wish.




Case insensitivity:

 1. Warn whenever a module or class has two __dict__ entries that differ
only by case

 2. Eventually, disallow that form of name-clash altogether

 3. After a period, allow case variations to be equivalent.



Unifying types and classes (more vague):

 1. Add something like extension class to make type subclassing easier.

 2. Informally deprecate modules that do not incorporate it.

 3. Replace or fix details of the language and implementation that
behave differently for types and classes. (e.g. the type() operator)




-- 
 Paul Prescod - Not encumbered by ActiveState consensus
Simplicity does not precede complexity, but follows it. 
	- http://www.cs.yale.edu/homes/perlis-alan/quotes.html


From pf@artcom-gmbh.de  Tue Oct 24 08:47:03 2000
From: pf@artcom-gmbh.de (Peter Funk)
Date: Tue, 24 Oct 2000 09:47:03 +0200 (MEST)
Subject: Integer division revisited (was Re: [Python-Dev] Gradual migration)
In-Reply-To: <39F52EF1.A201C6D9@prescod.net> from Paul Prescod at "Oct 23, 2000 11:40:49 pm"
Message-ID: <m13nynX-000Dm8C@artcom0.artcom-gmbh.de>

Hi,

Paul Prescod wrote on python-dev@python.org:
[...]
> Reclaiming the division operator from truncating integer division:
[...]

Bruce Sherwood and David Scherer suggested a IMHO very clever solution to
this particular problem in March/April this year.  This thread was first 
posted to idle-dev and afterwards X-posted to python-dev:

http://www.python.org/pipermail/idle-dev/2000-April/000138.html
http://www.python.org/pipermail/idle-dev/2000-April/000140.html
http://www.python.org/pipermail/python-dev/2000-April/010029.html

Unfortunately I'm no native english speaker and have not enough time 
to make a Python-2.1 PEP from it.  May be somebody else wants to go for it?

I still believe, this was a very clever Python enhancement, which should
be officially proposed.

Regards, Peter
-- 
Peter Funk, Oldenburger Str.86, D-27777 Ganderkesee, Germany, Fax:+49 4222950260
office: +49 421 20419-0 (ArtCom GmbH, Grazer Str.8, D-28359 Bremen)


From mal@lemburg.com  Tue Oct 24 09:45:03 2000
From: mal@lemburg.com (M.-A. Lemburg)
Date: Tue, 24 Oct 2000 10:45:03 +0200
Subject: [Python-Dev] Gradual migration
References: <39F52EF1.A201C6D9@prescod.net>
Message-ID: <39F54C0F.25798309@lemburg.com>

Paul Prescod wrote:
> 
> Python 3K. It is the repository for our hopes and dreams. We tend to
> invoke it in three different situations:
> 
>  1. in delaying discussions of gee-whiz features (e.g. static type
> checking)
> 
>  2. in delaying hairy implementation re-factoring that we don't
> want to undertake right now.
> 
>  3. in delaying painful backwards-compatibility breakage
> 
> I think it is somewhat debatable whether we really need to or should do
> these three things all at once but that's a separate discussion for
> another day. (the other experiment may inform our decision)

I think will simply be a consequence of doing a complete rewrite
of the interpreter for Py3K. AFAIR, the only truely feasable
solution would be doing the rewrite in a widely portable
subset of C++ and then managing classes at that level.
 
Moving to a common and very low-level strategy for classes
will allows us to put even the most basic types (strings and
numbers) into an inheritence tree. 

Differences like the
ones between Unicode and 8-bit strings would then flesh
out as two different subclasses of a generic string type which
again is based on a generic sequence type.

The same could be done for dictionaries: special ones for
just string keys, case insensitive lookups, etc. could all
be subclasses of a generic mapping class.

Dito for numbers (and division strategies).

By following this principle there won't be all that much
breakage, since the old functionality will still be around,
only the defaults will have changed.

Add to this pluggable compilers and ceval loops, plus a nice
way of configuring the lot on a per-module basis and you're
set. (Ok, it's a fluffy clouds image, but you get the picture ;-)

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/


From guido@python.org  Tue Oct 24 16:57:43 2000
From: guido@python.org (Guido van Rossum)
Date: Tue, 24 Oct 2000 10:57:43 -0500
Subject: [Python-Dev] Gradual migration
In-Reply-To: Your message of "Tue, 24 Oct 2000 10:45:03 +0200."
 <39F54C0F.25798309@lemburg.com>
References: <39F52EF1.A201C6D9@prescod.net>
 <39F54C0F.25798309@lemburg.com>
Message-ID: <200010241557.KAA15629@cj20424-a.reston1.va.home.com>

> Paul Prescod wrote:
> > 
> > Python 3K. It is the repository for our hopes and dreams. We tend to
> > invoke it in three different situations:
> > 
> >  1. in delaying discussions of gee-whiz features (e.g. static type
> > checking)
> > 
> >  2. in delaying hairy implementation re-factoring that we don't
> > want to undertake right now.
> > 
> >  3. in delaying painful backwards-compatibility breakage
> > 
> > I think it is somewhat debatable whether we really need to or should do
> > these three things all at once but that's a separate discussion for
> > another day. (the other experiment may inform our decision)

Marc-Andre Lemburg replied:

> I think will simply be a consequence of doing a complete rewrite
> of the interpreter for Py3K. AFAIR, the only truely feasable
> solution would be doing the rewrite in a widely portable
> subset of C++ and then managing classes at that level.
>  
> Moving to a common and very low-level strategy for classes
> will allows us to put even the most basic types (strings and
> numbers) into an inheritence tree. 
> 
> Differences like the
> ones between Unicode and 8-bit strings would then flesh
> out as two different subclasses of a generic string type which
> again is based on a generic sequence type.
> 
> The same could be done for dictionaries: special ones for
> just string keys, case insensitive lookups, etc. could all
> be subclasses of a generic mapping class.
> 
> Dito for numbers (and division strategies).
> 
> By following this principle there won't be all that much
> breakage, since the old functionality will still be around,
> only the defaults will have changed.
> 
> Add to this pluggable compilers and ceval loops, plus a nice
> way of configuring the lot on a per-module basis and you're
> set. (Ok, it's a fluffy clouds image, but you get the picture ;-)

Good job in channeling me, Marc-Andre!  I'm sure that's not exactly
how it's going to be, but on the face of it, this sure sounds like a
reasonable possible route.  Do you want to be the author for PEP-3000?

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


From guido@python.org  Tue Oct 24 17:13:37 2000
From: guido@python.org (Guido van Rossum)
Date: Tue, 24 Oct 2000 11:13:37 -0500
Subject: [Python-Dev] Gradual migration
In-Reply-To: Your message of "Mon, 23 Oct 2000 23:40:49 MST."
 <39F52EF1.A201C6D9@prescod.net>
References: <39F52EF1.A201C6D9@prescod.net>
Message-ID: <200010241613.LAA15769@cj20424-a.reston1.va.home.com>

> I want to focus on "3" -- breakage. Rather than delaying painful
> backwards-compatibility breakage I thing we should make it less painful.
> We should decide where we are going long before we ask our users to move
> there. I think we should start including alternatives to syntaxes and
> features that we know are broken. Once people move to the alternatives
> we can "reassign" or remove the original syntax with much less pain.

Absolutely.  Whenever possible, we should try to plan for migration in
Python 2.x.

> In other words, rather than telling people "here's a new version, your
> code is broken, sorry." We should tell them: "we're going to break code.
> Here's an alternative syntax that you can use that will be interpreted
> the same in the old and new versions -- please move to this new syntax
> as quickly as possible."

It would also help if we could produce automatic translation tools
that will convert the old syntax into the new.  This desire may
restrict our choices however: the translation tools don't have runtime
information to go by.  It's easy enough to change obsolete syntax into
new syntax, but it's hard to decide whether a particular "/" operator
should be changed into an integer divide ("//") or left alone.

> I'll outline some examples of the strategy. You may or may not like
> details of the particular proposals but you might still agree with the
> strategy. Also, I don't claim that all of the proposals are fully
> fleshed-out...again, it's the strategy I'm most interested in. I don't
> even agree with every feature change I describe below -- they are just
> some I've heard of for Python 3000. In other words ** this is not a
> design document for Python 3000! **

I think the proper approach is to start a separate migration process
for each of these proposed changes.  Each should be paced separately
(the pace may depend on how hard to swallow the change is for users as
well as how hard it is to implement the new functionality) and for
each, a separate PEP in the 3000 series should be started.  I can even
see that several PEPs will be needed in some cases (e.g. one to
describe the new syntax, one to to flesh out the implementation, and
one to decide on the migration steps).

I won't comment on Paul's examples, that's for the various PEP
processes.

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


From cgw@fnal.gov  Tue Oct 24 16:21:45 2000
From: cgw@fnal.gov (Charles G Waldman)
Date: Tue, 24 Oct 2000 10:21:45 -0500 (CDT)
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: <ECEPKNMJLHAPFFJHDOJBKEKIDOAA.MarkH@ActiveState.com>
References: <14837.14407.954185.466011@buffalo.fnal.gov>
 <ECEPKNMJLHAPFFJHDOJBKEKIDOAA.MarkH@ActiveState.com>
Message-ID: <14837.43273.24692.93965@buffalo.fnal.gov>

Mark Hammond writes:
 > >  > Agreed.  However, XPFE works fine here IMO.
 > >
 > cgw> "Here" means on MS-Win, right?   Maybe that's why our perceptions are
 > cgw> so different.
 > 
 > Correct.  Although I have run it under Linux a few times, I wouldnt really
 > know LAF issues if I tripped over them there ;-)
 > 
 > Mark.

It's certainly true that the lack of a consistent look and feel for
Linux apps has been somewhat of a problem historically.  However, with
the emergence of Gnome, it seems that there is finally some
convergence.  (Althought people in the KDE/Qt camp will certainly not
agree!)  Gnome is gathering momentum, especially now that Sun has
joined the Gnome Foundation.  With outfits like Eazel, Helix Code,
etc, turning out high-quality products, things are moving fast in the
Gnome/Gtk+ world and it seems clear to me that this will be the major
desktop platform for Unix machines in the upcoming decade.

Back in my former life, when I was still worrying about Windows, the
company I worked for bought into a commerical x-platform GUI toolkit
called Galaxy (I mentioned this earlier).  Galaxy re-implemented all
the native widgets, kind of like XPFE does.  One issue with this was
that MS seemed to change something about the widgets in every release
- e.g. the Galaxy filechooser looked like Windows 3.1, then Win95 came
out and Galaxy had to play catch-up.  Once Galaxy had the Win95 LAF,
Win98 came out.  Now I hear there's something called Windows ME.  Have
they changed the look-and-feel again?  Seems to me like all the
widget-reimplementors are doomed to playing eternal catch-up.

OK, enough off-topic rambling (for now),
	   
	   -C





From akuchlin@mems-exchange.org  Tue Oct 24 16:43:26 2000
From: akuchlin@mems-exchange.org (Andrew Kuchling)
Date: Tue, 24 Oct 2000 11:43:26 -0400
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: <14837.43273.24692.93965@buffalo.fnal.gov>; from cgw@fnal.gov on Tue, Oct 24, 2000 at 10:21:45AM -0500
References: <14837.14407.954185.466011@buffalo.fnal.gov> <ECEPKNMJLHAPFFJHDOJBKEKIDOAA.MarkH@ActiveState.com> <14837.43273.24692.93965@buffalo.fnal.gov>
Message-ID: <20001024114326.E13957@kronos.cnri.reston.va.us>

On Tue, Oct 24, 2000 at 10:21:45AM -0500, Charles G Waldman wrote:
>It's certainly true that the lack of a consistent look and feel for
>Linux apps has been somewhat of a problem historically.  However, with
>the emergence of Gnome, it seems that there is finally some
>convergence.  (Althought people in the KDE/Qt camp will certainly not

Careful... while people may try to port GTk+ to Windows, porting GNOME
is a different kettle of wax, because GNOME needs GTk+ but also
entails gnome-libs and gnome-vfs and Bonobo and esound and lots of
other things, which provide services such as object embedding that
wouldn't be required -- or would be very different -- on Windows.  I
don't know if anyone is trying to tease apart GNOME into a
Windows-suitable subset; it seems like it would be a difficult task.

Qt is at least a toolkit that aims at cross-platform portability,
though there again, the KDE environment built on top of it is not
going to be portable to anything that isn't Unix.  Both the Qt and
GTk+ toolkits ignore the Mac, leaving Tk and wxWindows as the only
real possibilities.  This is why, every time this debate comes up, we
end up sticking with Tk; it may suck, but all the other systems don't
support everything...

Maybe the best approach is to follow /F's lead with Tkinter3000, and
reimplement the Tkinter API on top of MFC / GTk+ / Qt.  (Er... that
*is* what Tkinter3000 is, right?)  What's the problem we're trying to solve here?

     * Is it that the problem that the Tkinter module is a bad API for
       GUI programming?

     * Or is it that the Tk implementation is slow or bulky?

     * Or do we just dislike having to require Tcl as well as Tk?

Can someone articulate why Tk should be replaced?

--amk


From gvwilson@nevex.com  Tue Oct 24 16:52:00 2000
From: gvwilson@nevex.com (Greg Wilson)
Date: Tue, 24 Oct 2000 11:52:00 -0400 (EDT)
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: <20001024114326.E13957@kronos.cnri.reston.va.us>
Message-ID: <Pine.LNX.4.10.10010241146450.6622-100000@akbar.nevex.com>

> Andrew Kuchling wrote:
> What's the problem we're trying to solve here?
> 
> * Is it that the problem that the Tkinter module is a bad API for
>   GUI programming?
> 
> * Or is it that the Tk implementation is slow or bulky?
> 
> * Or do we just dislike having to require Tcl as well as Tk?
> 
> Can someone articulate why Tk should be replaced?

I can articulate why I'm unhappy with the current set-up:

1. Requiring Tcl is fragile.  Un-gumming installation on machines at Los
   Alamos before my first Python course cost me several hours, and I had
   to do it again two months' later.  I've run into similar problems with
   multiple Tcl installations on Windows machines (personal use).

2. (Lack of) native look and feel.  This is a complete show-stopper for
   many of the outfits I've dealt with (and not just with Python).

Performance doesn't really matter --- I've never had students complain about
speed, although I've never asked them to build something large enough that
refresh would be an issue.

I don't have experience teaching wxPython, so I can't comment on the
relative teachability of its API vs. Tk's.

Hope this helps,
Greg




From paul@prescod.net  Tue Oct 24 17:12:12 2000
From: paul@prescod.net (Paul Prescod)
Date: Tue, 24 Oct 2000 09:12:12 -0700
Subject: [Python-Dev] Gradual migration
References: <39F52EF1.A201C6D9@prescod.net> <39F54C0F.25798309@lemburg.com>
Message-ID: <39F5B4DC.C226D8F6@prescod.net>

"M.-A. Lemburg" wrote:
> 
>...
> 
> I think will simply be a consequence of doing a complete rewrite
> of the interpreter for Py3K. AFAIR, the only truely feasable
> solution would be doing the rewrite in a widely portable
> subset of C++ and then managing classes at that level.

I disagree for a variety of reasons:

 * implementation language and Python inheritance semantics are almost
completely distinct. After all, we have Python implementations in a
variety of languages with minor incompatibilities. Python could have a
proper type/class merging even if it were written in assembly language.
So let's leave implementation language aside.

 * there is a hell of a lot we can do to make the type/class split less
visible without a major rewrite. For instance, lists could have a
__getitem__ method so that they "act like" instances. Instances could
return their methods in a dir() so that they "act like" built-in
objects. So there is no reason to wait for a complete rewrite to start
on this path.

 * It may even be the case that we can get from here to complete merged
type/class semantics WITHOUT a rewrite. If a mad genious had not written
stackless Python I would have sworn up and down that stackless Python
would require a Python rewrite. It didn't. If another slightly less mad
genious had not integrated ints and longs I would never have believed it
possible without another rewrite. Someone needs to do an analysis of
what it takes to merge types and classes and *demonstrate* that it
requires a rewrite rather than *asserting* that it requires a rewrite.

In other words, let's stop sprinkling the "major rewrite" pixie dust on
hard problems and instead decide where we want to go and how we want to
get there!

> Moving to a common and very low-level strategy for classes
> will allows us to put even the most basic types (strings and
> numbers) into an inheritence tree.

I don't know what you mean by a "low-level strategy" for classes. It's
not like we can somehow use C++ vtables without giving up Python's
dynamicity. Python's class handling is about as low-level as it can get
in my humble opinion.

> Differences like the
> ones between Unicode and 8-bit strings would then flesh
> out as two different subclasses of a generic string type which
> again is based on a generic sequence type.

Of course that's where we want to go but it doesn't avoid the backwards
compatibility problems. We can do this today using proxying.

> The same could be done for dictionaries: special ones for
> just string keys, case insensitive lookups, etc. could all
> be subclasses of a generic mapping class.

We can easily do this today.

> Dito for numbers (and division strategies).

There's no way I'm going to let you get away with that little sleight of
hand. How is inheritance holy water going to allow us to change the
semantics of:

5/2

without breaking code??

The same goes for

a.b = 5

versus

a.B = 5

C++ does not help. Inheritance does not help. Pluggable compilers do not
help. We *will* break code. We just need to decide whether to do it in a
thoughtful way that gives people a chance to migrate or put off
decisions until the last possible moment and then spring it on them with
no between-version upgrade path.

> By following this principle there won't be all that much
> breakage, since the old functionality will still be around,
> only the defaults will have changed.

When you change defaults you break code. Keeping the old functionality
around is barely helpful.  Nobody has EVER proposed a change to Python
where something that was previously possible is now made impossible. So
whatever our strategy, the PROBLEM is changing defaults. The solution is
telling people what defaults are changing in what timeline and
discouraging them from depending on the old defaults.

> Add to this pluggable compilers and ceval loops, plus a nice
> way of configuring the lot on a per-module basis and you're
> set. (Ok, it's a fluffy clouds image, but you get the picture ;-)

Sounds mythical. I'm trying to take it out of the realm of fluffy clouds
and bring it into the world that people can plan their businesses and
coding strategies around.
-- 
 Paul Prescod - Not encumbered by corporate consensus
Simplicity does not precede complexity, but follows it. 
	- http://www.cs.yale.edu/homes/perlis-alan/quotes.html


From paul@prescod.net  Tue Oct 24 17:30:17 2000
From: paul@prescod.net (Paul Prescod)
Date: Tue, 24 Oct 2000 09:30:17 -0700
Subject: [Python-Dev] Gradual migration
References: <39F52EF1.A201C6D9@prescod.net> <200010241613.LAA15769@cj20424-a.reston1.va.home.com>
Message-ID: <39F5B919.4B80A526@prescod.net>

Guido van Rossum wrote:
> 
> ...
> 
> I think the proper approach is to start a separate migration process
> for each of these proposed changes.  

I agree.

As a more concrete extension to my last email, I propose the following
doctrine:

"""
No major documented feature should be removed or have changed semantics
in Python 3000 or any other new version of Python until users have had a
year (preferably MORE!) of upgrade time. Upgrade time entails the
following parts:

    1. the released Python version has a new recommended way to
accomplish the task in a manner that will remain available in the
"breakage version" e.g. a div() function that people can use for a few
years while the semantics of "/" are in transition.

    2. the mechanism/syntax that will be removed is formally deprecated.
The documentation would say, e.g. "You should not use '/' for now. It is
changing semantics in the future."

    3. the released Python version sports a runtime warning to tell
users that the mechanism/syntax is going away. "CompatibilityError:
Future versions of Python will have different semantics for the '/'
operator. Please use div() instead."

The actual "right" amount of upgrade time depends on the extent of the
breakage and its ease of detection.
"""

I can PEP this if people agree. I think that the user community would
appreciate our effort to promise not to break code suddenly and
capriciously.
-- 
 Paul Prescod - Not encumbered by corporate consensus
Simplicity does not precede complexity, but follows it. 
	- http://www.cs.yale.edu/homes/perlis-alan/quotes.html


From barry@wooz.org  Tue Oct 24 17:26:13 2000
From: barry@wooz.org (Barry A. Warsaw)
Date: Tue, 24 Oct 2000 12:26:13 -0400 (EDT)
Subject: [Python-Dev] What to choose to replace Tkinter?
References: <20001024114326.E13957@kronos.cnri.reston.va.us>
 <Pine.LNX.4.10.10010241146450.6622-100000@akbar.nevex.com>
Message-ID: <14837.47141.817450.488896@anthem.concentric.net>

>>>>> "GW" == Greg Wilson <gvwilson@nevex.com> writes:

    GW> 2. (Lack of) native look and feel.  This is a complete
    GW> show-stopper for many of the outfits I've dealt with (and not
    GW> just with Python).

On the other hand, it's incredibly easy to whip together a GUI in Tk
for simple applications.  Yes, Tk gets painful as applications grow,
but I'd hate to abandon such a simple, well-known toolkit for a
complicated, hard-to-learn but powerful native look-and-feel one.  You
don't /always/ care about strict native LAF.

Or to restate: I'd hate to have to make that choice.  If we can't
satisfy both requirements (mandatory-native-LAF and rapid prototyping
friendliness), we may need to continue to support multiple toolkits.

the-delicious-aroma-of-the-first-GUI-bakeoff-still-in-the-air-ly y'rs,
-Barry


From guido@python.org  Tue Oct 24 18:39:38 2000
From: guido@python.org (Guido van Rossum)
Date: Tue, 24 Oct 2000 12:39:38 -0500
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: Your message of "Tue, 24 Oct 2000 11:52:00 -0400."
 <Pine.LNX.4.10.10010241146450.6622-100000@akbar.nevex.com>
References: <Pine.LNX.4.10.10010241146450.6622-100000@akbar.nevex.com>
Message-ID: <200010241739.MAA16414@cj20424-a.reston1.va.home.com>

> I can articulate why I'm unhappy with the current set-up:
> 
> 1. Requiring Tcl is fragile.  Un-gumming installation on machines at Los
>    Alamos before my first Python course cost me several hours, and I had
>    to do it again two months' later.  I've run into similar problems with
>    multiple Tcl installations on Windows machines (personal use).

For Windows, this problem has gone away in 1.6 and 2.0 -- we
distribute and install our own Tcl/Tk binaries, in a place that
doesn't affect or require existing Tcl/Tk installations.

Maybe we can do the same for Unix binary distributions?  I believe
Jeremy has already had to create a separate RPM for _tkinter because
there are too many different versions of Tcl/Tk out there -- it
shouldn't be hard to install our own altogether.

> 2. (Lack of) native look and feel.  This is a complete show-stopper for
>    many of the outfits I've dealt with (and not just with Python).

Really?  Are you sure that's not just general resistence against new
things?  To me, and I suspect may others, the app I use most often on
Windows is Netscape -- talk about lack of native look-and-feel!  It's
never bothered me all that much.

Or are you saying that IDLE isn't designed as a typical Microsoft app?
That's quite a separate issue from the widget look-and-feel!

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


From barry@wooz.org  Tue Oct 24 17:40:50 2000
From: barry@wooz.org (Barry A. Warsaw)
Date: Tue, 24 Oct 2000 12:40:50 -0400 (EDT)
Subject: [Python-Dev] Gradual migration
References: <39F52EF1.A201C6D9@prescod.net>
 <39F54C0F.25798309@lemburg.com>
 <39F5B4DC.C226D8F6@prescod.net>
Message-ID: <14837.48018.547379.464959@anthem.concentric.net>

>>>>> "PP" == Paul Prescod <paul@prescod.net> writes:

    PP>  * implementation language and Python inheritance semantics
    PP> are almost completely distinct. After all, we have Python
    PP> implementations in a variety of languages with minor
    PP> incompatibilities. Python could have a proper type/class
    PP> merging even if it were written in assembly language.  So
    PP> let's leave implementation language aside.

Jython experience backs this up.  It would be incredibly convenient if
we could just map Java classes to Python classes, so that for example,
we'd have in Java a PyException class that is exceptions.Exception
with minimal or no Java wrappings.  And Finn nearly did this.

The problem that we ran into with Java is that it allows only single
inheritance.  So you couldn't create a Python exception that multiply
inherited from two or more other Python exceptions.  Doesn't happen
often, but it does happen, so is that an acceptable tradeoff?

C++ might be better in this particular respect, but there will be
other issues, because as soon as you start transparently showing the
implementation's classes into Python, you inherit their semantics and
restrictions as well.

Just saying that it's tricky.
-Barry


From guido@python.org  Tue Oct 24 18:54:39 2000
From: guido@python.org (Guido van Rossum)
Date: Tue, 24 Oct 2000 12:54:39 -0500
Subject: [Python-Dev] Gradual migration
In-Reply-To: Your message of "Tue, 24 Oct 2000 09:30:17 MST."
 <39F5B919.4B80A526@prescod.net>
References: <39F52EF1.A201C6D9@prescod.net> <200010241613.LAA15769@cj20424-a.reston1.va.home.com>
 <39F5B919.4B80A526@prescod.net>
Message-ID: <200010241754.MAA16520@cj20424-a.reston1.va.home.com>

> As a more concrete extension to my last email, I propose the following
> doctrine:
> 
> """
> No major documented feature should be removed or have changed semantics
> in Python 3000 or any other new version of Python until users have had a
> year (preferably MORE!) of upgrade time. Upgrade time entails the
> following parts:
> 
>     1. the released Python version has a new recommended way to
> accomplish the task in a manner that will remain available in the
> "breakage version" e.g. a div() function that people can use for a few
> years while the semantics of "/" are in transition.
> 
>     2. the mechanism/syntax that will be removed is formally deprecated.
> The documentation would say, e.g. "You should not use '/' for now. It is
> changing semantics in the future."
> 
>     3. the released Python version sports a runtime warning to tell
> users that the mechanism/syntax is going away. "CompatibilityError:
> Future versions of Python will have different semantics for the '/'
> operator. Please use div() instead."
> 
> The actual "right" amount of upgrade time depends on the extent of the
> breakage and its ease of detection.
> """
> 
> I can PEP this if people agree. I think that the user community would
> appreciate our effort to promise not to break code suddenly and
> capriciously.

Go for it.  I have little bandwidth to think about this deeply, but
what you're proposing here sounds like a good approach.  Certainly it
will make it easier if I can point to this PEP when I get the next FUD
email about "should I bother to learn Python 2.0 when Py3K is going to
be all different?"...

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


From effbot@telia.com  Tue Oct 24 18:07:12 2000
From: effbot@telia.com (Fredrik Lundh)
Date: Tue, 24 Oct 2000 19:07:12 +0200
Subject: [Python-Dev] FYI: ajuba solutions (formerly scriptics) acquired by interwoven
References: <003201c03d18$f384a5c0$3c6340d5@hagrid> <20001023154016.A2722@thyrsus.com> <20001023162118.B18005@kronos.cnri.reston.va.us> <001e01c03d34$d11bd5f0$3c6340d5@hagrid> <39F52C56.214B28A1@prescod.net>
Message-ID: <006001c03ddc$dda85570$3c6340d5@hagrid>

paul wrote:
> Perhaps this could be an opportunity to split Tcl and Tk more cleanly.
> People like Fredrick and his Perl/Ruby/... equivalents could get more
> deeply involved in setting direction.

I'm waiting for the Tcl/Tk developers to grow up -- they still
fear that any attempt to make it easier to use Tk from other
languages would be to "give up the crown jewels" :-(

</F>



From effbot@telia.com  Tue Oct 24 17:59:23 2000
From: effbot@telia.com (Fredrik Lundh)
Date: Tue, 24 Oct 2000 18:59:23 +0200
Subject: [Python-Dev] What to choose to replace Tkinter?
References: <14837.14407.954185.466011@buffalo.fnal.gov> <ECEPKNMJLHAPFFJHDOJBKEKIDOAA.MarkH@ActiveState.com> <14837.43273.24692.93965@buffalo.fnal.gov> <20001024114326.E13957@kronos.cnri.reston.va.us>
Message-ID: <005f01c03ddc$dd52bb60$3c6340d5@hagrid>

andrew wrote:
> Maybe the best approach is to follow /F's lead with Tkinter3000, and
> reimplement the Tkinter API on top of MFC / GTk+ / Qt.  (Er... that
> *is* what Tkinter3000 is, right?)

nope -- at least not initially.  the first two steps are a new
Tk glue layer, and an extension API that allows you to write
new widgets in pure Python.  also see:

    http://w1.132.telia.com/~u13208596/tkinter/index.htm

:::

I have plans for how to take the Tkinter API *and* the new
extension API beyond Tk, but let's save that for another day...

:::

> Can someone articulate why Tk should be replaced?

beats me ;-)

</F>



From cgw@fnal.gov  Tue Oct 24 17:54:35 2000
From: cgw@fnal.gov (Charles G Waldman)
Date: Tue, 24 Oct 2000 11:54:35 -0500 (CDT)
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: <20001024114326.E13957@kronos.cnri.reston.va.us>
References: <14837.14407.954185.466011@buffalo.fnal.gov>
 <ECEPKNMJLHAPFFJHDOJBKEKIDOAA.MarkH@ActiveState.com>
 <14837.43273.24692.93965@buffalo.fnal.gov>
 <20001024114326.E13957@kronos.cnri.reston.va.us>
Message-ID: <14837.48843.889458.137903@buffalo.fnal.gov>

Andrew Kuchling writes:
 > 
 > Careful... while people may try to port GTk+ to Windows, porting GNOME
 > is a different kettle of wax, because GNOME needs GTk+ but also
 > entails gnome-libs

But I was never seriously advocating Gtk+ on Windows.  This was just a
footnote.  I shouldn't have even mentioned the Windows Gtk+ port
because it just muddied the water.

The major point I was trying to make is that toolkits like Tkinter and
WxWindows, which try to delegate to the native widget sets whenever
possible, will succeed, and toolkits like Galaxy/AWT/Swing/XPFE, which
reimpliment all the widgets from scratch, are doomed to fail.  (IMO,
of course).

What I believe we need is a suitable abstraction which uses MFC on
MS-Win platforms and Gtk+ on Unix.  And which also doesn't, due to the
abstraction, take away too many features.  I don't know that much
about MFC, but for a simple example - Gtk+ offers an option for its
canvas widget to do all drawing in antialised mode (by the way, this
is slow but produces very nice looking results).  It would be a shame
if the abstraction layer didn't allow for things like this to be used.

 > This is why, every time this debate comes up, we
 > end up sticking with Tk; it may suck, but all the other systems don't
 > support everything...

Right.  FWIW, in my day-to-day work, if it has to run on MS-Win I use
Tkinter, and if MS-Win is not an issue I use PyGtk.  Fermilab will be
showing some network monitoring software at the Supercomputing 2000
conference next month, and it's mostly all stuff I whipped up a few
days using Tkinter.


From gmcm@hypernet.com  Tue Oct 24 18:14:42 2000
From: gmcm@hypernet.com (Gordon McMillan)
Date: Tue, 24 Oct 2000 13:14:42 -0400
Subject: [Python-Dev] Gradual migration
In-Reply-To: <39F5B4DC.C226D8F6@prescod.net>
Message-ID: <39F58B42.26855.490B8F73@localhost>

Paul Prescod wrote:
...
> .... It's
> not like we can somehow use C++ vtables without giving up Python's
> dynamicity. 

But that's exactly what COM does.

not-to-be-taken-as-an-endorsement-ly y'rs

- Gordon


From akuchlin@mems-exchange.org  Tue Oct 24 18:15:14 2000
From: akuchlin@mems-exchange.org (Andrew Kuchling)
Date: Tue, 24 Oct 2000 13:15:14 -0400
Subject: [Python-Dev] FYI: ajuba solutions (formerly scriptics) acquired by interwoven
In-Reply-To: <006001c03ddc$dda85570$3c6340d5@hagrid>; from effbot@telia.com on Tue, Oct 24, 2000 at 07:07:12PM +0200
References: <003201c03d18$f384a5c0$3c6340d5@hagrid> <20001023154016.A2722@thyrsus.com> <20001023162118.B18005@kronos.cnri.reston.va.us> <001e01c03d34$d11bd5f0$3c6340d5@hagrid> <39F52C56.214B28A1@prescod.net> <006001c03ddc$dda85570$3c6340d5@hagrid>
Message-ID: <20001024131514.B25025@kronos.cnri.reston.va.us>

On Tue, Oct 24, 2000 at 07:07:12PM +0200, Fredrik Lundh wrote:
>I'm waiting for the Tcl/Tk developers to grow up -- they still
>fear that any attempt to make it easier to use Tk from other
>languages would be to "give up the crown jewels" :-(

In the long run this has probably harmed Tk seriously.  If Tk was just
a widget set divorced from Tcl, then it might have been chosen as the
underlying widget set for GNOME or KDE, and then have benefited from
the development work done for those projects, such as the GNOME canvas
enhancements, which now can't be absorbed back into Tk without a lot
of effort to merge the two sets of code.  

--amk


From gvwilson@nevex.com  Tue Oct 24 18:58:59 2000
From: gvwilson@nevex.com (Greg Wilson)
Date: Tue, 24 Oct 2000 13:58:59 -0400 (EDT)
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: <200010241739.MAA16414@cj20424-a.reston1.va.home.com>
Message-ID: <Pine.LNX.4.10.10010241355360.6622-100000@akbar.nevex.com>

> > Greg Wilson:
> > I can articulate why I'm unhappy with the current set-up:
> > 1. Requiring Tcl is fragile.

> Guido van Rossum:
> For Windows, this problem has gone away in 1.6 and 2.0 -- we distribute and
> install our own Tcl/Tk binaries

OK.

> > Greg Wilson:
> > 2. (Lack of) native look and feel.  This is a complete show-stopper for
> >    many of the outfits I've dealt with (and not just with Python).

> Guido van Rossum:
> Really?  Are you sure that's not just general resistence against new things?

Well, my students' resistance to novelty is low enough that they're willing to
take a Python course :-).  This comes up every time I teach; no idea whether it
has any impact on the usability of completed applications, but I believe it
makes people less likely to choose Tkinter when starting development.

Thanks,
Greg



From guido@python.org  Tue Oct 24 20:04:55 2000
From: guido@python.org (Guido van Rossum)
Date: Tue, 24 Oct 2000 14:04:55 -0500
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: Your message of "Tue, 24 Oct 2000 13:58:59 -0400."
 <Pine.LNX.4.10.10010241355360.6622-100000@akbar.nevex.com>
References: <Pine.LNX.4.10.10010241355360.6622-100000@akbar.nevex.com>
Message-ID: <200010241904.OAA19165@cj20424-a.reston1.va.home.com>

> Well, my students' resistance to novelty is low enough that they're
> willing to take a Python course :-).  This comes up every time I
> teach; no idea whether it has any impact on the usability of
> completed applications, but I believe it makes people less likely to
> choose Tkinter when starting development.

Can you elaborate on the line of argument that you typically hear?
What do you say to dispel it?

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


From nas@arctrix.com  Tue Oct 24 12:56:11 2000
From: nas@arctrix.com (Neil Schemenauer)
Date: Tue, 24 Oct 2000 04:56:11 -0700
Subject: [Python-Dev] A small step to removing the type/class split
Message-ID: <20001024045611.B9993@glacier.fnational.com>

I've run into a problem with ExtensionClass which I believe can
only be fixed by modifying Python.  I will try to explain.

I have an ExtensionClass which defines __cmp__.  Depending on the
objects being compared, the __cmp__ method may never be called.
This is due to code in object.c that looks like this:

    if (PyInstance_Check(v) || PyInstance_Check(w)) {
        try to use use __cmp__ method
    }
    else {
        try number coerce and fall back on type name comparison
    }

Extension classes can never pass the PyInstance_Check predicate.
I've searched for all occurances of PyInstance_Check in the 2.0
source.  In many places that PyInstance_Check occurs a more
general "is this an instance-like type" check would seem to be
more suitable.

Here is my proposal:

  * Define a new type flag Py_TPFLAGS_INSTANCE.
  * Create a new predicate Py_IsInstance which checks for this
    flag.
  * Set this flag on PyInstance_Type.
  * Replace most occurances of PyInstance_Check with
    Py_IsInstance.

Extension types (like ExtensionClass) can then define the type
flag Py_TPLAGS_INSTANCE and be treated as an instance type by the
Python interpreter.  This should make it quite a bit easier to make
extension types behave like "real" classes.

Comments?

  Neil


From mal@lemburg.com  Tue Oct 24 20:37:30 2000
From: mal@lemburg.com (M.-A. Lemburg)
Date: Tue, 24 Oct 2000 21:37:30 +0200
Subject: [Python-Dev] Gradual migration
References: <39F52EF1.A201C6D9@prescod.net> <39F54C0F.25798309@lemburg.com> <39F5B4DC.C226D8F6@prescod.net>
Message-ID: <39F5E4FA.9FD6D35@lemburg.com>

Paul Prescod wrote:
> 
> "M.-A. Lemburg" wrote:
> >
> >...
> >
> > I think will simply be a consequence of doing a complete rewrite
> > of the interpreter for Py3K. AFAIR, the only truely feasable
> > solution would be doing the rewrite in a widely portable
> > subset of C++ and then managing classes at that level.
> 
> I disagree for a variety of reasons:
> 
>  * implementation language and Python inheritance semantics are almost
> completely distinct. After all, we have Python implementations in a
> variety of languages with minor incompatibilities. Python could have a
> proper type/class merging even if it were written in assembly language.
> So let's leave implementation language aside.

Hey, think of it as opportunity: we can reuse much of C++'s 
optimizations and the integration of Python and C++ applications
will get *much* easier.
 
A rewrite shouldn't scare anyone away -- much of the existing
code can be reused since only the Python C APIs of the various
types will have to be rewritten, not the logic behind the types.

Besides, Py3K will be a project which runs in parallel to the
2.x development (at least that's what I've read on some BeOpen
webpage), so there's really not much to worry about wrt to
breakage, etc. People will be able to test-drive Py3K while
using the 2.x series.

>  * there is a hell of a lot we can do to make the type/class split less
> visible without a major rewrite. For instance, lists could have a
> __getitem__ method so that they "act like" instances. Instances could
> return their methods in a dir() so that they "act like" built-in
> objects. So there is no reason to wait for a complete rewrite to start
> on this path.

Right. I didn't want to say that things cannot be done prior
to the rewrite, only that a rewrite will give us much more
options that we currently have.

>  * It may even be the case that we can get from here to complete merged
> type/class semantics WITHOUT a rewrite. If a mad genious had not written
> stackless Python I would have sworn up and down that stackless Python
> would require a Python rewrite. It didn't. If another slightly less mad
> genious had not integrated ints and longs I would never have believed it
> possible without another rewrite. Someone needs to do an analysis of
> what it takes to merge types and classes and *demonstrate* that it
> requires a rewrite rather than *asserting* that it requires a rewrite.
>
> In other words, let's stop sprinkling the "major rewrite" pixie dust on
> hard problems and instead decide where we want to go and how we want to
> get there!

See above.
 
> > Moving to a common and very low-level strategy for classes
> > will allows us to put even the most basic types (strings and
> > numbers) into an inheritence tree.
> 
> I don't know what you mean by a "low-level strategy" for classes. It's
> not like we can somehow use C++ vtables without giving up Python's
> dynamicity. Python's class handling is about as low-level as it can get
> in my humble opinion.

With "low-level" I meant trying to build Python classes and
instances on top of a very thin layer on top of C++ classes,
e.g. all slots could be implemented using true C++ methods with
additional logic to override them using dynamically bound
Python method objects.

> > Differences like the
> > ones between Unicode and 8-bit strings would then flesh
> > out as two different subclasses of a generic string type which
> > again is based on a generic sequence type.
> 
> Of course that's where we want to go but it doesn't avoid the backwards
> compatibility problems.

Huh ? I was talking about clear design... not ways to avoid
b/w compatibility. Merging Unicode and strings will hurt one
way or another. This is simply a consequence of using strings
as binary containers where Unicode is meant for text only use.

> We can do this today using proxying.

Could you explain this ?
 
> > The same could be done for dictionaries: special ones for
> > just string keys, case insensitive lookups, etc. could all
> > be subclasses of a generic mapping class.
> 
> We can easily do this today.

No we can't: Python's use of pointer compares to find out
which type it is dealing with prevent this.
 
> > Dito for numbers (and division strategies).
> 
> There's no way I'm going to let you get away with that little sleight of
> hand. How is inheritance holy water going to allow us to change the
> semantics of:
> 
> 5/2
> 
> without breaking code??
> 
> The same goes for
> 
> a.b = 5
> 
> versus
> 
> a.B = 5
> 
> C++ does not help. Inheritance does not help. Pluggable compilers do not
> help. We *will* break code. We just need to decide whether to do it in a
> thoughtful way that gives people a chance to migrate or put off
> decisions until the last possible moment and then spring it on them with
> no between-version upgrade path.

Just tell Python to use the correct class for what the
code was written for (and this could be done by plugging in
a 2.0 compiler). The instances of those classes would still work
together with other semantics by virtue of exposing the same
interface, yet the internals would work differently, e.g.
a module using case insensitive lookup would be compiled using
case insensitive dictionaries as namespaces.

> > By following this principle there won't be all that much
> > breakage, since the old functionality will still be around,
> > only the defaults will have changed.
> 
> When you change defaults you break code. Keeping the old functionality
> around is barely helpful.  Nobody has EVER proposed a change to Python
> where something that was previously possible is now made impossible. So
> whatever our strategy, the PROBLEM is changing defaults. The solution is
> telling people what defaults are changing in what timeline and
> discouraging them from depending on the old defaults.

All true. I was just referring to the possibility of keeping
the old semantics around in case some module relies on them.
In this ideal world, a simple "define pythonlevel=2.0"
would suffice to make the old module work with Py3k.
 
> > Add to this pluggable compilers and ceval loops, plus a nice
> > way of configuring the lot on a per-module basis and you're
> > set. (Ok, it's a fluffy clouds image, but you get the picture ;-)
> 
> Sounds mythical. I'm trying to take it out of the realm of fluffy clouds
> and bring it into the world that people can plan their businesses and
> coding strategies around.

Hmm, wasn't Py3k meant as sandbox for new experiments ? 
The 2.x series is for doing business with, IMHO at least. 

At the current dev speed we'll have plenty of time to get Py3k
rock solid. Then we can add all the backward compatibility layers
we want to it. If the design is a good, adding these layers
won't pose much of a problem.

Why spoil all the fun when we haven't even started thinking
about all the possibilities we could use to make Py3k a
success ?

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/


From mal@lemburg.com  Tue Oct 24 20:54:39 2000
From: mal@lemburg.com (M.-A. Lemburg)
Date: Tue, 24 Oct 2000 21:54:39 +0200
Subject: [Python-Dev] A small step to removing the type/class split
References: <20001024045611.B9993@glacier.fnational.com>
Message-ID: <39F5E8FF.5F18C71E@lemburg.com>

Neil Schemenauer wrote:
> 
> I've run into a problem with ExtensionClass which I believe can
> only be fixed by modifying Python.  I will try to explain.
> 
> I have an ExtensionClass which defines __cmp__.  Depending on the
> objects being compared, the __cmp__ method may never be called.
> This is due to code in object.c that looks like this:
> 
>     if (PyInstance_Check(v) || PyInstance_Check(w)) {
>         try to use use __cmp__ method
>     }
>     else {
>         try number coerce and fall back on type name comparison
>     }
> 
> Extension classes can never pass the PyInstance_Check predicate.
> I've searched for all occurances of PyInstance_Check in the 2.0
> source.  In many places that PyInstance_Check occurs a more
> general "is this an instance-like type" check would seem to be
> more suitable.
> 
> Here is my proposal:
> 
>   * Define a new type flag Py_TPFLAGS_INSTANCE.
>   * Create a new predicate Py_IsInstance which checks for this
>     flag.
>   * Set this flag on PyInstance_Type.
>   * Replace most occurances of PyInstance_Check with
>     Py_IsInstance.
> 
> Extension types (like ExtensionClass) can then define the type
> flag Py_TPLAGS_INSTANCE and be treated as an instance type by the
> Python interpreter.  This should make it quite a bit easier to make
> extension types behave like "real" classes.
> 
> Comments?

Sounds fine, except that the "isinstance()" behaviour would
have to be defined somewhere / somehow... a mapping of slots
to __special_methods__ would be a good start.

BTW, mxProxy does some of this mapping already... you may want to 
have a look.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/


From gmcm@hypernet.com  Tue Oct 24 21:01:25 2000
From: gmcm@hypernet.com (Gordon McMillan)
Date: Tue, 24 Oct 2000 16:01:25 -0400
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: <Pine.LNX.4.10.10010241355360.6622-100000@akbar.nevex.com>
References: <200010241739.MAA16414@cj20424-a.reston1.va.home.com>
Message-ID: <39F5B255.22108.49A43169@localhost>

Greg Wilson:
> > > 2. (Lack of) native look and feel.  This is a complete show-stopper for
> > >    many of the outfits I've dealt with (and not just with Python).
> 
> > Guido van Rossum:
> > Really?  Are you sure that's not just general resistence against new things?
> 
> Well, my students' resistance to novelty is low enough that they're willing to
> take a Python course :-).  This comes up every time I teach; no idea whether it
> has any impact on the usability of completed applications, but I believe it
> makes people less likely to choose Tkinter when starting development.

As I see it, Tk, like SQL, has the property that it's dead easy 
to get something crappy running, but it takes a real expert 
(like /F) to make it good. With wxPython, though, it's easy (if 
somewhat tedious) to get something good - at least as far as 
normal "forms" style GUIs.

I'm not taking sides - I dabble in both and will never be an 
expert at either. But for clients using Windows, I use 
wxPython because it's indistinguishable from native Win32.

(BTW, MFC is lagging further and further behind native Win32 -
 I believe MS considers it "legacy".)

- Gordon


From barry@wooz.org  Tue Oct 24 21:06:23 2000
From: barry@wooz.org (Barry A. Warsaw)
Date: Tue, 24 Oct 2000 16:06:23 -0400 (EDT)
Subject: [Python-Dev] A small step to removing the type/class split
References: <20001024045611.B9993@glacier.fnational.com>
Message-ID: <14837.60351.887533.801888@anthem.concentric.net>

>>>>> "NS" == Neil Schemenauer <nas@arctrix.com> writes:

    NS> I've run into a problem with ExtensionClass which I believe
    NS> can only be fixed by modifying Python.  I will try to explain.

    NS> I have an ExtensionClass which defines __cmp__.  Depending on
    NS> the objects being compared, the __cmp__ method may never be
    NS> called.  This is due to code in object.c that looks like this:

    |     if (PyInstance_Check(v) || PyInstance_Check(w)) {
    |         try to use use __cmp__ method
    |     }
    |     else {
    |         try number coerce and fall back on type name comparison
    |     }

I hit a similar wall when I tried (a long time ago) to take a boolean
class I'd written in Python and make it a built-in type.  The problem
was that in Python I could compare a Boolean instance against any
other object for truth equivalence, but because of this hack, I
couldn't do the same with the built-in type.

    |   * Define a new type flag Py_TPFLAGS_INSTANCE.
    |   * Create a new predicate Py_IsInstance which checks for this
    |     flag.
    |   * Set this flag on PyInstance_Type.
    |   * Replace most occurances of PyInstance_Check with
    |     Py_IsInstance.

    NS> Extension types (like ExtensionClass) can then define the type
    NS> flag Py_TPLAGS_INSTANCE and be treated as an instance type by
    NS> the Python interpreter.  This should make it quite a bit
    NS> easier to make extension types behave like "real" classes.

I'm not sure how well this addresses what I ran into.  Would
PyBooleanObject then have to have it's Py_TPFLAGS_INSTANCE flag set?
Does that actually make sense?  How does this interact with the rich
comparisons idea?  Seems like this is a hack that doesn't quite get at
the heart of the matter, worthwhile as it may be given the current
implementation.

-Barry


From barry@wooz.org  Tue Oct 24 21:11:54 2000
From: barry@wooz.org (Barry A. Warsaw)
Date: Tue, 24 Oct 2000 16:11:54 -0400 (EDT)
Subject: [Python-Dev] getting at the current frame
Message-ID: <14837.60682.437334.797392@anthem.concentric.net>

I've been playing around with ideas for internationalizing Mailman,
which naturally <wink> leads to string interpolation.  To see why,
think about making the following code translatable:

    def trade(yours, mine):
	print 'if you give me %s, i will give you %s' % (yours, mine)

Because the order of the interpolated values may change in the
translated string, you really have to do something like:

    def trade(yours, mine):
	print 'if you give me %(yours)s, i will give you %(mine)s' % {
	    'yours': yours,
	    'mine' : mine,
	    }

which actually will look something like this in real code:

    def trade(yours, mine):
	print _('if you give me %(yours)s, i will give you %(mine)s') % {
	    'yours': yours,
	    'mine' : mine,
	    }

The string wrapped in _() is what gets translated here.

Okay, we all know that's a pain, right?  Lots of people have proposed
solutions.  I've looked briefly at !?ng's Itpl.py, but I think it
probably does too much by adding evaluation.

I can define _() to make the problem somewhat more convenient:

    def _(s):
	try:
	    raise Exception
	except Exception:
	    frame = sys.exc_info()[2].tb_frame.f_back
	d = frame.f_globals.copy()
	d.update(frame.f_locals())
	return the_translation_of(s) % d

Now I can write the code like this:

    def trade(yours, mine):
	print _('if you give me %(yours)s, i will give you %(mine)s')

All well and good and doable in Python today, except getting the
current frame with the exception raising trick is slooow.  A simple
proposed addition to the sys module can improve the performance by
about 8x:

    def _(s):
        frame = sys.getcaller(1)
	d = frame.f_globals.copy()
	d.update(frame.f_locals())
	return the_translation_of(s) % d

The implementation of sys.getcaller() is given in the below patch.
Comments?  I think this particular addition is too small for a PEP,
although ?!ng still owns PEP 215 (which needs filling in).

-Barry

-------------------- snip snip --------------------
Index: sysmodule.c
===================================================================
RCS file: /cvsroot/python/python/dist/src/Python/sysmodule.c,v
retrieving revision 2.78
diff -u -r2.78 sysmodule.c
--- sysmodule.c	2000/09/01 23:29:28	2.78
+++ sysmodule.c	2000/10/24 17:50:30
@@ -15,6 +15,8 @@
 */
 
 #include "Python.h"
+#include "compile.h"
+#include "frameobject.h"
 
 #include "osdefs.h"
 
@@ -284,6 +286,38 @@
 }
 #endif
 
+static char getcaller_doc[] =
+"getcaller([depth]) -> frameobject\n\
+\n\
+By default, return the frame object at the top of the call stack.  If an\n\
+integer depth is given, return the frame object that many calls below the\n\
+top of the stack.  If that is deeper than the call stack, a ValueError is\n\
+raised.";
+
+
+static PyObject *
+sys_getcaller(PyObject *self, PyObject *args)
+{
+	PyFrameObject *f = PyThreadState_Get()->frame;
+	int depth = -1;
+
+	if (!PyArg_ParseTuple(args, "|i:getcaller", &depth))
+		return NULL;
+
+	while (depth > 0 && f != NULL) {
+		f = f->f_back;
+		--depth;
+	}
+	if (f == NULL) {
+		PyErr_SetString(PyExc_ValueError,
+				"call stack is not deep enough");
+		return NULL;
+	}
+	Py_INCREF(f);
+	return (PyObject*)f;
+}
+
+
 #ifdef Py_TRACE_REFS
 /* Defined in objects.c because it uses static globals if that file */
 extern PyObject *_Py_GetObjects(PyObject *, PyObject *);
@@ -313,6 +347,7 @@
 	{"getrefcount",	sys_getrefcount, 1, getrefcount_doc},
 	{"getrecursionlimit", sys_getrecursionlimit, 1,
 	 getrecursionlimit_doc},
+	{"getcaller", sys_getcaller, 1, getcaller_doc},
 #ifdef USE_MALLOPT
 	{"mdebug",	sys_mdebug, 1},
 #endif


From nas@arctrix.com  Tue Oct 24 14:45:35 2000
From: nas@arctrix.com (Neil Schemenauer)
Date: Tue, 24 Oct 2000 06:45:35 -0700
Subject: [Python-Dev] A small step to removing the type/class split
In-Reply-To: <14837.60351.887533.801888@anthem.concentric.net>; from barry@wooz.org on Tue, Oct 24, 2000 at 04:06:23PM -0400
References: <20001024045611.B9993@glacier.fnational.com> <14837.60351.887533.801888@anthem.concentric.net>
Message-ID: <20001024064535.A10253@glacier.fnational.com>

On Tue, Oct 24, 2000 at 04:06:23PM -0400, Barry A. Warsaw wrote:

[on Py_TPLAGS_INSTANCE]
> I'm not sure how well this addresses what I ran into [with a
> boolean extension type].  Would PyBooleanObject then have to
> have it's Py_TPFLAGS_INSTANCE flag set?  Does that actually
> make sense?

I think it would address your problem but I don't know if the
name of the flag makes sense.  Code around PyInstance_Check()
usually looks like this:

    if (PyInstance_Check(obj)) {
        PyObject *foo = PyObject_GetAttrString(obj, "__foo__");
        ...
    }
    else {
        ...
    }

There is not a lot of code that assumes (obj->ob_type ==
PyInstance_Type) after a PyInstance_Check().  That's encouraging.

> How does this interact with the rich comparisons idea?

I don't know.  I think I am trying to a address a deeper problem
here.

> Seems like this is a hack that doesn't quite get at the heart
> of the matter, worthwhile as it may be given the current
> implementation.

Yes, I have that feeling as well.  More deep thinking is probably
required. :)

  Neil



From mal@lemburg.com  Tue Oct 24 21:45:28 2000
From: mal@lemburg.com (M.-A. Lemburg)
Date: Tue, 24 Oct 2000 22:45:28 +0200
Subject: [Python-Dev] getting at the current frame
References: <14837.60682.437334.797392@anthem.concentric.net>
Message-ID: <39F5F4E8.1188E1E0@lemburg.com>

"Barry A. Warsaw" wrote:
> [...]
> All well and good and doable in Python today, except getting the
> current frame with the exception raising trick is slooow.  A simple
> proposed addition to the sys module can improve the performance by
> about 8x:
> 
>     def _(s):
>         frame = sys.getcaller(1)
>         d = frame.f_globals.copy()
>         d.update(frame.f_locals())
>         return the_translation_of(s) % d
> 
> The implementation of sys.getcaller() is given in the below patch.
> Comments?  I think this particular addition is too small for a PEP,
> although ?!ng still owns PEP 215 (which needs filling in).

+1. 

I have a similar function in mxTools. I would use a different
name though... something like "sys.getframe()".

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/


From guido@python.org  Tue Oct 24 22:50:32 2000
From: guido@python.org (Guido van Rossum)
Date: Tue, 24 Oct 2000 16:50:32 -0500
Subject: [Python-Dev] A small step to removing the type/class split
In-Reply-To: Your message of "Tue, 24 Oct 2000 04:56:11 MST."
 <20001024045611.B9993@glacier.fnational.com>
References: <20001024045611.B9993@glacier.fnational.com>
Message-ID: <200010242150.QAA19518@cj20424-a.reston1.va.home.com>

> I've run into a problem with ExtensionClass which I believe can
> only be fixed by modifying Python.  I will try to explain.
> 
> I have an ExtensionClass which defines __cmp__.  Depending on the
> objects being compared, the __cmp__ method may never be called.
> This is due to code in object.c that looks like this:
> 
>     if (PyInstance_Check(v) || PyInstance_Check(w)) {
>         try to use use __cmp__ method
>     }
>     else {
>         try number coerce and fall back on type name comparison
>     }
> 
> Extension classes can never pass the PyInstance_Check predicate.
> I've searched for all occurances of PyInstance_Check in the 2.0
> source.  In many places that PyInstance_Check occurs a more
> general "is this an instance-like type" check would seem to be
> more suitable.
> 
> Here is my proposal:
> 
>   * Define a new type flag Py_TPFLAGS_INSTANCE.
>   * Create a new predicate Py_IsInstance which checks for this
>     flag.
>   * Set this flag on PyInstance_Type.
>   * Replace most occurances of PyInstance_Check with
>     Py_IsInstance.
> 
> Extension types (like ExtensionClass) can then define the type
> flag Py_TPLAGS_INSTANCE and be treated as an instance type by the
> Python interpreter.  This should make it quite a bit easier to make
> extension types behave like "real" classes.
> 
> Comments?

Good analysis of a problem -- but I disagree on the solution.

Rather than formalizing the exceptions made for instances, we should
work on eradicating the differences between classes and types.  I
believe that the plans for rich comparisons would or could also take
care of this.  I hope I'll have more time soon to explore this.

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


From barry@wooz.org  Tue Oct 24 21:49:04 2000
From: barry@wooz.org (barry@wooz.org)
Date: Tue, 24 Oct 2000 16:49:04 -0400 (EDT)
Subject: [Python-Dev] getting at the current frame
References: <14837.60682.437334.797392@anthem.concentric.net>
 <39F5F4E8.1188E1E0@lemburg.com>
Message-ID: <14837.62912.897422.392307@anthem.concentric.net>

>>>>> "M" == M  <mal@lemburg.com> writes:

    M> I have a similar function in mxTools. I would use a different
    M> name though... something like "sys.getframe()".

Works for me.

Thanks,
-Barry


From guido@python.org  Tue Oct 24 23:16:00 2000
From: guido@python.org (Guido van Rossum)
Date: Tue, 24 Oct 2000 17:16:00 -0500
Subject: [Python-Dev] Re: getting at the current frame
In-Reply-To: Your message of "Tue, 24 Oct 2000 17:04:11 -0400."
 <14837.63819.667508.794728@anthem.concentric.net>
References: <14837.52425.84457.36757@anthem.concentric.net> <14837.53353.79747.421223@cj42289-a.reston1.va.home.com> <14837.60401.939234.320786@anthem.concentric.net> <200010242155.QAA19570@cj20424-a.reston1.va.home.com>
 <14837.63819.667508.794728@anthem.concentric.net>
Message-ID: <200010242216.RAA19692@cj20424-a.reston1.va.home.com>

>     GvR> Agreed.  I think it's good to have the functionality
>     GvR> available, but it's also good to make it *real* clear not to
>     GvR> mess with it unless you really know what you're doing.  Maybe
>     GvR> it should be in a separate module or at least have a leading
>     GvR> _underscore.
> 
> I think you're fairly safe from mischief since the only writable
> attributes of a frame object are f_trace, f_exc_type, f_exc_value, and
> f_exc_traceback.  The same caveats about f_globals and f_locals apply
> as with the dicts returned by locals() and globals().

It's not so much that it's easy to do damage with.  I have a
philosophical problem with making this a feature that people can use
whenever they feel like.  It's a messy feature and its use should
limited as an implementation aid for language features like variable
substitution.

The other, perhaps more major, problem with this it is that you can't
easily wrap functions that use it in other functions.  Normally, if
there's a function foo(arg) that does something, I can write a
function wrapfoo(arg) that does something else, then calls foo(arg),
and then does another thing.  But if foo() uses getframe(), that's not
so easy: the call to foo() in wrapfoo() will access wrapfoo()'s frame.

A way around this would be to implement foo as a call to (e.g.)
_foo(arg, frame), and define foo(arg) as _foo(arg, sys.getframe()).
Then _wrapfoo(arg, frame) could be defined as a wrapper around
_foo(arg, frame) and wrapfoo(arg) as _wrapfoo(arg, sys.getframe()).

This is another reason to be very selective in the use of getframe().

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


From nas@arctrix.com  Tue Oct 24 15:37:12 2000
From: nas@arctrix.com (Neil Schemenauer)
Date: Tue, 24 Oct 2000 07:37:12 -0700
Subject: [Python-Dev] A small step to removing the type/class split
In-Reply-To: <200010242150.QAA19518@cj20424-a.reston1.va.home.com>; from guido@python.org on Tue, Oct 24, 2000 at 04:50:32PM -0500
References: <20001024045611.B9993@glacier.fnational.com> <200010242150.QAA19518@cj20424-a.reston1.va.home.com>
Message-ID: <20001024073712.A10539@glacier.fnational.com>

On Tue, Oct 24, 2000 at 04:50:32PM -0500, Guido van Rossum wrote:
> Rather than formalizing the exceptions made for instances, we
> should work on eradicating the differences between classes and
> types.

Yes, I see this now.  Those PyInstance_Check() calls should
really go away.  Instead, the type should be responsible for
providing different behavior.

> I believe that the plans for rich comparisons would or could
> also take care of this.

I've just briefly looked at the proposal.  It consists of two
parts.  One is splitting __cmp__ into __gt__, __lt__, etc.  That
is a separate issue to the one we are dicussing.  The other part
is directly related.  In order for types to define their own
comparison behavior, it proposes that types have an optional
pointer to a rich comparison function in the type structure.  I
think this is the right idea but it doesn't go far enough.  Every
operation should be implementable by the type.  Code like:

    if (PyString_Check(obj)) {
        something
    }
    else if (PyInstance_Check(obj)) {
        something else
    }
    ...

should disappear unless it is need for performance reasons.  I
think we are close to achieving this goal.  I'll try to come up
with a proposal.

  Neil


From barry@wooz.org  Tue Oct 24 22:34:54 2000
From: barry@wooz.org (barry@wooz.org)
Date: Tue, 24 Oct 2000 17:34:54 -0400 (EDT)
Subject: [Python-Dev] Re: getting at the current frame
References: <14837.52425.84457.36757@anthem.concentric.net>
 <14837.53353.79747.421223@cj42289-a.reston1.va.home.com>
 <14837.60401.939234.320786@anthem.concentric.net>
 <200010242155.QAA19570@cj20424-a.reston1.va.home.com>
 <14837.63819.667508.794728@anthem.concentric.net>
 <200010242216.RAA19692@cj20424-a.reston1.va.home.com>
Message-ID: <14838.126.77589.541148@anthem.concentric.net>

>>>>> "GvR" == Guido van Rossum <guido@python.org> writes:

    GvR> The other, perhaps more major, problem with this it is that
    GvR> you can't easily wrap functions that use it in other
    GvR> functions.  Normally, if there's a function foo(arg) that
    GvR> does something, I can write a function wrapfoo(arg) that does
    GvR> something else, then calls foo(arg), and then does another
    GvR> thing.  But if foo() uses getframe(), that's not so easy: the
    GvR> call to foo() in wrapfoo() will access wrapfoo()'s frame.

    GvR> A way around this would be to implement foo as a call to
    GvR> (e.g.)  _foo(arg, frame), and define foo(arg) as _foo(arg,
    GvR> sys.getframe()).  Then _wrapfoo(arg, frame) could be defined
    GvR> as a wrapper around _foo(arg, frame) and wrapfoo(arg) as
    GvR> _wrapfoo(arg, sys.getframe()).

Darn good point.  So where could we put it?  It's a useful
introspection device.  If it goes in a separate module, should that
perhaps be called `reflection'?  Or maybe `runtime'?  Or maybe
"sys._getframe()" is good enough.

-Barry


From guido@python.org  Wed Oct 25 00:13:43 2000
From: guido@python.org (Guido van Rossum)
Date: Tue, 24 Oct 2000 18:13:43 -0500
Subject: [Python-Dev] Re: getting at the current frame
In-Reply-To: Your message of "Tue, 24 Oct 2000 17:34:54 -0400."
 <14838.126.77589.541148@anthem.concentric.net>
References: <14837.52425.84457.36757@anthem.concentric.net> <14837.53353.79747.421223@cj42289-a.reston1.va.home.com> <14837.60401.939234.320786@anthem.concentric.net> <200010242155.QAA19570@cj20424-a.reston1.va.home.com> <14837.63819.667508.794728@anthem.concentric.net> <200010242216.RAA19692@cj20424-a.reston1.va.home.com>
 <14838.126.77589.541148@anthem.concentric.net>
Message-ID: <200010242313.SAA19938@cj20424-a.reston1.va.home.com>

> Darn good point.  So where could we put it?  It's a useful
> introspection device.  If it goes in a separate module, should that
> perhaps be called `reflection'?  Or maybe `runtime'?  Or maybe
> "sys._getframe()" is good enough.

sys._getframe() is good enough.

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


From DavidA@ActiveState.com  Wed Oct 25 00:08:28 2000
From: DavidA@ActiveState.com (David Ascher)
Date: Tue, 24 Oct 2000 16:08:28 -0700 (Pacific Daylight Time)
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: <14837.43273.24692.93965@buffalo.fnal.gov>
Message-ID: <Pine.WNT.4.21.0010241517480.1584-100000@loom>

> Back in my former life, when I was still worrying about Windows, the
> company I worked for bought into a commerical x-platform GUI toolkit
> called Galaxy (I mentioned this earlier).  Galaxy re-implemented all
> the native widgets, kind of like XPFE does.  One issue with this was
> that MS seemed to change something about the widgets in every release
> - e.g. the Galaxy filechooser looked like Windows 3.1, then Win95 came
> out and Galaxy had to play catch-up.  Once Galaxy had the Win95 LAF,
> Win98 came out.  Now I hear there's something called Windows ME.  Have
> they changed the look-and-feel again?  Seems to me like all the
> widget-reimplementors are doomed to playing eternal catch-up.

Back in a former life of _mine_, I was one of two people who understood
the architecture of Neuron Data's Open Interface Toolkit.  It used the
same strategy.  Not sure what that has to do with Python, though it was
a very fun project.  It was also fun to turn on the Mac 'theme' on a
Decwindows box (we're talking 1989 or so =).

The funniest story about that job involves Cray and black and white
monitors, but that's a story for another time, another place.

--da



From greg@cosc.canterbury.ac.nz  Wed Oct 25 00:18:59 2000
From: greg@cosc.canterbury.ac.nz (Greg Ewing)
Date: Wed, 25 Oct 2000 12:18:59 +1300 (NZDT)
Subject: [Python-Dev] Why not revive stdwin?
In-Reply-To: <20001023162118.B18005@kronos.cnri.reston.va.us>
Message-ID: <200010242318.MAA28238@s454.cosc.canterbury.ac.nz>

Andrew Kuchling <akuchlin@mems-exchange.org>:

> It seems to me that supporting MacOS is the big problem for
> cross-platform GUIs.

It appears that we can't rely on anyone else to provide and
support a GUI properly across all three platforms. If we
want one, it looks like we'll have to do it ourselves.

How about reviving and building upon stdwin? I quite liked
stdwin, despite its limitations, because it was small and simple,
and it worked on both Mac and Unix.

Greg Ewing, Computer Science Dept, +--------------------------------------+
University of Canterbury,	   | A citizen of NewZealandCorp, a	  |
Christchurch, New Zealand	   | wholly-owned subsidiary of USA Inc.  |
greg@cosc.canterbury.ac.nz	   +--------------------------------------+


From est@hyperreal.org  Tue Oct 24 22:58:43 2000
From: est@hyperreal.org (est@hyperreal.org)
Date: Tue, 24 Oct 2000 14:58:43 -0700 (PDT)
Subject: [Python-Dev] Re: getting at the current frame
In-Reply-To: <14838.126.77589.541148@anthem.concentric.net> from "barry@wooz.org"
 at "Oct 24, 2000 05:34:54 pm"
Message-ID: <20001024215843.7507.qmail@hyperreal.org>

barry@wooz.org discourseth:
> 
> Darn good point.  So where could we put it?  It's a useful
> introspection device.  If it goes in a separate module, should that
> perhaps be called `reflection'?  Or maybe `runtime'?  Or maybe
> "sys._getframe()" is good enough.

Hmm..I'd think `reification' instead of `reflection'.  My
understanding was that reification involves taking an implicit
language entity and making it an expressed value (e.g., getframe() or
call_with_current_continuation()) while reflection goes in the
opposite direction (e.g., eval()).

pedantically,

e


From greg@cosc.canterbury.ac.nz  Wed Oct 25 02:14:52 2000
From: greg@cosc.canterbury.ac.nz (Greg Ewing)
Date: Wed, 25 Oct 2000 14:14:52 +1300 (NZDT)
Subject: [Python-Dev] A small step to removing the type/class split
In-Reply-To: <20001024073712.A10539@glacier.fnational.com>
Message-ID: <200010250114.OAA28255@s454.cosc.canterbury.ac.nz>

Neil Schemenauer <nas@arctrix.com>:

> Those PyInstance_Check() calls should really go away. Instead, the
> type should be responsible for providing different behavior.

Yes, that's the crux of the problem, I think.

Another place where this is a nuisance is where it
assumes that if x has any tp_as_sequence slots and y
has any tp_as_number slots, then x*y is a sequence
replication operation.

Greg Ewing, Computer Science Dept, +--------------------------------------+
University of Canterbury,	   | A citizen of NewZealandCorp, a	  |
Christchurch, New Zealand	   | wholly-owned subsidiary of USA Inc.  |
greg@cosc.canterbury.ac.nz	   +--------------------------------------+



From esr@thyrsus.com  Wed Oct 25 05:56:27 2000
From: esr@thyrsus.com (Eric S. Raymond)
Date: Tue, 24 Oct 2000 21:56:27 -0700
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: <005f01c03ddc$dd52bb60$3c6340d5@hagrid>; from effbot@telia.com on Tue, Oct 24, 2000 at 06:59:23PM +0200
References: <14837.14407.954185.466011@buffalo.fnal.gov> <ECEPKNMJLHAPFFJHDOJBKEKIDOAA.MarkH@ActiveState.com> <14837.43273.24692.93965@buffalo.fnal.gov> <20001024114326.E13957@kronos.cnri.reston.va.us> <005f01c03ddc$dd52bb60$3c6340d5@hagrid>
Message-ID: <20001024215627.B1147@thyrsus.com>

Fredrik Lundh <effbot@telia.com>:
> > Can someone articulate why Tk should be replaced?
> 
> beats me ;-)

My main reason is that Tcl is in trouble, and I fear Tcl/Tk may become
effectively unmaintained in the foreseeable future.
-- 
		<a href="http:///~esr/">Eric S. Raymond</a>

Rapists just *love* unarmed women.  And the politicians who disarm them.


From esr@thyrsus.com  Wed Oct 25 06:29:17 2000
From: esr@thyrsus.com (Eric S. Raymond)
Date: Tue, 24 Oct 2000 22:29:17 -0700
Subject: [Python-Dev] Why not revive stdwin?
In-Reply-To: <200010242318.MAA28238@s454.cosc.canterbury.ac.nz>; from greg@cosc.canterbury.ac.nz on Wed, Oct 25, 2000 at 12:18:59PM +1300
References: <20001023162118.B18005@kronos.cnri.reston.va.us> <200010242318.MAA28238@s454.cosc.canterbury.ac.nz>
Message-ID: <20001024222917.I1147@thyrsus.com>

Greg Ewing <greg@cosc.canterbury.ac.nz>:
> It appears that we can't rely on anyone else to provide and
> support a GUI properly across all three platforms. If we
> want one, it looks like we'll have to do it ourselves.

I fear this is much too big a job to be practical -- not just in the
additional code but the downstream maintainance.
-- 
		<a href="http:///~esr/">Eric S. Raymond</a>

"I hold it, that a little rebellion, now and then, is a good thing, and as 
necessary in the political world as storms in the physical."
	-- Thomas Jefferson, Letter to James Madison, January 30, 1787


From barry@wooz.org  Wed Oct 25 04:11:54 2000
From: barry@wooz.org (Barry A. Warsaw)
Date: Tue, 24 Oct 2000 23:11:54 -0400 (EDT)
Subject: [Python-Dev] Re: getting at the current frame
References: <14837.52425.84457.36757@anthem.concentric.net>
 <14837.53353.79747.421223@cj42289-a.reston1.va.home.com>
 <14837.60401.939234.320786@anthem.concentric.net>
 <200010242155.QAA19570@cj20424-a.reston1.va.home.com>
 <14837.63819.667508.794728@anthem.concentric.net>
 <200010242216.RAA19692@cj20424-a.reston1.va.home.com>
 <14838.126.77589.541148@anthem.concentric.net>
 <200010242313.SAA19938@cj20424-a.reston1.va.home.com>
Message-ID: <14838.20346.451094.231019@anthem.concentric.net>

>>>>> "GvR" == Guido van Rossum <guido@python.org> writes:

    GvR> sys._getframe() is good enough.

Cool, I'll upload the patch to SF.

-Barry


From barry@wooz.org  Wed Oct 25 04:44:10 2000
From: barry@wooz.org (Barry A. Warsaw)
Date: Tue, 24 Oct 2000 23:44:10 -0400 (EDT)
Subject: [Python-Dev] Re: getting at the current frame
References: <14837.52425.84457.36757@anthem.concentric.net>
 <14837.53353.79747.421223@cj42289-a.reston1.va.home.com>
 <14837.60401.939234.320786@anthem.concentric.net>
 <200010242155.QAA19570@cj20424-a.reston1.va.home.com>
 <14837.63819.667508.794728@anthem.concentric.net>
 <200010242216.RAA19692@cj20424-a.reston1.va.home.com>
 <14838.126.77589.541148@anthem.concentric.net>
 <200010242313.SAA19938@cj20424-a.reston1.va.home.com>
 <14838.20346.451094.231019@anthem.concentric.net>
Message-ID: <14838.22282.676715.200546@anthem.concentric.net>

>>>>> "BAW" == Barry A Warsaw <barry@wooz.org> writes:

>>>>> "GvR" == Guido van Rossum <guido@python.org> writes:

    GvR> sys._getframe() is good enough.

    BAW> Cool, I'll upload the patch to SF.

Patch #102106

http://sourceforge.net/patch/?func=detailpatch&patch_id=102106&group_id=5470

(includes doc patch)

-Barry


From tim_one@email.msn.com  Wed Oct 25 08:10:36 2000
From: tim_one@email.msn.com (Tim Peters)
Date: Wed, 25 Oct 2000 03:10:36 -0400
Subject: [Python-Dev] Gradual migration
In-Reply-To: <39F54C0F.25798309@lemburg.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCMELHHMAA.tim_one@email.msn.com>

[MAL]
> ...
> I think will simply be a consequence of doing a complete rewrite
> of the interpreter for Py3K.

Not just to be my usual self <wink>, but I do see a from-scratch rewrite as
being less likely as the years go by.  There's nothing I know of in Guido's
plans that can't be done incrementally instead -- and if he doesn't either,
selling a total- rewrite project to an employer is probably impossible.

The most successful projects I've seen and been on *did* rewrite all the
code routinely, but one subsystem at a time.  This happens when you're
tempted to add a hack, realize it wouldn't be needed if an entire area were
reworked, and mgmt is bright enough to realize that hacks compound in fatal
ways over time.  The "ain't broke, don't fix" philosophy is a good guide
here, provided you've got a very low threshold for insisting "it's broke"
<0.4 wink>.

if-you-would-have-liked-to-do-the-whole-differently-then-by-all-means-
    *do*-the-whole-thing-differently-that-works-in-c-too-ly y'rs  - tim




From Moshe Zadka <moshez@math.huji.ac.il>  Wed Oct 25 08:49:21 2000
From: Moshe Zadka <moshez@math.huji.ac.il> (Moshe Zadka)
Date: Wed, 25 Oct 2000 09:49:21 +0200 (IST)
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: <200010241739.MAA16414@cj20424-a.reston1.va.home.com>
Message-ID: <Pine.GSO.4.10.10010250923490.9960-100000@sundial>

On Tue, 24 Oct 2000, Guido van Rossum wrote:

> Maybe we can do the same for Unix binary distributions?

I don't know what you mean by "UNIX" binary distributions: each UNIX
has its own sets of horrors in the distribution arena. Personally, I
don't care what we do about RPMs, since I'm not a Red Hat user. However,
this should probably be more Red Hat's job then ours. Debian, on the
other hand, would probably do this much better then Python-Dev can,
without gratutitous Tcl/Tk installations. For other unices, most people
install from sources anyway, which mostly means I should get off my butt
and start working on the Sumo interpreter.

> Really?  Are you sure that's not just general resistence against new
> things?  To me, and I suspect may others, the app I use most often on
> Windows is Netscape -- talk about lack of native look-and-feel!  It's
> never bothered me all that much.

I don't know how to break this to you, but you're not the average computer
user <wink>.

--
Moshe Zadka <moshez@math.huji.ac.il>
There is no IGLU cabal.
http://advogato.org/person/moshez



From mal@lemburg.com  Wed Oct 25 09:10:46 2000
From: mal@lemburg.com (M.-A. Lemburg)
Date: Wed, 25 Oct 2000 10:10:46 +0200
Subject: [Python-Dev] Gradual migration
References: <LNBBLJKPBEHFEDALKOLCMELHHMAA.tim_one@email.msn.com>
Message-ID: <39F69586.E017DA7E@lemburg.com>

Tim Peters wrote:
> 
> [MAL]
> > ...
> > I think this will simply be a consequence of doing a complete rewrite
> > of the interpreter for Py3K.
> 
> Not just to be my usual self <wink>, but I do see a from-scratch rewrite as
> being less likely as the years go by.  There's nothing I know of in Guido's
> plans that can't be done incrementally instead -- and if he doesn't either,
> selling a total- rewrite project to an employer is probably impossible.
>
> The most successful projects I've seen and been on *did* rewrite all the
> code routinely, but one subsystem at a time.  This happens when you're
> tempted to add a hack, realize it wouldn't be needed if an entire area were
> reworked, and mgmt is bright enough to realize that hacks compound in fatal
> ways over time.  The "ain't broke, don't fix" philosophy is a good guide
> here, provided you've got a very low threshold for insisting "it's broke"
> <0.4 wink>.

As I mentioned in the posting, the idea was from the "fluffy clouds"
area. The rewrite would only involve the core type system and perhaps
the core interpreter layout (parser, compiler, etc. all wrapped in
classes) -- most of the existing code would be reusable. 

The idea behind this is somewhat like what you do when starting out a
project based on a few simple functions and then reorganizing the
code into a class-based approach. There's no need to rewrite all 
the type internals, just the type interfaces. 

Python has long reached a level of complexity that is counter-
productive when it comes to adding new extension types. Just
think of all the problems people have with coercion, the integration
of user defined and internal types, the missing links between
types and classes, etc. etc.  

BTW, why all the talk about "employers" ? Much of Python's code
base was written without any employer knowing about it ;-)

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/


From jim@interet.com  Wed Oct 25 11:40:56 2000
From: jim@interet.com (James C. Ahlstrom)
Date: Wed, 25 Oct 2000 06:40:56 -0400
Subject: [Python-Dev] What to choose to replace Tkinter?
References: <14837.14407.954185.466011@buffalo.fnal.gov> <ECEPKNMJLHAPFFJHDOJBKEKIDOAA.MarkH@ActiveState.com> <14837.43273.24692.93965@buffalo.fnal.gov> <20001024114326.E13957@kronos.cnri.reston.va.us>
Message-ID: <39F6B8B8.E3242929@interet.com>

Andrew Kuchling wrote:

> Can someone articulate why Tk should be replaced?

I don't know whether Tk should replaced, but I
can explain why I don't use it for our commercial
Python application.

It is just too big and complicated.  Windows comes
with a built-in GUI, and I hesitate to install
another scripting language (Tcl) and its libraries,
and then install a big system which has frequently been
out of phase with Python releases just to access the
Windows GUI.

What if a user calls with a problem?  Why should I
have to debug their Tcl library path problems?  No
thanks.

JimA


From jim@interet.com  Wed Oct 25 11:47:05 2000
From: jim@interet.com (James C. Ahlstrom)
Date: Wed, 25 Oct 2000 06:47:05 -0400
Subject: [Python-Dev] What to choose to replace Tkinter?
References: <Pine.LNX.4.10.10010241146450.6622-100000@akbar.nevex.com> <200010241739.MAA16414@cj20424-a.reston1.va.home.com>
Message-ID: <39F6BA29.3CAB4C0E@interet.com>

Guido van Rossum wrote:

> > 2. (Lack of) native look and feel.  This is a complete show-stopper for
> >    many of the outfits I've dealt with (and not just with Python).
> 
> Really?  Are you sure that's not just general resistence against new
> things?  To me, and I suspect may others, the app I use most often on
> Windows is Netscape -- talk about lack of native look-and-feel!  It's
> never bothered me all that much.

In the past I have resolutely demanded native Windows look
and feel in my apps.  In fact, I have been tiresome on the topic.

Now I am changing my mind.  Lots of prominent Windows apps now
depart from Microsoft LAF, and I have the impression that users
are getting used to it.  I still think the usual File menu
items and file open/save dialogs should be standard, but I
am less concerned about other controls.  For a look
at how to really do controls, check out software for
kids.  Just my 1.e-2$.

JimA


From guido@python.org  Wed Oct 25 13:11:35 2000
From: guido@python.org (Guido van Rossum)
Date: Wed, 25 Oct 2000 07:11:35 -0500
Subject: [Python-Dev] Why not revive stdwin?
In-Reply-To: Your message of "Tue, 24 Oct 2000 22:29:17 MST."
 <20001024222917.I1147@thyrsus.com>
References: <20001023162118.B18005@kronos.cnri.reston.va.us> <200010242318.MAA28238@s454.cosc.canterbury.ac.nz>
 <20001024222917.I1147@thyrsus.com>
Message-ID: <200010251211.HAA22128@cj20424-a.reston1.va.home.com>

> Greg Ewing <greg@cosc.canterbury.ac.nz>:
> > It appears that we can't rely on anyone else to provide and
> > support a GUI properly across all three platforms. If we
> > want one, it looks like we'll have to do it ourselves.

Eric Raymond:
> I fear this is much too big a job to be practical -- not just in the
> additional code but the downstream maintainance.

Well said.  The "roll your own" approach has been attempted before,
but simply isn't worth the time and effort.  After all, Python is a
glue language!

(And stdwin would really look pathetic in this time.)

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


From guido@python.org  Wed Oct 25 13:25:29 2000
From: guido@python.org (Guido van Rossum)
Date: Wed, 25 Oct 2000 07:25:29 -0500
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: Your message of "Wed, 25 Oct 2000 06:40:56 -0400."
 <39F6B8B8.E3242929@interet.com>
References: <14837.14407.954185.466011@buffalo.fnal.gov> <ECEPKNMJLHAPFFJHDOJBKEKIDOAA.MarkH@ActiveState.com> <14837.43273.24692.93965@buffalo.fnal.gov> <20001024114326.E13957@kronos.cnri.reston.va.us>
 <39F6B8B8.E3242929@interet.com>
Message-ID: <200010251225.HAA22242@cj20424-a.reston1.va.home.com>

> Andrew Kuchling wrote:
> 
> > Can someone articulate why Tk should be replaced?

Jim Ahlstrom replied:

> I don't know whether Tk should replaced, but I
> can explain why I don't use it for our commercial
> Python application.
> 
> It is just too big and complicated.  Windows comes
> with a built-in GUI, and I hesitate to install
> another scripting language (Tcl) and its libraries,
> and then install a big system which has frequently been
> out of phase with Python releases just to access the
> Windows GUI.

To me this all sounds like FUD.  Since Python 1.6 and 2.0, you don't
have to install Tcl/Tk or its libraries -- it is installed
*transparently* by the Python Windows installer.  That's different --
and better -- than what happened in 1.5.2, where a separate Tcl/Tk
installer was optionally run.  The version issues are also resolved
this way: you are guaranteed to get exactly the Tcl/Tk version that
was tested by the developers.

> What if a user calls with a problem?  Why should I
> have to debug their Tcl library path problems?  No
> thanks.

The Tcl library paths are all taken care of by the new installer
strategy.

Really, give it a try.  It Just Works! (SM)

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


From guido@python.org  Wed Oct 25 13:27:28 2000
From: guido@python.org (Guido van Rossum)
Date: Wed, 25 Oct 2000 07:27:28 -0500
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: Your message of "Wed, 25 Oct 2000 06:47:05 -0400."
 <39F6BA29.3CAB4C0E@interet.com>
References: <Pine.LNX.4.10.10010241146450.6622-100000@akbar.nevex.com> <200010241739.MAA16414@cj20424-a.reston1.va.home.com>
 <39F6BA29.3CAB4C0E@interet.com>
Message-ID: <200010251227.HAA22256@cj20424-a.reston1.va.home.com>

> In the past I have resolutely demanded native Windows look
> and feel in my apps.  In fact, I have been tiresome on the topic.
> 
> Now I am changing my mind.  Lots of prominent Windows apps now
> depart from Microsoft LAF, and I have the impression that users
> are getting used to it.  I still think the usual File menu
> items and file open/save dialogs should be standard, but I
> am less concerned about other controls.  For a look
> at how to really do controls, check out software for
> kids.  Just my 1.e-2$.

Even Microsoft is violating its own (boring) style guide, when they
think it appeals to a specific audience.  Have you seen their Media
Player?

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


From jim@digicool.com  Wed Oct 25 13:21:41 2000
From: jim@digicool.com (Jim Fulton)
Date: Wed, 25 Oct 2000 08:21:41 -0400
Subject: [Python-Dev] A small step to removing the type/class split
References: <20001024045611.B9993@glacier.fnational.com> <200010242150.QAA19518@cj20424-a.reston1.va.home.com>
Message-ID: <39F6D055.584C4FEA@digicool.com>

Guido van Rossum wrote:
> 
(snip)
> Rather than formalizing the exceptions made for instances, we should
> work on eradicating the differences between classes and types. 

Yee ha! I couldn't agree more. :)

> I believe that the plans for rich comparisons would or could also take
> care of this. 

I assume that rich comparison's have new slots with signatures
that don't assume objects of the same type.

> I hope I'll have more time soon to explore this.

Me too.

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 jim@digicool.com  Wed Oct 25 13:25:53 2000
From: jim@digicool.com (Jim Fulton)
Date: Wed, 25 Oct 2000 08:25:53 -0400
Subject: [Python-Dev] A small step to removing the type/class split
References: <20001024045611.B9993@glacier.fnational.com>
Message-ID: <39F6D151.70F47CFF@digicool.com>

Neil Schemenauer wrote:
> 
> I've run into a problem with ExtensionClass which I believe can
> only be fixed by modifying Python.  I will try to explain.
> 
> I have an ExtensionClass which defines __cmp__.  Depending on the
> objects being compared, the __cmp__ method may never be called.
> This is due to code in object.c that looks like this:
> 
>     if (PyInstance_Check(v) || PyInstance_Check(w)) {
>         try to use use __cmp__ method
>     }
>     else {
>         try number coerce and fall back on type name comparison
>     }
> 
> Extension classes can never pass the PyInstance_Check predicate.
> I've searched for all occurances of PyInstance_Check in the 2.0
> source.  In many places that PyInstance_Check occurs a more
> general "is this an instance-like type" check would seem to be
> more suitable.
> 
> Here is my proposal:

(snip)

I think you got some good answers later in the thread.

I'll point out that a work around is to make your ExtensionClass
a numeric type.  Numeric types have different comparison 
semantics that allow you to get around this limitation.
I did this a few months back for acquisition wrappers.

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 gvwilson@nevex.com  Wed Oct 25 13:38:12 2000
From: gvwilson@nevex.com (Greg Wilson)
Date: Wed, 25 Oct 2000 08:38:12 -0400 (EDT)
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: <200010241904.OAA19165@cj20424-a.reston1.va.home.com>
Message-ID: <Pine.LNX.4.10.10010250820030.2415-100000@akbar.nevex.com>

> Guido van Rossum:
> Can you elaborate on the line of argument that you typically hear
> [objections to Tkinter]? What do you say to dispel it?

From some feedback forms from old runs of my Python course (with spelling
corrections :-)

1. "My users don't care what programs are written in.  They just care
   if they're easy to use.  They won't care if Python programs have
   the same look and feel on different computers, because they won't
   ever think of [name of program] as a Python program.  To them, it
   will be a Windows program that looks funny."

2. "You said three times in the intro lecture this morning that the
   most important thing in a GUI was consistency.  Then you told us to
   write GUIs that look different from everything else on the desktop."

3. "I'm confused: I didn't realize that Python was a library on top of
   TCL."

I spent a minute drawing blob diagrams to answer #3; I think most students
understood, but the person who asked the question was clearly still confused.

I didn't try to dispel #1 or #2, because I agree with them: my experience is
that consistent look and feel are crucial for making non-programmers less afraid
of pressing the wrong button or making the program "do weird things".  Other
people with more experience creating end-user applications may have different
views.

Thanks,
Greg



From guido@python.org  Wed Oct 25 14:53:48 2000
From: guido@python.org (Guido van Rossum)
Date: Wed, 25 Oct 2000 08:53:48 -0500
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: Your message of "Wed, 25 Oct 2000 08:38:12 -0400."
 <Pine.LNX.4.10.10010250820030.2415-100000@akbar.nevex.com>
References: <Pine.LNX.4.10.10010250820030.2415-100000@akbar.nevex.com>
Message-ID: <200010251353.IAA28190@cj20424-a.reston1.va.home.com>

> From some feedback forms from old runs of my Python course (with spelling
> corrections :-)
> 
> 1. "My users don't care what programs are written in.  They just care
>    if they're easy to use.  They won't care if Python programs have
>    the same look and feel on different computers, because they won't
>    ever think of [name of program] as a Python program.  To them, it
>    will be a Windows program that looks funny."
> 
> 2. "You said three times in the intro lecture this morning that the
>    most important thing in a GUI was consistency.  Then you told us to
>    write GUIs that look different from everything else on the desktop."
> 
> 3. "I'm confused: I didn't realize that Python was a library on top of
>    TCL."
> 
> I spent a minute drawing blob diagrams to answer #3; I think most students
> understood, but the person who asked the question was clearly still confused.
> 
> I didn't try to dispel #1 or #2, because I agree with them: my
> experience is that consistent look and feel are crucial for making
> non-programmers less afraid of pressing the wrong button or making
> the program "do weird things".  Other people with more experience
> creating end-user applications may have different views.

This is helpful.  Can you elaborate on what elements of the Windows
look-and-feel are missing in Tkinter?  As far as I know, the menu
bars, file selection dialogs, scroll bars, dialog boxes and so on have
a thoroughly native look-and-feel, since Tk implements these as
wrappers around the native widgets.  IDLE doesn't look very different
from Notepad!

So what's missing?  A toolbar with icons?  That would be easy to add
using existing Tk controls (Pmw has it too).  The multiple document
interface?  It sucks -- and even Word 2000 has gone away from that!

What kind of GUIs did you teach them exactly?  If you started with
basic Tkinter widgets, sure, it looks different than anything else.
But that depends on the widget layout in the program, not on the
widget library used!

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


From barry@scottb.demon.co.uk  Wed Oct 25 14:55:40 2000
From: barry@scottb.demon.co.uk (Barry Scott)
Date: Wed, 25 Oct 2000 14:55:40 +0100
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: <200010251353.IAA28190@cj20424-a.reston1.va.home.com>
Message-ID: <002301c03e8b$42cbc280$060210ac@private>

I choose to use wxPython over TK because:

1. wxPython has a reasonable event model
2. wxPython allows me build one object hierarchy
3. TK requires I manage two object hierarchies, TK's and my classes
4. Hooking events to TK seems clumsy from Python

As others have said better docs on wxPython would be nice
and its to easy to crash the world from wxPython.

		Barry



From claird@starbase.neosoft.com  Wed Oct 25 15:58:53 2000
From: claird@starbase.neosoft.com (Cameron Laird)
Date: Wed, 25 Oct 2000 09:58:53 -0500 (CDT)
Subject: [Python-Dev] Miscellaneous comments on Tkinter and related matters
Message-ID: <200010251458.JAA77237@starbase.neosoft.com>

I can rarely afford to dip into Python-Dev.  My head is exploding
too much of the time as it is.

Maybe I can help with the recent Tkinter discussions, though.
1.  Tcl's going to be around for a long time.
    Here's the insider scoop on what the Ajuba
    Solutions announcement means:  insiders
    don't know.  That is, *nobody* is sure how
    Tcl will develop.

    It'll survive, though, for quite a while.
    Do NOT worry that it'll suddenly dry up
    and blow away.

    I'm working on a more detailed explanation
    of Tcl processes.  It'll probably take a
    few weeks, though.  In the meantime, just
    ignore the mess, and understand that the
    Tcl Core Team includes bright people who'll
    land on their feet somehow.
2.  I agree that MacOS is the thorny problem for
    the standard Pysolution.  I'd be happy to
    discuss the possibilities (Tkinter?  wxWindows?
    Qt?!? GTK+?!!?!? ...) with a smaller group,
    and, of course, Fredrik, Robin, Guido, ...
    all are quite knowledgeable about these
    matters.

    There are a few things you should know about
    the Tcl side.  The bad is that Tk is barely
    maintained for MacOS.  It's really rather
    miserable.  On the other hand, Jim Ingham is
    now an Apple employee, and things could change
    in a hurry, at any time.

    The good is that Tk starts far ahead of any
    competitor.  It has already solved most of
    the hard problems.  All it needs is a little
    maintenance.
3.  Is there a way to have Tk without contamination
    by Tcl?  More than ever.  This is what makes me
    most cheerful about Tkinter's prospects.  The
    Tcl Core Team has largely given up its hangups
    about co-operating with foreigners (or its
    hangups that barbarians have hangups about co-
    operating with Tcl).  This is a *very* good
    time for someone like Fredrik to establish a
    working relationship, and get CVS access.  I
    really think Tk can be maintained by a different
    group than Tcl.

    Perl, Ruby, ... folks are also receptive to the
    idea (I've talked with them).  For pointers to
    some of what's happening in this area, see
    <URL:http://starbase.neosoft.com/~claird/comp.lang.misc/core_enhancement.html>

    Also, you should know that my favorite enhancement
    to Tk is a remodularization called TkGS.  This
    should improve performance under Win*, make it
    more portable to BeOS, improve access by Python,
    and so on.
4.  Greg's right that some publishers are dumping Tcl.
    Not all, though.  If it matters, we can go into
    details.
5.  Pango is indeed cool, but it's different from
    [text].  The world is probably moving to Pango and
    similar implementations.  The world will be missing
    much of what [text] offers.
6.  ANYONE with an urge to get out a Python-related
    idea should pursue it.  *DDJ*'s a great outlet.
    It's far from the only one.  If people have ideas
    about articles, but are held back by lack of time/
    fluency/contacts/..., *please* get in touch with
    me.  I'll find a way at least to give articles a
    fair chance at being published.

Cameron Laird       <claird@NeoSoft.com>       +1 281 996 8546 FAX
http://starbase.neosoft.com/~claird/misc.writing/publications.html


From cgw@fnal.gov  Wed Oct 25 16:31:38 2000
From: cgw@fnal.gov (Charles G Waldman)
Date: Wed, 25 Oct 2000 10:31:38 -0500 (CDT)
Subject: [Python-Dev] Miscellaneous comments on Tkinter and related matters
In-Reply-To: <200010251458.JAA77237@starbase.neosoft.com>
References: <200010251458.JAA77237@starbase.neosoft.com>
Message-ID: <14838.64730.225260.148853@buffalo.fnal.gov>

Cameron Laird writes:
 > I can rarely afford to dip into Python-Dev.  My head is exploding
 > too much of the time as it is.
 > 
 > Maybe I can help with the recent Tkinter discussions, though.

 > 2.  I agree that MacOS is the thorny problem for
 >     the standard Pysolution. 

What is the impact of the fact that MacOS X will run X?  Doesn't this
open the door to a lot of new possibilities, at least if we don't need
to support Mac OS[6-9].  Or is the installed base of MacOS[6-9] just
way too big to even think about dropping (or deprecating) support for
it?


From tim_one@email.msn.com  Wed Oct 25 17:23:30 2000
From: tim_one@email.msn.com (Tim Peters)
Date: Wed, 25 Oct 2000 12:23:30 -0400
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: <200010251225.HAA22242@cj20424-a.reston1.va.home.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCIEMOHMAA.tim_one@email.msn.com>

[Guido, on finding Tcl/Tk under Windows]
> To me this all sounds like FUD.  Since Python 1.6 and 2.0, you don't
> have to install Tcl/Tk or its libraries -- it is installed
> *transparently* by the Python Windows installer.  That's different --
> and better -- than what happened in 1.5.2, where a separate Tcl/Tk
> installer was optionally run.  The version issues are also resolved
> this way: you are guaranteed to get exactly the Tcl/Tk version that
> was tested by the developers.

Unless you're Fredrik, alas <wink>.  Apparently Tcl still honors library
envars first if they exist, and if some other installation or use of Tcl/Tk
set those, you can still end up w/ a mix. *Much* better than before, though,
and I don't recall ay instance of this happening in real life so far apart
from /F (who had no problem figuring it out, of course).

>> What if a user calls with a problem?  Why should I
>> have to debug their Tcl library path problems?  No
>> thanks.

> The Tcl library paths are all taken care of by the new installer
> strategy.
>
> Really, give it a try.  It Just Works! (SM)

I'll second that!  "Mystery startup errors" from the Python+Tcl+Tk+Windows
combo were at least weekly questions on c.l.py for 1.5.2, often daily.  I've
seen none for 1.6 or 2.0.

and-all-it-took-was-avoiding-ms's-recommended-practices<wink>-ly y'rs  - tim




From guido@python.org  Wed Oct 25 18:46:55 2000
From: guido@python.org (Guido van Rossum)
Date: Wed, 25 Oct 2000 12:46:55 -0500
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: Your message of "Wed, 25 Oct 2000 12:23:30 -0400."
 <LNBBLJKPBEHFEDALKOLCIEMOHMAA.tim_one@email.msn.com>
References: <LNBBLJKPBEHFEDALKOLCIEMOHMAA.tim_one@email.msn.com>
Message-ID: <200010251746.MAA30108@cj20424-a.reston1.va.home.com>

> [Guido, on finding Tcl/Tk under Windows]
> > To me this all sounds like FUD.  Since Python 1.6 and 2.0, you don't
> > have to install Tcl/Tk or its libraries -- it is installed
> > *transparently* by the Python Windows installer.  That's different --
> > and better -- than what happened in 1.5.2, where a separate Tcl/Tk
> > installer was optionally run.  The version issues are also resolved
> > this way: you are guaranteed to get exactly the Tcl/Tk version that
> > was tested by the developers.

[Tim]
> Unless you're Fredrik, alas <wink>.  Apparently Tcl still honors library
> envars first if they exist, and if some other installation or use of Tcl/Tk
> set those, you can still end up w/ a mix. *Much* better than before, though,
> and I don't recall ay instance of this happening in real life so far apart
> from /F (who had no problem figuring it out, of course).

Hm...  In FixTk, TCL_LIBRARY is set explicitly.  Perhaps it should set
TK_LIBRARY explicitly too?

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


From trentm@ActiveState.com  Wed Oct 25 18:11:42 2000
From: trentm@ActiveState.com (Trent Mick)
Date: Wed, 25 Oct 2000 10:11:42 -0700
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: <LNBBLJKPBEHFEDALKOLCIEMOHMAA.tim_one@email.msn.com>; from tim_one@email.msn.com on Wed, Oct 25, 2000 at 12:23:30PM -0400
References: <200010251225.HAA22242@cj20424-a.reston1.va.home.com> <LNBBLJKPBEHFEDALKOLCIEMOHMAA.tim_one@email.msn.com>
Message-ID: <20001025101142.B8625@ActiveState.com>

On Wed, Oct 25, 2000 at 12:23:30PM -0400, Tim Peters wrote:
> [Guido, on finding Tcl/Tk under Windows]
> > To me this all sounds like FUD.  Since Python 1.6 and 2.0, you don't
> > have to install Tcl/Tk or its libraries -- it is installed
> > *transparently* by the Python Windows installer.  That's different --
> > and better -- than what happened in 1.5.2, where a separate Tcl/Tk
> > installer was optionally run.  The version issues are also resolved
> > this way: you are guaranteed to get exactly the Tcl/Tk version that
> > was tested by the developers.
> 
> Unless you're Fredrik, alas <wink>.

...Or anybody installing ActivePython for that matter. We give instructions
that the latest version of Tcl/Tk has to be installed separately, but Tk is
*not* bundled with it.


Trent

-- 
Trent Mick
TrentM@ActiveState.com


From pf@artcom-gmbh.de  Wed Oct 25 18:02:45 2000
From: pf@artcom-gmbh.de (Peter Funk)
Date: Wed, 25 Oct 2000 19:02:45 +0200 (MEST)
Subject: GUI-Discussion; MacOS vs. MacOS X (was Re: [Python-Dev] Miscellaneous comments on Tkinter and related...)
In-Reply-To: <14838.64730.225260.148853@buffalo.fnal.gov> from Charles G Waldman at "Oct 25, 2000 10:31:38 am"
Message-ID: <m13oTwr-000Dm8C@artcom0.artcom-gmbh.de>

Hi,

Charles G Waldman:
>  > 2.  I agree that MacOS is the thorny problem for
>  >     the standard Pysolution. 
> 
> What is the impact of the fact that MacOS X will run X?  Doesn't this
> open the door to a lot of new possibilities, at least if we don't need
> to support Mac OS[6-9].  Or is the installed base of MacOS[6-9] just
> way too big to even think about dropping (or deprecating) support for
> it?

It will take years, before MacOS X will find its way onto the desk
of the average Apple Mac user.  The Mac s mostly used in the graphics 
and printing industry (our cutsomers) where people normally don't 
even think about a OS upgrade, if they don't have to.  They usually
run a mix of Photoshop, Quark XPRess, Artwork, illustrator or other 
so called creative software on the version of the OS they had on 
the machine when they bought it.  THese machines are usually used
through a period of at least four years.

So MacOS X might simplify things for software vendors from 2004 on 
and later.

Regards, Peter


From guido@python.org  Wed Oct 25 19:21:58 2000
From: guido@python.org (Guido van Rossum)
Date: Wed, 25 Oct 2000 13:21:58 -0500
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: Your message of "Wed, 25 Oct 2000 10:11:42 MST."
 <20001025101142.B8625@ActiveState.com>
References: <200010251225.HAA22242@cj20424-a.reston1.va.home.com> <LNBBLJKPBEHFEDALKOLCIEMOHMAA.tim_one@email.msn.com>
 <20001025101142.B8625@ActiveState.com>
Message-ID: <200010251821.NAA30247@cj20424-a.reston1.va.home.com>

> ...Or anybody installing ActivePython for that matter. We give instructions
> that the latest version of Tcl/Tk has to be installed separately, but Tk is
> *not* bundled with it.

And that's a shame.  Any chance that will be fixed any time soon?

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


From jeremy@alum.mit.edu  Wed Oct 25 14:36:46 2000
From: jeremy@alum.mit.edu (Jeremy Hylton)
Date: Wed, 25 Oct 2000 09:36:46 -0400 (EDT)
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: <200010251821.NAA30247@cj20424-a.reston1.va.home.com>
References: <200010251225.HAA22242@cj20424-a.reston1.va.home.com>
 <LNBBLJKPBEHFEDALKOLCIEMOHMAA.tim_one@email.msn.com>
 <20001025101142.B8625@ActiveState.com>
 <200010251821.NAA30247@cj20424-a.reston1.va.home.com>
Message-ID: <14838.57838.841831.632628@bitdiddle.concentric.net>

>>>>> "GvR" == Guido van Rossum <guido@python.org> writes:

  >> ...Or anybody installing ActivePython for that matter. We give
  >> instructions that the latest version of Tcl/Tk has to be
  >> installed separately, but Tk is *not* bundled with it.

  GvR> And that's a shame.  Any chance that will be fixed any time
  GvR> soon?

I think a version of Tkinter packaged with a distutils setup script is
the best answer for Unix platforms.  As a Linux user, I do *not* want
to install a second copy of Tcl/Tk.

If we have a distutil-Tkinter, e.g. 
    ftp://ftp.python.org/pub/python/2.0/Tkinter-2.0-8.0.tar.gz
then a user can download it and run "python setup.py install" to build
a Tkinter against their installed version of Tk.  This will be
straightforward on many Linux systems, because they ship with Tk
installed.

Jeremy


From jeremy@alum.mit.edu  Wed Oct 25 14:41:30 2000
From: jeremy@alum.mit.edu (Jeremy Hylton)
Date: Wed, 25 Oct 2000 09:41:30 -0400 (EDT)
Subject: [Python-Dev] build problems under Solaris
Message-ID: <14838.58122.920099.787981@bitdiddle.concentric.net>

There are two bug reports about build problems under Solaris (117508
and 117606).  I don't have access to a Solaris machine, so I can't do
anything to help these users.  Since ActivePython is shipped for
Solaris, I assume that you (or someone else at AS) does have access to
a Solaris machine.  Can you take a look at these problems?  Or assign
them to someone else who can?

Jeremy



From guido@python.org  Wed Oct 25 19:50:07 2000
From: guido@python.org (Guido van Rossum)
Date: Wed, 25 Oct 2000 13:50:07 -0500
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: Your message of "Wed, 25 Oct 2000 09:36:46 -0400."
 <14838.57838.841831.632628@bitdiddle.concentric.net>
References: <200010251225.HAA22242@cj20424-a.reston1.va.home.com> <LNBBLJKPBEHFEDALKOLCIEMOHMAA.tim_one@email.msn.com> <20001025101142.B8625@ActiveState.com> <200010251821.NAA30247@cj20424-a.reston1.va.home.com>
 <14838.57838.841831.632628@bitdiddle.concentric.net>
Message-ID: <200010251850.NAA30475@cj20424-a.reston1.va.home.com>

> I think a version of Tkinter packaged with a distutils setup script is
> the best answer for Unix platforms.  As a Linux user, I do *not* want
> to install a second copy of Tcl/Tk.

Why not?  Because if every app using Tcl/Tk did that there would be
hundreds of copies of Tcl/Tk on your disk?  I don't think that
argument flies; only a few other major languages use Tcl/Tk this was,
so maybe you'd end up with 4 copies of Tcl/Tk: one for Tcl/Tk itself,
one for Python+Tkinter, one for Perl/Tk (that's a separate code base
anyway so you already have this today -- if you install Perl/Tk, that
is), and one for Ruby.  Given modern disk sizes I don't think it's a
problem.  We do the same for Windows, for good reasons: so we can be
independent of whatever Tcl/Tk version is already installed.

> If we have a distutil-Tkinter, e.g. 
>     ftp://ftp.python.org/pub/python/2.0/Tkinter-2.0-8.0.tar.gz
> then a user can download it and run "python setup.py install" to build
> a Tkinter against their installed version of Tk.  This will be
> straightforward on many Linux systems, because they ship with Tk
> installed.

Of course that's easier.  But less robust.  (And why is there an "8.0"
in the filename if it works with other Tcl/Tk versions???)

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


From paul@prescod.net  Wed Oct 25 19:11:34 2000
From: paul@prescod.net (Paul Prescod)
Date: Wed, 25 Oct 2000 11:11:34 -0700
Subject: [Python-Dev] Gradual migration
References: <39F52EF1.A201C6D9@prescod.net> <39F54C0F.25798309@lemburg.com> <39F5B4DC.C226D8F6@prescod.net> <39F5E4FA.9FD6D35@lemburg.com>
Message-ID: <39F72256.C7F93BFB@prescod.net>

"M.-A. Lemburg" wrote:
> 
> ...
>
> >  * implementation language and Python inheritance semantics are almost
> > completely distinct. After all, we have Python implementations in a
> > variety of languages with minor incompatibilities. Python could have a
> > proper type/class merging even if it were written in assembly language.
> > So let's leave implementation language aside.
> 
> Hey, think of it as opportunity: we can reuse much of C++'s
> optimizations and the integration of Python and C++ applications
> will get *much* easier.

We could make integrating C++ and Python easier through CXX or Py_Cpp.
Perhaps we should ship one of those with Python 2.1. Anyhow, integrating
C++ and Python is not really so hard, in my experience.
 
> A rewrite shouldn't scare anyone away -- much of the existing
> code can be reused since only the Python C APIs of the various
> types will have to be rewritten, not the logic behind the types.

I wasn't really addressing the issue of backwards compatibility of
extensions -- I was talking about Python programs. Nevertheless, I can't
resist:

Porting your app to the Python APIs is often the majority of the work in
a particular extension. A lot of Python extensions consist only of API
glue!
 
> Besides, Py3K will be a project which runs in parallel to the
> 2.x development (at least that's what I've read on some BeOpen
> webpage), so there's really not much to worry about wrt to
> breakage, etc. People will be able to test-drive Py3K while
> using the 2.x series.

I don't see how that helps. If you can't write programs that work both
on the old interpreter and the new one then you need to have a "switch
over" day. The whole point of my doctrine is that Python 3K should run
all code that the version of Python immediately before it did. The most
it can do in terms of breakage is to warn about error messages. In that
case it doesn't matter much whether Python 3K is available at the same
time as 2.X or emerges from Guido's head fully formed.

> >  * there is a hell of a lot we can do to make the type/class split less
> > visible without a major rewrite. For instance, lists could have a
> > __getitem__ method so that they "act like" instances. Instances could
> > return their methods in a dir() so that they "act like" built-in
> > objects. So there is no reason to wait for a complete rewrite to start
> > on this path.
> 
> Right. I didn't want to say that things cannot be done prior
> to the rewrite, only that a rewrite will give us much more
> options that we currently have.

Okay, so do you agree with the rule expressed here:

http://www.python.org/pipermail/python-dev/2000-October/016785.html

> > I don't know what you mean by a "low-level strategy" for classes. It's
> > not like we can somehow use C++ vtables without giving up Python's
> > dynamicity. Python's class handling is about as low-level as it can get
> > in my humble opinion.
> 
> With "low-level" I meant trying to build Python classes and
> instances on top of a very thin layer on top of C++ classes,
> e.g. all slots could be implemented using true C++ methods with
> additional logic to override them using dynamically bound
> Python method objects.

I don't think that there is really interesting magic in a C++ compiler.
A vtable is an array of pointers to functions. We've already implemented
the equivalent in ANSI C. C++ exceptions, constructors, destriuctors and
smart pointers are a little more interesting from a code maintenance and
simplicity point of view. But even then I think that we could get to a
C++ implementation through incremental rewrites.

> > > Differences like the
> > > ones between Unicode and 8-bit strings would then flesh
> > > out as two different subclasses of a generic string type which
> > > again is based on a generic sequence type.
> >
> > Of course that's where we want to go but it doesn't avoid the backwards
> > compatibility problems.
> 
> Huh ? I was talking about clear design... not ways to avoid
> b/w compatibility. 

But the whole point of my original article was backwards
compatibility!!! I didn't address an implementation strategy for Py3K at
all.

> Merging Unicode and strings will hurt one
> way or another. This is simply a consequence of using strings
> as binary containers where Unicode is meant for text only use.

The question I wanted to address is how we can *minimize the pain*. 

> ...
> > C++ does not help. Inheritance does not help. Pluggable compilers do not
> > help. We *will* break code. We just need to decide whether to do it in a
> > thoughtful way that gives people a chance to migrate or put off
> > decisions until the last possible moment and then spring it on them with
> > no between-version upgrade path.
> 
> Just tell Python to use the correct class for what the
> code was written for (and this could be done by plugging in
> a 2.0 compiler). The instances of those classes would still work
> together with other semantics by virtue of exposing the same
> interface, yet the internals would work differently, e.g.
> a module using case insensitive lookup would be compiled using
> case insensitive dictionaries as namespaces.

A mode switch solutiion is fraught with dangers. First there is the
issue of the correct default for the mode switch. 

http://www.python.org/pipermail/python-dev/2000-April/010029.html

Second, there are dangers cutting and pasting between modules.

Anyhow, even if we allow a mode switch we need to be able to help people
to upgrade their modules in a reasonable time. That's what the message I
cited advocates.

>...
> Why spoil all the fun when we haven't even started thinking
> about all the possibilities we could use to make Py3k a
> success ?

Asking for a map of where we are going and how we will get here is
"spoiling all of the fun?" I'm not sure what you are reacting to -- I
didn't advise one implementation strategy or another -- I just said that
we should employ a strategy that minimizes sudden and surprising code
breakage.

-- 
 Paul Prescod - Not encumbered by corporate consensus
Simplicity does not precede complexity, but follows it. 
	- http://www.cs.yale.edu/homes/perlis-alan/quotes.html


From fdrake@acm.org  Wed Oct 25 19:06:50 2000
From: fdrake@acm.org (Fred L. Drake, Jr.)
Date: Wed, 25 Oct 2000 14:06:50 -0400 (EDT)
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: <200010251850.NAA30475@cj20424-a.reston1.va.home.com>
References: <200010251225.HAA22242@cj20424-a.reston1.va.home.com>
 <LNBBLJKPBEHFEDALKOLCIEMOHMAA.tim_one@email.msn.com>
 <20001025101142.B8625@ActiveState.com>
 <200010251821.NAA30247@cj20424-a.reston1.va.home.com>
 <14838.57838.841831.632628@bitdiddle.concentric.net>
 <200010251850.NAA30475@cj20424-a.reston1.va.home.com>
Message-ID: <14839.8506.304295.908264@cj42289-a.reston1.va.home.com>

Guido van Rossum writes:
 > Why not?  Because if every app using Tcl/Tk did that there would be
 > hundreds of copies of Tcl/Tk on your disk?  I don't think that
 > argument flies; only a few other major languages use Tcl/Tk this was,

  So should every application written in Python install it's own copy
of Python, since there may be unexpected incompatibilities between
versions?


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at acm.org>
PythonLabs Team Member



From paul@prescod.net  Wed Oct 25 19:18:16 2000
From: paul@prescod.net (Paul Prescod)
Date: Wed, 25 Oct 2000 11:18:16 -0700
Subject: [Python-Dev] Miscellaneous comments on Tkinter and related matters
References: <200010251458.JAA77237@starbase.neosoft.com> <14838.64730.225260.148853@buffalo.fnal.gov>
Message-ID: <39F723E8.2AC6787@prescod.net>

Charles G Waldman wrote:
> 
> ...
> What is the impact of the fact that MacOS X will run X?  Doesn't this
> open the door to a lot of new possibilities, at least if we don't need
> to support Mac OS[6-9].  Or is the installed base of MacOS[6-9] just
> way too big to even think about dropping (or deprecating) support for
> it?

Would Mac users go for: "first install X. Then you can run Python."

-- 
 Paul Prescod - Not encumbered by corporate consensus
Simplicity does not precede complexity, but follows it. 
	- http://www.cs.yale.edu/homes/perlis-alan/quotes.html


From guido@python.org  Wed Oct 25 20:14:57 2000
From: guido@python.org (Guido van Rossum)
Date: Wed, 25 Oct 2000 14:14:57 -0500
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: Your message of "Wed, 25 Oct 2000 14:06:50 -0400."
 <14839.8506.304295.908264@cj42289-a.reston1.va.home.com>
References: <200010251225.HAA22242@cj20424-a.reston1.va.home.com> <LNBBLJKPBEHFEDALKOLCIEMOHMAA.tim_one@email.msn.com> <20001025101142.B8625@ActiveState.com> <200010251821.NAA30247@cj20424-a.reston1.va.home.com> <14838.57838.841831.632628@bitdiddle.concentric.net> <200010251850.NAA30475@cj20424-a.reston1.va.home.com>
 <14839.8506.304295.908264@cj42289-a.reston1.va.home.com>
Message-ID: <200010251914.OAA30720@cj20424-a.reston1.va.home.com>

>  > Why not?  Because if every app using Tcl/Tk did that there would be
>  > hundreds of copies of Tcl/Tk on your disk?  I don't think that
>  > argument flies; only a few other major languages use Tcl/Tk this was,
> 
> So should every application written in Python install it's own copy
> of Python, since there may be unexpected incompatibilities between
> versions?

Of course not, but large and important ones may.  Some already do,
e.g. Alice, Zope, Ultraseek.  I have no problem with this.  (The
saving grace is that none of these needs to recursively include
Tcl. :-)

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


From gvwilson@nevex.com  Wed Oct 25 19:17:24 2000
From: gvwilson@nevex.com (Greg Wilson)
Date: Wed, 25 Oct 2000 14:17:24 -0400 (EDT)
Subject: [Python-Dev] Gradual migration
In-Reply-To: <39F72256.C7F93BFB@prescod.net>
Message-ID: <Pine.LNX.4.10.10010251415580.10577-100000@akbar.nevex.com>

> Paul Prescod:
> Anyhow, integrating C++ and Python is not really so hard, in my experience.

...unless you are using heavily-templated code, e.g. every damn class you've
been asked to wrap up seems to be derived from something in the STL...

Greg



From cgw@fnal.gov  Wed Oct 25 19:18:56 2000
From: cgw@fnal.gov (Charles G Waldman)
Date: Wed, 25 Oct 2000 13:18:56 -0500 (CDT)
Subject: [Python-Dev] Miscellaneous comments on Tkinter and related matters
In-Reply-To: <39F723E8.2AC6787@prescod.net>
References: <200010251458.JAA77237@starbase.neosoft.com>
 <14838.64730.225260.148853@buffalo.fnal.gov>
 <39F723E8.2AC6787@prescod.net>
Message-ID: <14839.9232.950919.629446@buffalo.fnal.gov>

Paul Prescod writes:
 > 
 > Would Mac users go for: "first install X. Then you can run Python."
 > 

I should probably just shut up, because I really don't know enough
about Mac OS X, but what I was wondering is whether OS X will actually
*use* the X Window System.  Of course we don't want to tell users that
they have to go install X on their own.



From tim_one@email.msn.com  Wed Oct 25 19:18:55 2000
From: tim_one@email.msn.com (Tim Peters)
Date: Wed, 25 Oct 2000 14:18:55 -0400
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: <14839.8506.304295.908264@cj42289-a.reston1.va.home.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCGENHHMAA.tim_one@email.msn.com>

[Guido]
> Why not?  Because if every app using Tcl/Tk did that there would be
> hundreds of copies of Tcl/Tk on your disk?  I don't think that
> argument flies; only a few other major languages use Tcl/Tk this was,

[Fred Drake]
>   So should every application written in Python install it's own copy
> of Python, since there may be unexpected incompatibilities between
> versions?

So long as Python doesn't guarantee binary compatibility across releases,
that's the only thing that works.  Play PySol lately <wink>?




From paul@prescod.net  Wed Oct 25 19:27:33 2000
From: paul@prescod.net (Paul Prescod)
Date: Wed, 25 Oct 2000 11:27:33 -0700
Subject: [Python-Dev] Miscellaneous comments on Tkinter and related matters
References: <200010251458.JAA77237@starbase.neosoft.com>
 <14838.64730.225260.148853@buffalo.fnal.gov>
 <39F723E8.2AC6787@prescod.net> <14839.9232.950919.629446@buffalo.fnal.gov>
Message-ID: <39F72615.40B38862@prescod.net>

Charles G Waldman wrote:
> 
>...
> 
> I should probably just shut up, because I really don't know enough
> about Mac OS X, but what I was wondering is whether OS X will actually
> *use* the X Window System.  Of course we don't want to tell users that
> they have to go install X on their own.

And become just another Unix? Then how would they get people to pay the
Macintosh usability premium?

Seriously, maybe someday as a "Linux compatibility mode" but I don't
think it is officially proposed.

-- 
 Paul Prescod - Not encumbered by corporate consensus
Simplicity does not precede complexity, but follows it. 
	- http://www.cs.yale.edu/homes/perlis-alan/quotes.html


From paul@prescod.net  Wed Oct 25 19:30:34 2000
From: paul@prescod.net (Paul Prescod)
Date: Wed, 25 Oct 2000 11:30:34 -0700
Subject: Integer division revisited (was Re: [Python-Dev] Gradual migration)
References: <m13nynX-000Dm8C@artcom0.artcom-gmbh.de>
Message-ID: <39F726CA.9D472E50@prescod.net>

Peter Funk wrote:
> 
> ..
> 
> Bruce Sherwood and David Scherer suggested a IMHO very clever solution to
> this particular problem in March/April this year.  This thread was first
> posted to idle-dev and afterwards X-posted to python-dev:
> 
> http://www.python.org/pipermail/idle-dev/2000-April/000138.html
> http://www.python.org/pipermail/idle-dev/2000-April/000140.html
> http://www.python.org/pipermail/python-dev/2000-April/010029.html
 
Tim's last message on it doesn't sound overwhelmingly positiive to me!
Also, don't forget that Python is also a command line so "version
pragmas" cause additional complexity there.

-- 
 Paul Prescod
Simplicity does not precede complexity, but follows it. 
	- http://www.cs.yale.edu/homes/perlis-alan/quotes.html


From DavidA@ActiveState.com  Wed Oct 25 19:59:35 2000
From: DavidA@ActiveState.com (David Ascher)
Date: Wed, 25 Oct 2000 11:59:35 -0700 (Pacific Daylight Time)
Subject: [Python-Dev] build problems under Solaris
In-Reply-To: <14838.58122.920099.787981@bitdiddle.concentric.net>
Message-ID: <Pine.WNT.4.21.0010251159020.1360-100000@loom>

On Wed, 25 Oct 2000, Jeremy Hylton wrote:

> There are two bug reports about build problems under Solaris (117508
> and 117606).  I don't have access to a Solaris machine, so I can't do
> anything to help these users.  Since ActivePython is shipped for
> Solaris, I assume that you (or someone else at AS) does have access to
> a Solaris machine.  Can you take a look at these problems?  Or assign
> them to someone else who can?

Sure, we'll take a look.  

--david



From akuchlin@mems-exchange.org  Wed Oct 25 22:51:40 2000
From: akuchlin@mems-exchange.org (Andrew Kuchling)
Date: Wed, 25 Oct 2000 17:51:40 -0400
Subject: [Python-Dev] 2.0 articles
Message-ID: <E13oYSS-00071f-00@kronos.cnri.reston.va.us>

I'd like to begin writing an article about 2.0's Unicode support.
Before beginning, has anyone else already begun this task?  If yes,
please let me know...

(Incidentally, did a 2.0 press release ever go out?  Is someone going
to write one?)

--amk


From MarkH@ActiveState.com  Wed Oct 25 23:18:27 2000
From: MarkH@ActiveState.com (Mark Hammond)
Date: Thu, 26 Oct 2000 09:18:27 +1100
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: <200010251821.NAA30247@cj20424-a.reston1.va.home.com>
Message-ID: <ECEPKNMJLHAPFFJHDOJBCEOADOAA.MarkH@ActiveState.com>

[Trent]
> > ...Or anybody installing ActivePython for that matter. We
> > give instructions that the latest version of Tcl/Tk has to
> > be installed separately, but Tk is *not* bundled with it.

[Guido]
> And that's a shame.  Any chance that will be fixed any time soon?

Not presuming to speak for anyone, least of all the ActivePython product
manager :-)

I don't think it will be "fixed", as it is not considered "broken".  It was
an explicit choice to leave out Tcl/Tk.  And my recollection is that the
"feedback" address sees more requests for wxPython than Tcl/Tk.

We make it pretty clear Tcl/Tk is not included - I assume that everyone who
cares about that simply uses BeOpen releases or source tarballs.

[When I say "wont be fixed", I mean it is unlikely to appear in the core
ActivePython release.  It almost certainly will be supported as an add-on,
whatever that turns out to mean exactly ;-]

Mark.



From guido@python.org  Thu Oct 26 01:15:31 2000
From: guido@python.org (Guido van Rossum)
Date: Wed, 25 Oct 2000 19:15:31 -0500
Subject: [Python-Dev] 2.0 articles
In-Reply-To: Your message of "Wed, 25 Oct 2000 17:51:40 -0400."
 <E13oYSS-00071f-00@kronos.cnri.reston.va.us>
References: <E13oYSS-00071f-00@kronos.cnri.reston.va.us>
Message-ID: <200010260015.TAA02798@cj20424-a.reston1.va.home.com>

> (Incidentally, did a 2.0 press release ever go out?  Is someone going
> to write one?)

No; and not me...

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


From MarkH@ActiveState.com  Thu Oct 26 00:29:52 2000
From: MarkH@ActiveState.com (Mark Hammond)
Date: Thu, 26 Oct 2000 10:29:52 +1100
Subject: [Python-Dev] sys.__stdout__ - was RE: [Idle-dev] Doc Commentary
In-Reply-To: <200010251513.KAA28803@cj20424-a.reston1.va.home.com>
Message-ID: <ECEPKNMJLHAPFFJHDOJBOEOFDOAA.MarkH@ActiveState.com>

[From a mail in idle-dev - dropped idle-dev and all CCs]

[idle-dev poster]
> > >>> import sys
> > >>> f = open('some-output-file', 'w')
> > >>> sys.stdout = f
> > >>> # do some stuff
> > >>> sys.stdout = sys.__stdout__
> >
> > Because on entry, sys.stdout is already redirected
> > (not reflected in sys.__stdout__)

[Guido]

> Where did you get this idiom?  You should never use sys.__stdout__
> this way!  The proper idiom is
>
>   save_stdout = sys.stdout
>   try:
>       sys.stdout = f
>       # do some stuff
>   finally:
>       sys.stdout = save_stdout
>
> If you know of any places that are promoting direct use of __stdout__,
> please let them know this is wrong.  If you are contemplating to use
> this in code examples you intend to distribute, please don't!

I admit that I first became aware of sys.__stdout__ after seeing this exact
same idiom in other peoples code.  I always assumed that this is _exactly_
what sys.__stdout__ was to be used for!

The following examples exist:

* Tools/unicode/makeunicodedata.py - exactly the idiom you despise.
* Tools/il8n/pygettext.py - ditto
* Tools/idle/PyParse.py - disabled, debugging output function - presumably
to get around sys.stdout redirection - but this sounds suspect as an idiom
to me too!

So what _is_ it intended for?

Mark.



From greg@cosc.canterbury.ac.nz  Thu Oct 26 01:16:02 2000
From: greg@cosc.canterbury.ac.nz (Greg Ewing)
Date: Thu, 26 Oct 2000 13:16:02 +1300 (NZDT)
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: <200010251353.IAA28190@cj20424-a.reston1.va.home.com>
Message-ID: <200010260016.NAA28387@s454.cosc.canterbury.ac.nz>

> If you started with basic Tkinter widgets, sure, it looks different
> than anything else.  But that depends on the widget layout in the
> program, not on the widget library used!

This is one of my main gripes about the Tk API.  The default
behaviours of all its layout managers suck. In order to get a layout
that looks pleasant and/or conforms to some style guide, you have to
set a whole slew of options every time you place a widget.

Greg Ewing, Computer Science Dept, +--------------------------------------+
University of Canterbury,	   | A citizen of NewZealandCorp, a	  |
Christchurch, New Zealand	   | wholly-owned subsidiary of USA Inc.  |
greg@cosc.canterbury.ac.nz	   +--------------------------------------+


From barry@wooz.org  Thu Oct 26 01:17:38 2000
From: barry@wooz.org (Barry A. Warsaw)
Date: Wed, 25 Oct 2000 20:17:38 -0400 (EDT)
Subject: [Python-Dev] sys.__stdout__ - was RE: [Idle-dev] Doc Commentary
References: <200010251513.KAA28803@cj20424-a.reston1.va.home.com>
 <ECEPKNMJLHAPFFJHDOJBOEOFDOAA.MarkH@ActiveState.com>
Message-ID: <14839.30754.217582.20441@anthem.concentric.net>

>>>>> "MH" == Mark Hammond <MarkH@ActiveState.com> writes:

    MH> * Tools/il8n/pygettext.py

That's embarassing. ;)

Here's a patch, but I'm not going to check it in because I think a
/much/ better idiom to adopt is to use extended print instead.  I need
to make some updates to pygettext.py soon, so I'll probably just
2.0-ify it at the same time.

-Barry

-------------------- snip snip --------------------
Index: pygettext.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Tools/i18n/pygettext.py,v
retrieving revision 1.9
diff -u -r1.9 pygettext.py
--- pygettext.py	2000/05/02 19:28:30	1.9
+++ pygettext.py	2000/10/26 00:16:22
@@ -283,6 +283,7 @@
         options = self.__options
         timestamp = time.ctime(time.time())
         # common header
+        stdout = sys.stdout
         try:
             sys.stdout = fp
             # The time stamp in the header doesn't have the same format
@@ -314,7 +315,7 @@
                 print 'msgid', normalize(k)
                 print 'msgstr ""\n'
         finally:
-            sys.stdout = sys.__stdout__
+            sys.stdout = stdout
 
 
 def main():


From gmcm@hypernet.com  Thu Oct 26 01:39:14 2000
From: gmcm@hypernet.com (Gordon McMillan)
Date: Wed, 25 Oct 2000 20:39:14 -0400
Subject: [Python-Dev] sys.__stdout__ - was RE: [Idle-dev] Doc Commentary
In-Reply-To: <ECEPKNMJLHAPFFJHDOJBOEOFDOAA.MarkH@ActiveState.com>
References: <200010251513.KAA28803@cj20424-a.reston1.va.home.com>
Message-ID: <39F744F2.17759.4FC8E6D4@localhost>

> [Guido]
> 
> > Where did you get this idiom?  You should never use sys.__stdout__
> > this way!  The proper idiom is
> >
> >   save_stdout = sys.stdout
> >   try:
> >       sys.stdout = f
> >       # do some stuff
> >   finally:
> >       sys.stdout = save_stdout
[Mark]
> So what _is_ it intended for?

A fail-safe. The recommended idiom might also be called 
"plays well with others"; a barbarian notion that fortunately has 
not infected most import hacks or program exits...

works-for-me-so-buzz-off-ly y'rs

- Gordon


From akuchlin@mems-exchange.org  Thu Oct 26 03:40:03 2000
From: akuchlin@mems-exchange.org (Andrew Kuchling)
Date: Wed, 25 Oct 2000 22:40:03 -0400
Subject: [Python-Dev] 2.0 press release
In-Reply-To: <200010260015.TAA02798@cj20424-a.reston1.va.home.com>; from guido@python.org on Wed, Oct 25, 2000 at 07:15:31PM -0500
References: <E13oYSS-00071f-00@kronos.cnri.reston.va.us> <200010260015.TAA02798@cj20424-a.reston1.va.home.com>
Message-ID: <20001025224003.A27300@kronos.cnri.reston.va.us>

On Wed, Oct 25, 2000 at 07:15:31PM -0500, Guido van Rossum wrote:
>> (Incidentally, did a 2.0 press release ever go out?  Is someone going
>> to write one?)
>No; and not me...

Little-known fact: Guido actually does nothing but sit in his pyjamas
(with feet!)  all day, drinking cocoa, eating Hostess Twinkies and
watching Tiny Toons, while his long-suffering co-workers implement and
debug the fantastically complex algorithms that go into Python.

Here's some rough text: Can someone with a clue about writing a good
press release give this a look?

--amk


Reston, VA, Oct 25 2000: The Python development team today announced
the release of version 2.0 of the Python programming language.
Version 2.0 adds a number of significant new features:

	* Unicode support, in the form of a new Unicode data type,
	library additions for conversion to/from various encodings,
	and support for displaying Unicode strings in Tk widgets.

	* New language features: garbage collection of cycles, list
	comprehensions, augmented assignment, string methods.

	* Distutils, a new system for making Python modules and
	extensions easily available to a wider audience with very
	little overhead for build/release/install mechanics.

	* Improved XML support, including support for the Simple API
	for XML (SAX2), a miniature Document Object Model (DOM), and
	the Expat parser.

	* Many library improvements, including HTTP/1.1 support, an
	enhanced curses module, the ability to read and write
	ZIP-format files, support for the Windows registry, and many
	more minor improvements.

	* Ports to new platforms: 64-bit Windows on the Itanium
	processor, Windows CE, and Darwin/MacOS X.
	
Python is an interpreted, object-oriented, high-level programming
language.  Its high-level built in data structures, combined with
dynamic typing and dynamic binding, make it very attractive for rapid
application development, as well as for use as a scripting or glue
language to connect existing components together.  Python's simple,
easy to learn syntax emphasizes readability and therefore reduces the
cost of program maintenance, and it supports modules and packages,
encouraging program modularity and code reuse.  

Many extension modules for Python have been written to interface 
with other libraries and applications.  Some of the available modules
include:

	* Support for many relational databases (Oracle, Sybase, MySQL)
	* GUI toolkits (Tk, Windows MFC, wxWindows, KDE, GNOME)
	* Internet protocols (LDAP, WebDAV, XML-RPC, SOAP)
	* Mathematics (Numeric Python)

Python is used for many different purposes, particularly
cross-platform rapid development, Web development, and scripting of
scientific applications.  Some of the applications using Python
include:

	* Zope, the leading Open Source web application server
	* The Mailman mailing list manager
	* The Reportlab PDF document generation toolset
	* XXX suggestions?

XXX too darn many lists here?

<Insert 4 or 5 quotations from various people here.  
 Possible people: someone from Digital Creations, PythonWare,
	          Reportlabs, ActiveState/O'Reilly, TheKompany,
	          Infoseek, Red Hat, a developer from some well-known
	          free software project that uses Python>

The Python interpreter and the extensive standard library are
available free of charge and are distributed under an open-source
license.  Ports have been made to all major platforms, such as
Windows, MacOS, and many Unix variants (Linux, Solaris, FreeBSD, etc.)
New versions are developed collaboratively by a core group of over 20
developers.

About BeOpen:
  <get text for this>

About Python:

   More information about Python can be obtained from the official Python
   website, http://www.python.org. 

(XXX Do you include About sections for the companies that provide quotes?)

Press contacts:
XXX whose address?



From guido@python.org  Thu Oct 26 05:02:11 2000
From: guido@python.org (Guido van Rossum)
Date: Wed, 25 Oct 2000 23:02:11 -0500
Subject: [Python-Dev] sys.__stdout__
In-Reply-To: Your message of "Thu, 26 Oct 2000 10:29:52 +1100."
 <ECEPKNMJLHAPFFJHDOJBOEOFDOAA.MarkH@ActiveState.com>
References: <ECEPKNMJLHAPFFJHDOJBOEOFDOAA.MarkH@ActiveState.com>
Message-ID: <200010260402.XAA03016@cj20424-a.reston1.va.home.com>

> So what _is_ it intended for?

Example: IDLE redirects sys.stderr so that it gets displayed in the
Python Shell window with a different text color.  But occasionally I
need to debug IDLE and the bug is in the text drawing.  Then it's nice
if I can write to __stderr__, which goes to the console.

Or suppose I'm in a regular interactive session and I've managed to
screw myself by assigning a bogus file object to sys.stdout (it
happens :-).  If I know that, I can type sys.stdout = sys.__stdout__
at the >>> prompt and save myself -- so I don't have to restart the
session and perhaps lose valuable data.

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


From fdrake@acm.org  Thu Oct 26 04:55:13 2000
From: fdrake@acm.org (Fred L. Drake, Jr.)
Date: Wed, 25 Oct 2000 23:55:13 -0400 (EDT)
Subject: [Python-Dev] sys.__stdout__ - was RE: [Idle-dev] Doc Commentary
In-Reply-To: <ECEPKNMJLHAPFFJHDOJBOEOFDOAA.MarkH@ActiveState.com>
References: <200010251513.KAA28803@cj20424-a.reston1.va.home.com>
 <ECEPKNMJLHAPFFJHDOJBOEOFDOAA.MarkH@ActiveState.com>
Message-ID: <14839.43809.850142.50138@cj42289-a.reston1.va.home.com>

Mark Hammond writes:
 > * Tools/unicode/makeunicodedata.py - exactly the idiom you despise.
 > * Tools/il8n/pygettext.py - ditto

  I've just fixed these two; too bad checkin messages aren't getting
sent.  ;(

 > * Tools/idle/PyParse.py - disabled, debugging output function - presumably
 > to get around sys.stdout redirection - but this sounds suspect as an idiom
 > to me too!

  I've left this one for someone with a good idea about what to do
about it.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at acm.org>
PythonLabs Team Member



From fdrake@acm.org  Thu Oct 26 05:31:33 2000
From: fdrake@acm.org (Fred L. Drake, Jr.)
Date: Thu, 26 Oct 2000 00:31:33 -0400 (EDT)
Subject: [Python-Dev] Re: [Bug #117070] README instructions for configuring Setup are not helpful
In-Reply-To: <20001025222406.A8389@snowy.squish.net>
References: <200010251752.KAA02444@sf-web2.i.sourceforge.net>
 <20001025222406.A8389@snowy.squish.net>
Message-ID: <14839.45989.450533.514732@cj42289-a.reston1.va.home.com>

[Moved over from a discussion in the bugs list; this relates to bug:
 http://sourceforge.net/bugs/?func=detailbug&bug_id=117070&group_id=5470
 Please be sure to CC: Jon on all replies.]

Jon Ribbens writes:
 > Why the Setup.in/Setup thing at all? Just copying Setup.in to Setup without
 > changes is unexpected enough to warrant mentioning in a paragraph of its
 > own, completely explicitly. The '.in' suffix is usually used for files which
 > autoconf is going to use to create a new file from - you cannot usually
 > simply copy the file yourself. An experienced admin installing Python is
 > more likely to believe the README is wrong than what it tells them to do
 > is correct. Why does the Setup.in file exist in the first place? Surely it
 > should be named 'Setup.dist' (and an identical file 'Setup' exist right from
 > the start).

  Ok, here's the plan:  Change Setup.in to Setup.dist, and provide a
copy as Setup.  Since this doesn't help if the source and build
directories differ, configure.in can be modified to create Setup if
(and only if!) it doesn't exist, by copying it from $srcdir/Modules/.
  I have the changes to configure.in, configure, Setup*, and
Modules/Makefile.pre.in ready, but I still need to update the
instructions in the README & possibly elsewhere.
  Does this sound agreeable?


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at acm.org>
PythonLabs Team Member



From effbot@telia.com  Thu Oct 26 08:15:45 2000
From: effbot@telia.com (Fredrik Lundh)
Date: Thu, 26 Oct 2000 09:15:45 +0200
Subject: [Python-Dev] sys.__stdout__ - was RE: [Idle-dev] Doc Commentary
References: <ECEPKNMJLHAPFFJHDOJBOEOFDOAA.MarkH@ActiveState.com>
Message-ID: <002f01c03f1c$9d721ef0$3c6340d5@hagrid>

mark wrote:
> > If you know of any places that are promoting direct use of __stdout__,
> > please let them know this is wrong.  If you are contemplating to use
> > this in code examples you intend to distribute, please don't!
> 
> I admit that I first became aware of sys.__stdout__ after seeing this exact
> same idiom in other peoples code.  I always assumed that this is _exactly_
> what sys.__stdout__ was to be used for!
> 
> The following examples exist:

and several examples in the eff-bot guide.

guess I'll have to fix it in the second edition...

</F>



From ping@lfw.org  Thu Oct 26 09:09:44 2000
From: ping@lfw.org (Ka-Ping Yee)
Date: Thu, 26 Oct 2000 01:09:44 -0700 (PDT)
Subject: [Python-Dev] getting at the current frame
In-Reply-To: <14837.60682.437334.797392@anthem.concentric.net>
Message-ID: <Pine.LNX.4.10.10010252356410.7079-100000@skuld.kingmanhall.org>

On Tue, 24 Oct 2000, Barry A. Warsaw wrote:
> 
> Okay, we all know that's a pain, right?  Lots of people have proposed
> solutions.  I've looked briefly at !?ng's Itpl.py, but I think it
> probably does too much by adding evaluation.

Do you think a variant of Itpl that only looked up variable names
would solve your problem?

> I can define _() to make the problem somewhat more convenient:
> 
>     def _(s):
> 	try:
> 	    raise Exception
> 	except Exception:
> 	    frame = sys.exc_info()[2].tb_frame.f_back
> 	d = frame.f_globals.copy()
> 	d.update(frame.f_locals())
> 	return the_translation_of(s) % d

How about this routine to get the current frame: inspect.currentframe().

Could i humbly re-request approval for inspect.py in the standard library?

    http://lfw.org/python/inspect.py

It's been up there for a long time, there's lots of good stuff in it,
and previous feedback on this list has all been fairly positive --
there just hasn't been an explicit approval for inclusion.  This is
probably because we were busy trying to get 2.0 released (even though
inspect.py was proposed here before ascii.py, and ascii.py did get
accepted).

I think the functionality it provides is important to supporting the
language definition.  It abstracts away the special secret attributes
and protects us from future changes in the internals.

If there are changes that need to be made before it can be accepted,
i'd be happy to make them.


-- ?!ng



From effbot@telia.com  Thu Oct 26 09:36:14 2000
From: effbot@telia.com (Fredrik Lundh)
Date: Thu, 26 Oct 2000 10:36:14 +0200
Subject: [Python-Dev] getting at the current frame
References: <Pine.LNX.4.10.10010252356410.7079-100000@skuld.kingmanhall.org>
Message-ID: <014501c03f27$cec2ef10$3c6340d5@hagrid>

> Could i humbly re-request approval for inspect.py in the standard library?
> 
>     http://lfw.org/python/inspect.py
> 
> It's been up there for a long time

hey, you still haven't fixed the *2 bug...

> I think the functionality it provides is important to supporting the
> language definition.  It abstracts away the special secret attributes
> and protects us from future changes in the internals.

agreed.

> inspect.py was proposed here before ascii.py, and ascii.py did get
> accepted

as part of the curses package, yes.

</F>



From ping@lfw.org  Thu Oct 26 09:53:56 2000
From: ping@lfw.org (Ka-Ping Yee)
Date: Thu, 26 Oct 2000 01:53:56 -0700 (PDT)
Subject: [Python-Dev] getting at the current frame
In-Reply-To: <014501c03f27$cec2ef10$3c6340d5@hagrid>
Message-ID: <Pine.LNX.4.10.10010260153110.7079-100000@skuld.kingmanhall.org>

On Thu, 26 Oct 2000, Fredrik Lundh wrote:
> > It's been up there for a long time
> 
> hey, you still haven't fixed the *2 bug...

Sorry -- looks like an older version than the one i have on my local
disk, which did get fixed.  The one on the website is now up to date.

    http://lfw.org/python/inspect.py


-- ?!ng



From jon+sourceforge@unequivocal.co.uk  Thu Oct 26 10:39:01 2000
From: jon+sourceforge@unequivocal.co.uk (Jon Ribbens)
Date: Thu, 26 Oct 2000 10:39:01 +0100
Subject: [Python-Dev] Re: [Bug #117070] README instructions for configuring Setup are not helpful
In-Reply-To: <14839.45989.450533.514732@cj42289-a.reston1.va.home.com>; from fdrake@acm.org on Thu, Oct 26, 2000 at 12:31:33AM -0400
References: <200010251752.KAA02444@sf-web2.i.sourceforge.net> <20001025222406.A8389@snowy.squish.net> <14839.45989.450533.514732@cj42289-a.reston1.va.home.com>
Message-ID: <20001026103901.A11873@snowy.squish.net>

"Fred L. Drake, Jr." <fdrake@acm.org> wrote:
>   Ok, here's the plan:  Change Setup.in to Setup.dist, and provide a
> copy as Setup.  Since this doesn't help if the source and build
> directories differ, configure.in can be modified to create Setup if
> (and only if!) it doesn't exist, by copying it from $srcdir/Modules/.
>   Does this sound agreeable?

Sounds cool. I would mention in the first part of the install instructions
about the Setup file, that you edit it to change the available modules
(this concept is not obvious if you don't know how Python works!),
that you can edit it now but if you have not installed Python before it is
best to try building without editing it first and that there are more
instructions further down the README. You might like to mention 'readline'
here too to head-off newsgroup questions about why up-arrow doesn't work ;-).

Cheers


Jon


From guido@python.org  Thu Oct 26 12:38:34 2000
From: guido@python.org (Guido van Rossum)
Date: Thu, 26 Oct 2000 06:38:34 -0500
Subject: [Python-Dev] sys.__stdout__
In-Reply-To: Your message of "Wed, 25 Oct 2000 23:55:13 -0400."
 <14839.43809.850142.50138@cj42289-a.reston1.va.home.com>
References: <200010251513.KAA28803@cj20424-a.reston1.va.home.com> <ECEPKNMJLHAPFFJHDOJBOEOFDOAA.MarkH@ActiveState.com>
 <14839.43809.850142.50138@cj42289-a.reston1.va.home.com>
Message-ID: <200010261138.GAA04678@cj20424-a.reston1.va.home.com>

>  > * Tools/idle/PyParse.py - disabled, debugging output function - presumably
>  > to get around sys.stdout redirection - but this sounds suspect as an idiom
>  > to me too!
> 
> I've left this one for someone with a good idea about what to do
> about it.

Don't touch it!  This one is needed because at this point sys.stdout
and sys.stderr are redirected to a window where you don't want the
parser debug output to show up.  (I mentioned this example in my
previous post.)

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


From guido@python.org  Thu Oct 26 12:45:49 2000
From: guido@python.org (Guido van Rossum)
Date: Thu, 26 Oct 2000 06:45:49 -0500
Subject: [Python-Dev] Re: [Bug #117070] README instructions for configuring Setup are not helpful
In-Reply-To: Your message of "Thu, 26 Oct 2000 00:31:33 -0400."
 <14839.45989.450533.514732@cj42289-a.reston1.va.home.com>
References: <200010251752.KAA02444@sf-web2.i.sourceforge.net> <20001025222406.A8389@snowy.squish.net>
 <14839.45989.450533.514732@cj42289-a.reston1.va.home.com>
Message-ID: <200010261145.GAA04767@cj20424-a.reston1.va.home.com>

[Fred]
>   Ok, here's the plan:  Change Setup.in to Setup.dist, and provide a
> copy as Setup.  Since this doesn't help if the source and build
> directories differ, configure.in can be modified to create Setup if
> (and only if!) it doesn't exist, by copying it from $srcdir/Modules/.
>   I have the changes to configure.in, configure, Setup*, and
> Modules/Makefile.pre.in ready, but I still need to update the
> instructions in the README & possibly elsewhere.
>   Does this sound agreeable?

Sure, except I'm not comfortable with having two files with identical
contents under CVS control.  How about not checking in Setup, but
creating it in configure if it doesn't exist?

This is necessary also for the following reason: when you build in a
different tree than the source tree, you should get a fresh copy of
Setup in the build tree -- another copy of Setup in the source tree is
useless.

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


From guido@python.org  Thu Oct 26 12:48:20 2000
From: guido@python.org (Guido van Rossum)
Date: Thu, 26 Oct 2000 06:48:20 -0500
Subject: [Python-Dev] getting at the current frame
In-Reply-To: Your message of "Thu, 26 Oct 2000 01:09:44 MST."
 <Pine.LNX.4.10.10010252356410.7079-100000@skuld.kingmanhall.org>
References: <Pine.LNX.4.10.10010252356410.7079-100000@skuld.kingmanhall.org>
Message-ID: <200010261148.GAA04780@cj20424-a.reston1.va.home.com>

> Could i humbly re-request approval for inspect.py in the standard library?
> 
>     http://lfw.org/python/inspect.py

To avoid that we forget about this again, and to make sure it gets
proper treatment, could you submit it through the patch manager?  No
need to turn it into a context diff, just upload the entire file.

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


From thomas@xs4all.net  Thu Oct 26 11:21:05 2000
From: thomas@xs4all.net (Thomas Wouters)
Date: Thu, 26 Oct 2000 12:21:05 +0200
Subject: [Python-Dev] A small step to removing the type/class split
In-Reply-To: <200010250114.OAA28255@s454.cosc.canterbury.ac.nz>; from greg@cosc.canterbury.ac.nz on Wed, Oct 25, 2000 at 02:14:52PM +1300
References: <20001024073712.A10539@glacier.fnational.com> <200010250114.OAA28255@s454.cosc.canterbury.ac.nz>
Message-ID: <20001026122105.N12812@xs4all.nl>

On Wed, Oct 25, 2000 at 02:14:52PM +1300, Greg Ewing wrote:
> Neil Schemenauer <nas@arctrix.com>:

> > Those PyInstance_Check() calls should really go away. Instead, the
> > type should be responsible for providing different behavior.

> Yes, that's the crux of the problem, I think.

> Another place where this is a nuisance is where it
> assumes that if x has any tp_as_sequence slots and y
> has any tp_as_number slots, then x*y is a sequence
> replication operation.

This is screwed in more than one way. The logic of which 'type' operation
has precedence isn't even internally consistent. The case of 'x*y' and 'x+y'
check the tp_as_number and tp_as_sequence slots in a *different order*, so
'x*y' can end up a number where 'x+y' ends up a sequence. (Or the other way
'round, I forget. I'm also struggling to catch up on my mail since Apachecon
had little to no connectivity, so I don't feel like checking :)

Brainwashed-into-Apache-2.0-forever-ly y'rs,
-- 
Thomas Wouters <thomas@xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!


From thomas@xs4all.net  Thu Oct 26 11:51:30 2000
From: thomas@xs4all.net (Thomas Wouters)
Date: Thu, 26 Oct 2000 12:51:30 +0200
Subject: [Python-Dev] ViewCVS on Sourceforge
Message-ID: <20001026125130.O12812@xs4all.nl>

I had a chat with Greg Stein about ViewCVS on the ApacheCon (I think Jon
Travis and Gregory Trubetskoy where there as well, but my memory is a bit
hazy) and since he's probably in some airplane over the atlantic right now,
I'll run away and steal his idea ;) We were kind of reflecting how nice it
would be if we could have ViewCVS, instead of cvsweb, on SourceForge. The
nice thing about ViewCVS is that it's a lot more efficient than cvsweb, and
it doesn't need write access to the repository itself. So how about we run
ViewCVS on python.sourceforge.net ourselves ?

We could do it now, in fact, with the complete CVS snapshot that gets made
every once in a while (that *does* still get made & backupped, right ?)
though it would obviously be a lot more useful if ViewCVS just had direct
access to the repository. I'm not sure how accessible that repository is,
however. Cursory searches on shell.sourceforge.net doesn't show anything,
except that the python-cvs.tgz that's in /home/projects/python is apparently
the one used for the move to sourceforge :-) Can we get access to the
repository directly, even if it's only semi-realtime ? (I wouldn't mind
doing a couple of rsync's in cron to keep it up to date) If anything,
running ViewCVS will show SourceForge how much nicer it is... ;-)

-- 
Thomas Wouters <thomas@xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!


From jon+sourceforge@unequivocal.co.uk  Thu Oct 26 12:01:27 2000
From: jon+sourceforge@unequivocal.co.uk (Jon Ribbens)
Date: Thu, 26 Oct 2000 12:01:27 +0100
Subject: [Python-Dev] Re: [Bug #117070] README instructions for configuring Setup are not helpful
In-Reply-To: <200010261145.GAA04767@cj20424-a.reston1.va.home.com>; from guido@python.org on Thu, Oct 26, 2000 at 06:45:49AM -0500
References: <200010251752.KAA02444@sf-web2.i.sourceforge.net> <20001025222406.A8389@snowy.squish.net> <14839.45989.450533.514732@cj42289-a.reston1.va.home.com> <200010261145.GAA04767@cj20424-a.reston1.va.home.com>
Message-ID: <20001026120127.B11873@snowy.squish.net>

Guido van Rossum <guido@python.org> wrote:
> Sure, except I'm not comfortable with having two files with identical
> contents under CVS control.  How about not checking in Setup, but
> creating it in configure if it doesn't exist?

I think that would be fine so long as the README file makes it clear that
you edit the Setup file after './configure' but before 'make'.

Cheers


Jon


From mal@lemburg.com  Thu Oct 26 12:23:19 2000
From: mal@lemburg.com (M.-A. Lemburg)
Date: Thu, 26 Oct 2000 13:23:19 +0200
Subject: [Python-Dev] 2.0 articles
References: <E13oYSS-00071f-00@kronos.cnri.reston.va.us>
Message-ID: <39F81427.FF4223C2@lemburg.com>

Andrew Kuchling wrote:
> 
> I'd like to begin writing an article about 2.0's Unicode support.
> Before beginning, has anyone else already begun this task?  If yes,
> please let me know...

I've already started something in that direction. The plan is to
write down the story of adding Unicode support to Python, the
pifalls, solutions, hacks, etc. I'll probably submit it to DDJ.

A article about *using* Unicode support would of course
be a nice complement to get a feeling of how it's like working
with the implementation :-)
 
> (Incidentally, did a 2.0 press release ever go out?  Is someone going
> to write one?)
> 
> --amk
> 
> _______________________________________________
> Python-Dev mailing list
> Python-Dev@python.org
> http://www.python.org/mailman/listinfo/python-dev

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/


From fdrake@acm.org  Thu Oct 26 13:21:08 2000
From: fdrake@acm.org (Fred L. Drake, Jr.)
Date: Thu, 26 Oct 2000 08:21:08 -0400 (EDT)
Subject: [Python-Dev] sys.__stdout__
In-Reply-To: <200010261138.GAA04678@cj20424-a.reston1.va.home.com>
References: <200010251513.KAA28803@cj20424-a.reston1.va.home.com>
 <ECEPKNMJLHAPFFJHDOJBOEOFDOAA.MarkH@ActiveState.com>
 <14839.43809.850142.50138@cj42289-a.reston1.va.home.com>
 <200010261138.GAA04678@cj20424-a.reston1.va.home.com>
Message-ID: <14840.8628.315347.722506@cj42289-a.reston1.va.home.com>

I wrote:
 > I've left this one for someone with a good idea about what to do
 > about it.

Guido van Rossum replied:
 > Don't touch it!  This one is needed because at this point sys.stdout
 > and sys.stderr are redirected to a window where you don't want the
 > parser debug output to show up.

  See, I knew someone would come up with a better idea!  ;)


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at acm.org>
PythonLabs Team Member



From skip@mojam.com (Skip Montanaro)  Thu Oct 26 13:31:36 2000
From: skip@mojam.com (Skip Montanaro) (Skip Montanaro)
Date: Thu, 26 Oct 2000 07:31:36 -0500 (CDT)
Subject: [Python-Dev] Re: [Bug #117070] README instructions for configuring Setup are not helpful
In-Reply-To: <14839.45989.450533.514732@cj42289-a.reston1.va.home.com>
References: <200010251752.KAA02444@sf-web2.i.sourceforge.net>
 <20001025222406.A8389@snowy.squish.net>
 <14839.45989.450533.514732@cj42289-a.reston1.va.home.com>
Message-ID: <14840.9256.408848.728486@beluga.mojam.com>

    Fred> Ok, here's the plan: Change Setup.in to Setup.dist, and provide a
    copy as Setup.

I don't like the idea that a file I am supposed to edit (Setup) would be in
the CVS repository where it could conceivably get messed with by a "cvs up"
command.  The current makefile target that emits a warning if Setup.in
(.dist) is newer than Setup should be sufficient to alert users when Setup
needs to be looked at.

-- 
Skip Montanaro (skip@mojam.com)
http://www.mojam.com/
http://www.musi-cal.com/


From skip@mojam.com (Skip Montanaro)  Thu Oct 26 13:34:09 2000
From: skip@mojam.com (Skip Montanaro) (Skip Montanaro)
Date: Thu, 26 Oct 2000 07:34:09 -0500 (CDT)
Subject: [Python-Dev] getting at the current frame
In-Reply-To: <Pine.LNX.4.10.10010252356410.7079-100000@skuld.kingmanhall.org>
References: <14837.60682.437334.797392@anthem.concentric.net>
 <Pine.LNX.4.10.10010252356410.7079-100000@skuld.kingmanhall.org>
Message-ID: <14840.9409.491061.671168@beluga.mojam.com>

    Ping> Could i humbly re-request approval for inspect.py in the standard
    Ping> library?

    Ping>     http://lfw.org/python/inspect.py

+1.  I've written functions over the years to do some small bits of what
inspect.py does.  I'd much rather have those things in a standard place with
more eyeballs checking them for correctness.

Skip


From akuchlin@mems-exchange.org  Thu Oct 26 13:56:26 2000
From: akuchlin@mems-exchange.org (Andrew Kuchling)
Date: Thu, 26 Oct 2000 08:56:26 -0400
Subject: [Python-Dev] 2.0 articles
In-Reply-To: <39F81427.FF4223C2@lemburg.com>; from mal@lemburg.com on Thu, Oct 26, 2000 at 01:23:19PM +0200
References: <E13oYSS-00071f-00@kronos.cnri.reston.va.us> <39F81427.FF4223C2@lemburg.com>
Message-ID: <20001026085626.A27785@kronos.cnri.reston.va.us>

On Thu, Oct 26, 2000 at 01:23:19PM +0200, M.-A. Lemburg wrote:
>A article about *using* Unicode support would of course
>be a nice complement to get a feeling of how it's like working

And that's what I want to write, so it works out nicely; great!

Finn, your comment has been noted; I'll take note of any differences
with Jython's Unicode support.  A draft will be announced on
python-dev, whenever it actually gets done.

--amk



From mal@lemburg.com  Thu Oct 26 14:07:35 2000
From: mal@lemburg.com (M.-A. Lemburg)
Date: Thu, 26 Oct 2000 15:07:35 +0200
Subject: [Python-Dev] Gradual migration
References: <39F52EF1.A201C6D9@prescod.net> <39F54C0F.25798309@lemburg.com> <39F5B4DC.C226D8F6@prescod.net> <39F5E4FA.9FD6D35@lemburg.com> <39F72256.C7F93BFB@prescod.net>
Message-ID: <39F82C97.12D04C85@lemburg.com>

Paul Prescod wrote:
> 
> "M.-A. Lemburg" wrote:
> >
> > ...
> >
> > >  * implementation language and Python inheritance semantics are almost
> > > completely distinct. After all, we have Python implementations in a
> > > variety of languages with minor incompatibilities. Python could have a
> > > proper type/class merging even if it were written in assembly language.
> > > So let's leave implementation language aside.
> >
> > Hey, think of it as opportunity: we can reuse much of C++'s
> > optimizations and the integration of Python and C++ applications
> > will get *much* easier.
> 
> We could make integrating C++ and Python easier through CXX or Py_Cpp.
> Perhaps we should ship one of those with Python 2.1. Anyhow, integrating
> C++ and Python is not really so hard, in my experience.

Ok, you can use SWIG to get most of the work done, but the interface
between the C++ object world and the Python object world is one
big mess -- all implementations I've seen use shadow objects
or proxies to interface from one to the other... with lots of
temporary objects used for the linkup.

Having Python itself written in C++ we could do *much* better.

But that's only a nice side-effect. The real argument here is
that we can push the type logic one layer further down. Ideal would
be a level of integration such as the one implemented in JPython
or Jython.
 
> > A rewrite shouldn't scare anyone away -- much of the existing
> > code can be reused since only the Python C APIs of the various
> > types will have to be rewritten, not the logic behind the types.
> 
> I wasn't really addressing the issue of backwards compatibility of
> extensions -- I was talking about Python programs. Nevertheless, I can't
> resist:
> 
> Porting your app to the Python APIs is often the majority of the work in
> a particular extension. A lot of Python extensions consist only of API
> glue!

True, but we're lucky, since we could provide a compatibility
layer on top of the new API.

BTW, I think I now know what your main concern is: the Python
level compatibility. I was talking of what goes on under the
hood and still think that Py3K should be used as a chance to
simplify the Python backend. As simplification often means
generalization, we'll open up new doors for future developments
along the way.

> > > I don't know what you mean by a "low-level strategy" for classes. It's
> > > not like we can somehow use C++ vtables without giving up Python's
> > > dynamicity. Python's class handling is about as low-level as it can get
> > > in my humble opinion.
> >
> > With "low-level" I meant trying to build Python classes and
> > instances on top of a very thin layer on top of C++ classes,
> > e.g. all slots could be implemented using true C++ methods with
> > additional logic to override them using dynamically bound
> > Python method objects.
> 
> I don't think that there is really interesting magic in a C++ compiler.
> A vtable is an array of pointers to functions. We've already implemented
> the equivalent in ANSI C. C++ exceptions, constructors, destriuctors and
> smart pointers are a little more interesting from a code maintenance and
> simplicity point of view. But even then I think that we could get to a
> C++ implementation through incremental rewrites.

Naa, the whole type slot interface is one big mess (sorry, Guido :-).
some slots are packaged, some are not, some are NULL, some are not,
there are oodles of sometimes weird dependencies between the
slots which are not really documented, etc. etc.

The slot design has serious drawbacks and should be replaced by
something more reliable, preferably C++ methods. That way, we'll
get some more "type" safety into Python and its extensions.

Note that porting old extensions won't be all that hard: 
a class reusing the existing slot functions as methods should
suffice in many cases.

> > Why spoil all the fun when we haven't even started thinking
> > about all the possibilities we could use to make Py3k a
> > success ?
> 
> Asking for a map of where we are going and how we will get here is
> "spoiling all of the fun?" I'm not sure what you are reacting to -- I
> didn't advise one implementation strategy or another -- I just said that
> we should employ a strategy that minimizes sudden and surprising code
> breakage.

Ok, we've been talking about different things here: with "spoiling
the fun" I meant putting ropes on possible changes to the C 
backend. 

You are talking about the frontend and I agree with you
that there should be a clear upgrade path from the 2.x series
to Py3K w/r to the Python side of things.

So I guess it's time for some PEPs now... the upgrade path
PEP and the fluffy clouds PEP.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/


From guido@python.org  Thu Oct 26 15:42:40 2000
From: guido@python.org (Guido van Rossum)
Date: Thu, 26 Oct 2000 09:42:40 -0500
Subject: [Python-Dev] Re: [Bug #117070] README instructions for configuring Setup are not helpful
In-Reply-To: Your message of "Thu, 26 Oct 2000 12:01:27 +0100."
 <20001026120127.B11873@snowy.squish.net>
References: <200010251752.KAA02444@sf-web2.i.sourceforge.net> <20001025222406.A8389@snowy.squish.net> <14839.45989.450533.514732@cj42289-a.reston1.va.home.com> <200010261145.GAA04767@cj20424-a.reston1.va.home.com>
 <20001026120127.B11873@snowy.squish.net>
Message-ID: <200010261442.JAA05046@cj20424-a.reston1.va.home.com>

> I think that would be fine so long as the README file makes it clear that
> you edit the Setup file after './configure' but before 'make'.

One thing -- it's perfectly fine to edit Setup after running Make for
the first time.  You just have to run Make again.  The Makefiles are
designed for this.

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


From paul@prescod.net  Thu Oct 26 14:56:40 2000
From: paul@prescod.net (Paul Prescod)
Date: Thu, 26 Oct 2000 06:56:40 -0700
Subject: [Python-Dev] Gradual migration
References: <39F52EF1.A201C6D9@prescod.net> <39F54C0F.25798309@lemburg.com> <39F5B4DC.C226D8F6@prescod.net> <39F5E4FA.9FD6D35@lemburg.com> <39F72256.C7F93BFB@prescod.net> <39F82C97.12D04C85@lemburg.com>
Message-ID: <39F83818.38EA64AE@prescod.net>

"M.-A. Lemburg" wrote:
> 
> ...
> 
> Having Python itself written in C++ we could do *much* better.

Agree.

> ...
> 
> The slot design has serious drawbacks and should be replaced by
> something more reliable, preferably C++ methods. That way, we'll
> get some more "type" safety into Python and its extensions.

I agree that the slot stuff is broken but my solution would be to junk
it and use the same mechanism for looking up "type methods" and
"instance methods". I can think of two ways to make that perform
reasonably: one is method caching and the other is by building interface
objects where methods are invoked by index -- basically vtables. But if
the same mechanism is going to accelerate Python and C types alike then
it can't really use C++ vtables because how do you generate a vtable at
runtime for a new Python class? (you could also think of it as a COM
interface object)

> So I guess it's time for some PEPs now... the upgrade path
> PEP and the fluffy clouds PEP.

Good timing. I just finished the first draft of the upgrade path PEP.

-- 
 Paul Prescod - Not encumbered by corporate consensus
Simplicity does not precede complexity, but follows it. 
	- http://www.cs.yale.edu/homes/perlis-alan/quotes.html


From barry@wooz.org  Thu Oct 26 14:24:49 2000
From: barry@wooz.org (Barry A. Warsaw)
Date: Thu, 26 Oct 2000 09:24:49 -0400 (EDT)
Subject: [Python-Dev] getting at the current frame
References: <14837.60682.437334.797392@anthem.concentric.net>
 <Pine.LNX.4.10.10010252356410.7079-100000@skuld.kingmanhall.org>
 <14840.9409.491061.671168@beluga.mojam.com>
Message-ID: <14840.12449.241947.715016@anthem.concentric.net>

>>>>> "SM" == Skip Montanaro <skip@mojam.com> writes:

    Ping> Could i humbly re-request approval for inspect.py in the
    Ping> standard library?

    Ping> http://lfw.org/python/inspect.py

    SM> +1.  I've written functions over the years to do some small
    SM> bits of what inspect.py does.  I'd much rather have those
    SM> things in a standard place with more eyeballs checking them
    SM> for correctness.

I've downloaded it, and will take a look.


From jim@interet.com  Thu Oct 26 15:03:43 2000
From: jim@interet.com (James C. Ahlstrom)
Date: Thu, 26 Oct 2000 10:03:43 -0400
Subject: [Python-Dev] What to choose to replace Tkinter?
References: <14837.14407.954185.466011@buffalo.fnal.gov> <ECEPKNMJLHAPFFJHDOJBKEKIDOAA.MarkH@ActiveState.com> <14837.43273.24692.93965@buffalo.fnal.gov> <20001024114326.E13957@kronos.cnri.reston.va.us>
 <39F6B8B8.E3242929@interet.com> <200010251225.HAA22242@cj20424-a.reston1.va.home.com>
Message-ID: <39F839BF.DD1B86BF@interet.com>

Guido van Rossum wrote:

> To me this all sounds like FUD.

True, but FUD is real and I have no apologies.

> Since Python 1.6 and 2.0, you don't
> have to install Tcl/Tk or its libraries -- it is installed
> *transparently* by the Python Windows installer.

We don't use the Python Windows installer.  Our app
has to use its own installer, and I would then have to run
two installers, one of which I don't understand.

Sorry to be such an old fuddy-duddy, but you will
get the same reaction from most commercial software
vendors.  Make that nearly ALL vendors.

JimA


From jim@interet.com  Thu Oct 26 15:06:02 2000
From: jim@interet.com (James C. Ahlstrom)
Date: Thu, 26 Oct 2000 10:06:02 -0400
Subject: [Python-Dev] What to choose to replace Tkinter?
References: <Pine.LNX.4.10.10010241146450.6622-100000@akbar.nevex.com> <200010241739.MAA16414@cj20424-a.reston1.va.home.com>
 <39F6BA29.3CAB4C0E@interet.com> <200010251227.HAA22256@cj20424-a.reston1.va.home.com>
Message-ID: <39F83A4A.26E543A3@interet.com>

Guido van Rossum wrote:

> Even Microsoft is violating its own (boring) style guide, when they
> think it appeals to a specific audience.  Have you seen their Media
> Player?

Yes, very slick.  My daughter has an app where you click on
doors to access parts of the program.  Nice design.

JimA


From gward@mems-exchange.org  Thu Oct 26 15:18:50 2000
From: gward@mems-exchange.org (Greg Ward)
Date: Thu, 26 Oct 2000 10:18:50 -0400
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: <39F83A4A.26E543A3@interet.com>; from jim@interet.com on Thu, Oct 26, 2000 at 10:06:02AM -0400
References: <Pine.LNX.4.10.10010241146450.6622-100000@akbar.nevex.com> <200010241739.MAA16414@cj20424-a.reston1.va.home.com> <39F6BA29.3CAB4C0E@interet.com> <200010251227.HAA22256@cj20424-a.reston1.va.home.com> <39F83A4A.26E543A3@interet.com>
Message-ID: <20001026101850.A14742@ludwig.cnri.reston.va.us>

On 26 October 2000, James C. Ahlstrom said:
> Guido van Rossum wrote:
> 
> > Even Microsoft is violating its own (boring) style guide, when they
> > think it appeals to a specific audience.  Have you seen their Media
> > Player?
> 
> Yes, very slick.  My daughter has an app where you click on
> doors to access parts of the program.  Nice design.

This is generally considered Bad Form by usability types.  I think it
boils down to this: the computer is not the real world, and trying to
emulate the real world on the computer is cutesy but a dead end.

Go look for "User Interface Hall of Shame" at your friendly
neighbourhood search engine for many enjoyable rants against bad GUI
design, including the "emulate the real world" school of thought.

Anyways, this is not a usability mailing list... back to our regularly
scheduled python-dev...

        Greg
-- 
Greg Ward - software developer                gward@mems-exchange.org
MEMS Exchange / CNRI                           voice: +1-703-262-5376
Reston, Virginia, USA                            fax: +1-703-262-5367


From paul@prescod.net  Thu Oct 26 15:28:12 2000
From: paul@prescod.net (Paul Prescod)
Date: Thu, 26 Oct 2000 07:28:12 -0700
Subject: [Python-Dev] Gradual migration PEP
Message-ID: <39F83F7C.2241158F@prescod.net>

PEP: XXX 
Title: Guidelines for introducing backwards incompatibilities 
Version: $Revision: 1.0 $ 
Author: Paul Prescod <paul@prescod.net,paulp@activestate.com> 
Status: Draft Type: Standards Track 
Python-Version: All
Created: 25-Oct-2000

Abstract

    In the natural evolution of programming languages it is sometimes
    necessary to make changes that modify the behaviour of older
programs.
    This PEP proposes a policy for implementing these changes in a
manner
    respectful of the installed base of Python users.

Implementation Details

    Implementation of this PEP requires the addition of a formal warning
    and deprecation facility that will be described in another proposal.

Scope

    These guidelines apply to future versions of Python that introduce
    backward-incompatible behaviour. Backward incompatible behaviour is
    a major deviation in Python interpretation from an earlier behaviour
    described in the standard Python documentation. Removal of a feature
    also constitutes a change of behaviour.

    This PEP does not replace or preclude other compatibility strategies
    such as dynamic loading of backwards-compatible parsers. On the
    other hand, if execution of "old code" requires a special switch or
    pragma then that is indeed a change of behavior from the point of
    view of the user and that change should be implemented according to
    these guidelines.

    In general, common sense must prevail in the implementation of these
    guidelines. For instance changing "sys.copyright" does not
constitute
    a backwards-incompatible change of behavior!

Steps For Introducting Backwards-Incompatible Features

    1. Propose backwards-incompatible behavior in a PEP. The PEP must
       include a section on backwards compatibility that describes in
       detail a plan to complete the remainder of these steps.

    2. Once the PEP is accepted as a productive direction, implement an
       alternate way to accomplish the task previously provided by the
       feature that is being removed or changed. For instance if the
       addition operator were scheduled for removal, a new version of
       Python could implement an "add()" built-in function.

    3. Formally deprecate the obsolete construct in the Python
       documentation.

    4. Add an an optional warning mode to the parser that will inform
       users when the deprecated construct is used. In other words, all
       programs that will behave differently in the future must trigger
       warnings in this mode. Compile-time warnings are preferable to
       runtime warnings. The warning messages should steer people from
       the deprecated construct to the alternative construct.

    5. There must be at least a one-year transition period between
       the release of the transitional version of Python and the release
       of the backwards incompatible version. Users will have at least
       a year to test their programs and migrate them from use of the
       deprecated construct to the alternative one.


Local Variables: 
mode: indented-text 
indent-tabs-mode: nil 
End:


From paul@prescod.net  Thu Oct 26 15:35:48 2000
From: paul@prescod.net (Paul Prescod)
Date: Thu, 26 Oct 2000 07:35:48 -0700
Subject: [Python-Dev] What to choose to replace Tkinter?
References: <ECEPKNMJLHAPFFJHDOJBCEOADOAA.MarkH@ActiveState.com>
Message-ID: <39F84144.105D1754@prescod.net>

Mark Hammond wrote:
> 
>...
> 
> I don't think it will be "fixed", as it is not considered "broken".  It was
> an explicit choice to leave out Tcl/Tk.  And my recollection is that the
> "feedback" address sees more requests for wxPython than Tcl/Tk.

That's all true. We also make it very easy to find the right version of
Tcl/Tk and will probably go even farther in this direction in the
future. Built-in Tcl/Tk support is not out of the question but there are
various user confusion issues: "Why are there two GUI frameworks in this
development environment? Why are there two development environments in
this development environment? Doesn't ActiveState have yet another GUI
framework and development environment under development?" "Why do I need
Tcl at all? What is its relationship with Python?

There are clear benefits to including Tcl/Tk but there are also costs
and its possible we'll weigh them differently in the future.

BTW: ActivePython does include Tkinter.

-- 
 Paul Prescod
Simplicity does not precede complexity, but follows it. 
	- http://www.cs.yale.edu/homes/perlis-alan/quotes.html


From gmcm@hypernet.com  Thu Oct 26 15:49:20 2000
From: gmcm@hypernet.com (Gordon McMillan)
Date: Thu, 26 Oct 2000 10:49:20 -0400
Subject: [Python-Dev] Gradual migration
In-Reply-To: <39F82C97.12D04C85@lemburg.com>
Message-ID: <39F80C30.5448.52D32F94@localhost>

[Paul]
> > We could make integrating C++ and Python easier through CXX or Py_Cpp.
> > Perhaps we should ship one of those with Python 2.1. Anyhow, integrating
> > C++ and Python is not really so hard, in my experience.

... or a number of others (but SWIG falls very short when it 
comes to things like C++ references)...

[Marc-Andre]
> Ok, you can use SWIG to get most of the work done, but the interface
> between the C++ object world and the Python object world is one
> big mess -- all implementations I've seen use shadow objects
> or proxies to interface from one to the other... with lots of
> temporary objects used for the linkup.

While I agree it's messy, those are not the objectionable 
qualities. Any refcounted C++ system is going to have proxies 
(smart pointers / refcounting stack-safe "reference" objects to 
the real heap-based objects).

And while I think we'd be better off with a C++ implementation, 
I would warn that C++'s notion of inheritence is in conflict with 
Python's. It won't be "as above, so below" (unless we screw 
interpreting and go straight to native code). Assuming that the 
class / type dichotomy actually gets healed, that is.
 
> ... The real argument here is
> that we can push the type logic one layer further down. Ideal would
> be a level of integration such as the one implemented in JPython
> or Jython.

Nope. If you heal the class / type split, there's really only one 
underlying type object. Unless you go the other way, and write 
"native" code (as JPython does).

All of the existing C++ interfaces / helpers deal only with type 
objects (at least, those that I've examined, which is most of 
them). In fact, only ExtensionClass attempts to deal with the 
class / type split, and while it's a masterpiece, I think it's a 
great example of everything to avoid in Py3K.
  


- Gordon


From barry@wooz.org  Thu Oct 26 15:58:23 2000
From: barry@wooz.org (Barry A. Warsaw)
Date: Thu, 26 Oct 2000 10:58:23 -0400 (EDT)
Subject: [Python-Dev] Gradual migration
References: <39F52EF1.A201C6D9@prescod.net>
 <39F54C0F.25798309@lemburg.com>
 <39F5B4DC.C226D8F6@prescod.net>
 <39F5E4FA.9FD6D35@lemburg.com>
 <39F72256.C7F93BFB@prescod.net>
 <39F82C97.12D04C85@lemburg.com>
 <39F83818.38EA64AE@prescod.net>
Message-ID: <14840.18063.152674.534458@anthem.concentric.net>

>>>>> "PP" == Paul Prescod <paul@prescod.net> writes:

    PP> I agree that the slot stuff is broken but my solution would be
    PP> to junk it and use the same mechanism for looking up "type
    PP> methods" and "instance methods". I can think of two ways to
    PP> make that perform reasonably: one is method caching and the
    PP> other is by building interface objects where methods are
    PP> invoked by index -- basically vtables. But if the same
    PP> mechanism is going to accelerate Python and C types alike then
    PP> it can't really use C++ vtables because how do you generate a
    PP> vtable at runtime for a new Python class? (you could also
    PP> think of it as a COM interface object)

Objective-C!

:)


From effbot@telia.com  Thu Oct 26 16:14:28 2000
From: effbot@telia.com (Fredrik Lundh)
Date: Thu, 26 Oct 2000 17:14:28 +0200
Subject: [Python-Dev] What to choose to replace Tkinter?
References: <14837.14407.954185.466011@buffalo.fnal.gov> <ECEPKNMJLHAPFFJHDOJBKEKIDOAA.MarkH@ActiveState.com> <14837.43273.24692.93965@buffalo.fnal.gov> <20001024114326.E13957@kronos.cnri.reston.va.us>              <39F6B8B8.E3242929@interet.com> <200010251225.HAA22242@cj20424-a.reston1.va.home.com> <39F839BF.DD1B86BF@interet.com>
Message-ID: <002a01c03f5f$71ca72f0$3c6340d5@hagrid>

jim wrote:
> Sorry to be such an old fuddy-duddy, but you will
> get the same reaction from most commercial software
> vendors.  Make that nearly ALL vendors.

what reaction?

are you saying that your own installer can install the
Python DLL but not the Tk DLL?

</F>



From gmcm@hypernet.com  Thu Oct 26 16:05:02 2000
From: gmcm@hypernet.com (Gordon McMillan)
Date: Thu, 26 Oct 2000 11:05:02 -0400
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: <20001026101850.A14742@ludwig.cnri.reston.va.us>
References: <39F83A4A.26E543A3@interet.com>; from jim@interet.com on Thu, Oct 26, 2000 at 10:06:02AM -0400
Message-ID: <39F80FDE.6102.52E19102@localhost>

James C. Ahlstrom said:

> > Yes, very slick.  My daughter has an app where you click on
> > doors to access parts of the program.  Nice design.

[Greg Ward] 
> This is generally considered Bad Form by usability types.  I think it
> boils down to this: the computer is not the real world, and trying to
> emulate the real world on the computer is cutesy but a dead end.

I once interviewed with a game designer (sports games - 
popular ones, too). He spent half an hour slamming MS's UI 
(his games run on Windows). Then he pulled up his latest 
(opening to a sports stadium) and said "Now here's a real UI". 
So I said "Show me how it works". 

The bozo ended up clicking on random things on the screen 
until something finally happened.

no-no-the-beer-means-OK--the-bimbo-means-CANCEL-ly y'rs

- Gordon


From barry@wooz.org  Thu Oct 26 16:36:37 2000
From: barry@wooz.org (barry@wooz.org)
Date: Thu, 26 Oct 2000 11:36:37 -0400 (EDT)
Subject: [Python-Dev] getting at the current frame
References: <14837.60682.437334.797392@anthem.concentric.net>
 <Pine.LNX.4.10.10010252356410.7079-100000@skuld.kingmanhall.org>
Message-ID: <14840.20357.734136.911927@anthem.concentric.net>

>>>>> "KY" == Ka-Ping Yee <ping@lfw.org> writes:

    >>  Okay, we all know that's a pain, right?  Lots of people have
    >> proposed solutions.  I've looked briefly at !?ng's Itpl.py, but
    >> I think it probably does too much by adding evaluation.

    KY> Do you think a variant of Itpl that only looked up variable
    KY> names would solve your problem?

I think it would calm my objections, yes.  I'll observe that I think
there may be a middle ground between my approach and Itpl.  I've found
a couple of situations where I want a minimal form of evaluation,
e.g. I want attributes to be expanded (and methods called), but not a
general evaluation facility.  So for example, I'd like to be able to
say:

    print _("The name of the mailing list is %(mlist.listname())s")

What worries me about a general evaluation framework is that we then
have to be really really careful about security and origin of the
strings we're using here.  Maybe we'd need to adopt something like
Perl's taint strings.

    KY> How about this routine to get the current frame:
    KY> inspect.currentframe().

It uses the same intentional-exception trick to get at the current
frame.  It's about 8x faster to do it in C.  I'll note that your
version raises and catches a string exception, while mine uses an
exception instance.  I don't see much difference in speed between the
two.

    KY> If there are changes that need to be made before it can be
    KY> accepted, i'd be happy to make them.

Sent under a separate private response...

-Barry


From gward@mems-exchange.org  Thu Oct 26 17:03:09 2000
From: gward@mems-exchange.org (Greg Ward)
Date: Thu, 26 Oct 2000 12:03:09 -0400
Subject: [Python-Dev] getting at the current frame
In-Reply-To: <14837.60682.437334.797392@anthem.concentric.net>; from barry@wooz.org on Tue, Oct 24, 2000 at 04:11:54PM -0400
References: <14837.60682.437334.797392@anthem.concentric.net>
Message-ID: <20001026120308.B14742@ludwig.cnri.reston.va.us>

On 24 October 2000, Barry A. Warsaw said:
> All well and good and doable in Python today, except getting the
> current frame with the exception raising trick is slooow.  A simple
> proposed addition to the sys module can improve the performance by
> about 8x:
> 
>     def _(s):
>         frame = sys.getcaller(1)
> 	d = frame.f_globals.copy()
> 	d.update(frame.f_locals())
> 	return the_translation_of(s) % d
> 
> The implementation of sys.getcaller() is given in the below patch.
> Comments?  I think this particular addition is too small for a PEP,
> although ?!ng still owns PEP 215 (which needs filling in).

+1.  Not sure if I would call that function 'getcaller()' or
'getframe()'; could go either way.

In my implementation of this (I guess everyone has one!), I also have a
couple of convenience functions:

  def get_caller_env (level=1):
      """get_caller_env(level : int = 1) -> (globals : dict, locals : dict)

      Return the environment of a caller: its dictionaries of global and
      local variables.  'level' has same meaning as for 'caller()'.
      """

  def get_frame_info (frame):
      """get_frame_info(frame)
         -> (filename : string,
             lineno : int,
             function_name : string,
             code_line : string)

      Extracts and returns a tuple of handy information from an execution
      frame.
      """

  def get_caller_info (level=1):
      """get_caller_info(level : int = 1)
         -> (filename : string,
             lineno : int,
             function_name : string,
             code_line : string)

      Extracts and returns a tuple of handy information from some caller's
      execution frame.  'level' is the same as for 'caller()', i.e.  if
      level is 1 (the default), gets this information about the caller of
      the function that is calling 'get_caller_info()'.
      """

These are mainly used by my unit-testing framework (which you'll no
doubt remember, Barry) to report where test failures originate.  Very
handy!

Looks like Ping's inspect.py has something like my 'get_frame_info()',
only it's called 'getframe()'.  Obviously this is the wrong name if
Barry's new function gets added as 'sys.getframe()'.  How 'bout this:

  sys.getframe(n)
    - return stack frame for depth 'n'
  inspect.getframeinfo(frame)
    - return (filename, line number, function name, lines-of-code)

Although I haven't grokked Ping's module enough to know if that rename
really fits his scheme.

        Greg
-- 
Greg Ward - software developer                gward@mems-exchange.org
MEMS Exchange / CNRI                           voice: +1-703-262-5376
Reston, Virginia, USA                            fax: +1-703-262-5367


From jon+sourceforge@unequivocal.co.uk  Thu Oct 26 17:57:01 2000
From: jon+sourceforge@unequivocal.co.uk (Jon Ribbens)
Date: Thu, 26 Oct 2000 17:57:01 +0100
Subject: [Python-Dev] Re: [Bug #117070] README instructions for configuring Setup are not helpful
In-Reply-To: <200010261442.JAA05046@cj20424-a.reston1.va.home.com>; from guido@python.org on Thu, Oct 26, 2000 at 09:42:40AM -0500
References: <200010251752.KAA02444@sf-web2.i.sourceforge.net> <20001025222406.A8389@snowy.squish.net> <14839.45989.450533.514732@cj42289-a.reston1.va.home.com> <200010261145.GAA04767@cj20424-a.reston1.va.home.com> <20001026120127.B11873@snowy.squish.net> <200010261442.JAA05046@cj20424-a.reston1.va.home.com>
Message-ID: <20001026175701.A4983@snowy.squish.net>

Guido van Rossum <guido@python.org> wrote:
> One thing -- it's perfectly fine to edit Setup after running Make for
> the first time.  You just have to run Make again.  The Makefiles are
> designed for this.

Mention this too ;-)


From fdrake@acm.org  Thu Oct 26 18:24:54 2000
From: fdrake@acm.org (Fred L. Drake, Jr.)
Date: Thu, 26 Oct 2000 13:24:54 -0400 (EDT)
Subject: [Python-Dev] Setup changes are checked in
Message-ID: <14840.26854.546598.565061@cj42289-a.reston1.va.home.com>

  I've checked in the changes to the handling of the Modules/Setup
file as we've discussed here.

  - Setup.in is now Setup.dist
  - Setup is created by configure
  - README and other instructions, comments, and documentation has
    been updated to reflect these changes


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at acm.org>
PythonLabs Team Member



From fdrake@acm.org  Thu Oct 26 18:30:22 2000
From: fdrake@acm.org (Fred L. Drake, Jr.)
Date: Thu, 26 Oct 2000 13:30:22 -0400 (EDT)
Subject: [Python-Dev] development version of docs online
Message-ID: <14840.27182.548970.193402@cj42289-a.reston1.va.home.com>

  Do people want to be notified when the development copy of the
documentation is update?  There was a comment from someone that they
didn't know where the online copy was.  I can send the update notice
to python-dev instead of just to myself if everyone wants it, or I can
send it to some other (appropriate) list.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at acm.org>
PythonLabs Team Member



From trentm@ActiveState.com  Thu Oct 26 18:42:30 2000
From: trentm@ActiveState.com (Trent Mick)
Date: Thu, 26 Oct 2000 10:42:30 -0700
Subject: [Python-Dev] development version of docs online
In-Reply-To: <14840.27182.548970.193402@cj42289-a.reston1.va.home.com>; from fdrake@acm.org on Thu, Oct 26, 2000 at 01:30:22PM -0400
References: <14840.27182.548970.193402@cj42289-a.reston1.va.home.com>
Message-ID: <20001026104230.B23283@ActiveState.com>

On Thu, Oct 26, 2000 at 01:30:22PM -0400, Fred L. Drake, Jr. wrote:
> 
>   Do people want to be notified when the development copy of the
> documentation is update?  There was a comment from someone that they

Yes, please.

Trent


-- 
Trent Mick
TrentM@ActiveState.com


From jim@interet.com  Thu Oct 26 20:34:03 2000
From: jim@interet.com (James C. Ahlstrom)
Date: Thu, 26 Oct 2000 15:34:03 -0400
Subject: [Python-Dev] What to choose to replace Tkinter?
References: <14837.14407.954185.466011@buffalo.fnal.gov> <ECEPKNMJLHAPFFJHDOJBKEKIDOAA.MarkH@ActiveState.com> <14837.43273.24692.93965@buffalo.fnal.gov> <20001024114326.E13957@kronos.cnri.reston.va.us>              <39F6B8B8.E3242929@interet.com> <200010251225.HAA22242@cj20424-a.reston1.va.home.com> <39F839BF.DD1B86BF@interet.com> <002a01c03f5f$71ca72f0$3c6340d5@hagrid>
Message-ID: <39F8872B.92D69403@interet.com>

Fredrik Lundh wrote:
> 
> jim wrote:
> > Sorry to be such an old fuddy-duddy, but you will
> > get the same reaction from most commercial software
> > vendors.  Make that nearly ALL vendors.
> 
> what reaction?
> 
> are you saying that your own installer can install the
> Python DLL but not the Tk DLL?

Not exactly.  I am saying I don't want to use the standard
Python Windows installer.  And I am saying I don't want to install
Tk because it is big, complicated, and requires Tcl and its libraries.

My installer does install the Python DLL python15.dll, so
I guess I could study how to install Tk and duplicate the
functionality of the Windows installer, and install Tk too.
But why would I want to?

JimA


From jim@interet.com  Thu Oct 26 20:38:40 2000
From: jim@interet.com (James C. Ahlstrom)
Date: Thu, 26 Oct 2000 15:38:40 -0400
Subject: [Python-Dev] What to choose to replace Tkinter?
References: <Pine.LNX.4.10.10010241146450.6622-100000@akbar.nevex.com> <200010241739.MAA16414@cj20424-a.reston1.va.home.com> <39F6BA29.3CAB4C0E@interet.com> <200010251227.HAA22256@cj20424-a.reston1.va.home.com> <39F83A4A.26E543A3@interet.com> <20001026101850.A14742@ludwig.cnri.reston.va.us>
Message-ID: <39F88840.3F619707@interet.com>

Greg Ward wrote:

> This is generally considered Bad Form by usability types.  I think it
> boils down to this: the computer is not the real world, and trying to
> emulate the real world on the computer is cutesy but a dead end.

I agree up to a point, and my own app doesn't use doors.

But kids like this kind of design, have no trouble
understanding it, and people wouldn't write this if
they didn't think it would sell.

I just meant that people have a larger tolerance for
non-Microsoft GUI design ideas than I thought up to now.

JimA


From skip@mojam.com (Skip Montanaro)  Thu Oct 26 21:10:33 2000
From: skip@mojam.com (Skip Montanaro) (Skip Montanaro)
Date: Thu, 26 Oct 2000 15:10:33 -0500 (CDT)
Subject: [Python-Dev] A possible bit for a README or FAQ?
Message-ID: <14840.36793.19348.903534@beluga.mojam.com>

Just came across this error while running configure:

    checking for gcc... gcc
    checking whether the C compiler (gcc   ) works... no
    configure: error: installation or configuration problem: C compiler cannot create executables.

The problem was that /tmp was full - sort of.  The system says there's no
space: 

    % cat /etc/termcap > /tmp/termcap
    bash: /tmp/termcap: No space left on device

but df disagrees:

    % df /tmp
    Filesystem           1k-blocks      Used Available Use% Mounted on
    /dev/hda5               153667     88796     56935  61% /

Short term workaround is to run configure with TMPDIR set somewhere else.
Perhaps this is something to put in a gcc-specific or Unix-specific section
of the README file.  I didn't see anything, and the message emitted by
configure gave no hint at the cause of the problem.  I realized what it was
because I've been scratching my head about this problem for a couple weeks.

If this is deemed useful I'll modify README and check it in.  If not, no big
deal.

(I have no idea why the system thinks /tmp is full... sigh ...)

Skip


From cgw@fnal.gov  Thu Oct 26 21:14:53 2000
From: cgw@fnal.gov (Charles G Waldman)
Date: Thu, 26 Oct 2000 15:14:53 -0500 (CDT)
Subject: [Python-Dev] A possible bit for a README or FAQ?
In-Reply-To: <14840.36793.19348.903534@beluga.mojam.com>
References: <14840.36793.19348.903534@beluga.mojam.com>
Message-ID: <14840.37053.829696.379140@buffalo.fnal.gov>

Skip Montanaro writes:
 > 
 > Just came across this error while running configure:
 > 
 >     checking for gcc... gcc
 >     checking whether the C compiler (gcc   ) works... no
 >     configure: error: installation or configuration problem: C compiler cannot create executables.

 > If this is deemed useful I'll modify README and check it in.  If not, no big
 > deal.

Personally,  I don't think this is useful.  I don't think the Python
README is the place to list everything that can go wrong during
./configure.

The generic advice is "If something goes wrong during ./configure, 
read through config.log to see what went wrong"

I'm curious what is in your config.log when this error occurs!


From nas@arctrix.com  Thu Oct 26 14:29:49 2000
From: nas@arctrix.com (Neil Schemenauer)
Date: Thu, 26 Oct 2000 06:29:49 -0700
Subject: [Python-Dev] A possible bit for a README or FAQ?
In-Reply-To: <14840.36793.19348.903534@beluga.mojam.com>; from skip@mojam.com on Thu, Oct 26, 2000 at 03:10:33PM -0500
References: <14840.36793.19348.903534@beluga.mojam.com>
Message-ID: <20001026062949.A14618@glacier.fnational.com>

> The problem was that /tmp was full - sort of.

You might try "df -i".  You could be out inodes but still have
blocks.

  Neil


From guido@python.org  Thu Oct 26 22:29:33 2000
From: guido@python.org (Guido van Rossum)
Date: Thu, 26 Oct 2000 16:29:33 -0500
Subject: [Python-Dev] Gradual migration PEP
In-Reply-To: Your message of "Thu, 26 Oct 2000 07:28:12 MST."
 <39F83F7C.2241158F@prescod.net>
References: <39F83F7C.2241158F@prescod.net>
Message-ID: <200010262129.QAA14206@cj20424-a.reston1.va.home.com>

Paul,

Your deprecation PEP looks good.  A few comments:

- I think that the one-year period may depend on the feature.  Some
may require an even longer time.  Others less.

- I think there will be cases where run-time checks are the only way
to detect use of the old feature (e.g. I'm still struggling with how
to change the division semantics).

But this shouldn't stop it from becoming a PEP.

Please arrange for a PEP number with Barry, the PEPmaster.

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


From thomas@xs4all.net  Thu Oct 26 23:58:41 2000
From: thomas@xs4all.net (Thomas Wouters)
Date: Fri, 27 Oct 2000 00:58:41 +0200
Subject: [Python-Dev] A possible bit for a README or FAQ?
In-Reply-To: <20001026062949.A14618@glacier.fnational.com>; from nas@arctrix.com on Thu, Oct 26, 2000 at 06:29:49AM -0700
References: <14840.36793.19348.903534@beluga.mojam.com> <20001026062949.A14618@glacier.fnational.com>
Message-ID: <20001027005841.R12812@xs4all.nl>

On Thu, Oct 26, 2000 at 06:29:49AM -0700, Neil Schemenauer wrote:
> > The problem was that /tmp was full - sort of.

> You might try "df -i".  You could be out inodes but still have
> blocks.

Or failing that, it could be out of 'indirect' or 'doubly-indirect' blocks,
or some other filesystem resource. Not often the case for something like
/tmp, but definately possible on some filesystems.

-- 
Thomas Wouters <thomas@xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!


From thomas@xs4all.net  Fri Oct 27 00:02:24 2000
From: thomas@xs4all.net (Thomas Wouters)
Date: Fri, 27 Oct 2000 01:02:24 +0200
Subject: [Python-Dev] A possible bit for a README or FAQ?
In-Reply-To: <14840.36793.19348.903534@beluga.mojam.com>; from skip@mojam.com on Thu, Oct 26, 2000 at 03:10:33PM -0500
References: <14840.36793.19348.903534@beluga.mojam.com>
Message-ID: <20001027010224.S12812@xs4all.nl>

On Thu, Oct 26, 2000 at 03:10:33PM -0500, Skip Montanaro wrote:

> Short term workaround is to run configure with TMPDIR set somewhere else.
> Perhaps this is something to put in a gcc-specific or Unix-specific section
> of the README file.  I didn't see anything, and the message emitted by
> configure gave no hint at the cause of the problem.  I realized what it was
> because I've been scratching my head about this problem for a couple weeks.

> If this is deemed useful I'll modify README and check it in.  If not, no big
> deal.

If you start adding things like that, also consider all the other
possibilities of configure being wrong. I hinted at one of them a couple of
weeks back, I think. (Somehow, 'last saturday', when I headed for London for
the Apachecon, feels like about two months ago :P) It's perfectly possible
for configure to be able to run gcc, gcc to be able to create working
binaries, but every check for a function or datatype failing because the
more 'involved' include files are missing. This is easy to do on Linux,
(removing /usr/src/linux, for instance) but not impossible on other systems
either.

-- 
Thomas Wouters <thomas@xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!


From greg@cosc.canterbury.ac.nz  Fri Oct 27 01:21:26 2000
From: greg@cosc.canterbury.ac.nz (Greg Ewing)
Date: Fri, 27 Oct 2000 13:21:26 +1300 (NZDT)
Subject: [Python-Dev] A possible bit for a README or FAQ?
In-Reply-To: <20001027005841.R12812@xs4all.nl>
Message-ID: <200010270021.NAA28528@s454.cosc.canterbury.ac.nz>

Thomas Wouters <thomas@xs4all.net>:

> Or failing that, it could be out of 'indirect' or 'doubly-indirect'
> blocks,

I think they're allocated from the same pool as data blocks.

What *can* happen is that you can run out of "large" blocks.  The
BSD-style filesystem stores files bigger than 8k in blocks made up of
8 contiguous 1k blocks. If the filesystem is nearly full, or contains
a large number of small files, you can find that it's impossible to
create any more files > 8k, even though there appears to be plenty of
free space, because the space is too fragmented.

I don't think that's what's happening here, though, since I've
only ever seen it happen when the filesystem was about 99% full.

Greg Ewing, Computer Science Dept, +--------------------------------------+
University of Canterbury,	   | A citizen of NewZealandCorp, a	  |
Christchurch, New Zealand	   | wholly-owned subsidiary of USA Inc.  |
greg@cosc.canterbury.ac.nz	   +--------------------------------------+


From tim_one@email.msn.com  Fri Oct 27 02:13:02 2000
From: tim_one@email.msn.com (Tim Peters)
Date: Thu, 26 Oct 2000 21:13:02 -0400
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: <39F8872B.92D69403@interet.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCEECGHNAA.tim_one@email.msn.com>

[Guido]
> are you saying that your own installer can install the
> Python DLL but not the Tk DLL?

[James Ahlstrom]
> Not exactly.  I am saying I don't want to use the standard
> Python Windows installer.  And I am saying I don't want to install
> Tk because it is big, complicated, and requires Tcl and its libraries.
>
> My installer does install the Python DLL python15.dll, so
> I guess I could study how to install Tk and duplicate the
> functionality of the Windows installer, and install Tk too.
> But why would I want to?

That's up to you and your customers.  What Guido has been telling you is
that what the Windows installer does now (as of 1.6) to "install" Tcl/Tk is
trivial:  it merely copies some Tcl/Tk files into the Python installation
tree.  It no longer runs the Scriptics installer, mucks with the path,
changes any envars, copies any files to outside of the Python tree, or even
sets anything up in the registry for Tcl/Tk.  You may not *want* to install
Tcl/Tk, but, if you would like to, there's no longer any basis for fearing
it's difficult, obscure, delicate or error-prone.

don't-know-about-those-wrt-other-gui-pkgs-ly y'rs  - tim




From skip@mojam.com (Skip Montanaro)  Fri Oct 27 04:54:51 2000
From: skip@mojam.com (Skip Montanaro) (Skip Montanaro)
Date: Thu, 26 Oct 2000 22:54:51 -0500 (CDT)
Subject: [Python-Dev] A possible bit for a README or FAQ?
In-Reply-To: <14840.37053.829696.379140@buffalo.fnal.gov>
References: <14840.36793.19348.903534@beluga.mojam.com>
 <14840.37053.829696.379140@buffalo.fnal.gov>
Message-ID: <14840.64651.444849.757658@beluga.mojam.com>

    Charles> The generic advice is "If something goes wrong during
    Charles> ./configure, read through config.log to see what went wrong"

Agreed.

    Charles> I'm curious what is in your config.log when this error occurs!

That's why I was thinking ("hmmm... perhaps a README bit").  It wasn't
giving me obvious "no space" messages.

I've concluded that it's probably best to forget it anyway.  If it's a
problem with configure or gcc messages, it's best addressed there.

Skip



From skip@mojam.com (Skip Montanaro)  Fri Oct 27 04:57:00 2000
From: skip@mojam.com (Skip Montanaro) (Skip Montanaro)
Date: Thu, 26 Oct 2000 22:57:00 -0500 (CDT)
Subject: [Python-Dev] A possible bit for a README or FAQ?
In-Reply-To: <20001026062949.A14618@glacier.fnational.com>
References: <14840.36793.19348.903534@beluga.mojam.com>
 <20001026062949.A14618@glacier.fnational.com>
Message-ID: <14840.64780.673428.672300@beluga.mojam.com>

    Neil> You might try "df -i".  You could be out inodes but still have
    Neil> blocks.

Thanks, that indeed seems to be the problem:

    % df -i /tmp
    Filesystem            Inodes   IUsed   IFree IUse% Mounted on
    /dev/hda5                39k     39k       7  100% /

I don't believe in all my years of fiddling with Unix systems I've ever run
out of inodes with a third of the disk space left.  Now to identify the
culprit.

Skip



From mal@lemburg.com  Fri Oct 27 11:15:53 2000
From: mal@lemburg.com (M.-A. Lemburg)
Date: Fri, 27 Oct 2000 12:15:53 +0200
Subject: [Python-Dev] Starship is still down...
Message-ID: <39F955D9.279864FD@lemburg.com>

It's been over a week since I posted my last gripe about
our community server starship being unreachable. Nothing has
happened so far... is there any chance on getting the server
up and running again ?

I am a bit concerned about the lack of support here: starship
should be considered a very important part in the Python
universe (after all, many Python extension packages and goodies
are available from that site). With the frequent downtimes
we recently had, I think people will get a wrong picture about
the Python community support.

Here's a traceroute from Germany to starship:
traceroute to starship.python.net (208.185.174.112), 30 hops max, 40 byte packets
 1  193.158.137.129 (193.158.137.129)  24 ms  23 ms  23 ms
 2  193.158.137.130 (193.158.137.130)  24 ms  35 ms  25 ms
 3  D-gw13.D.net.DTAG.DE (212.185.10.22)  67 ms  24 ms  35 ms
 4  K-gw13.K.net.DTAG.DE (194.25.124.137)  26 ms  25 ms  25 ms
 5  F-gw13.F.net.DTAG.DE (194.25.121.101)  32 ms  33 ms  33 ms
 6  TysonsC-gw12.USA.net.DTAG.DE (194.25.6.98)  113 ms  127 ms  131 ms
 7  TysonsC-gw1.USA.net.DTAG.DE (194.25.6.113)  115 ms  117 ms  134 ms
 8  mae-east-switch0.maee.above.net (208.184.210.9)  134 ms  114 ms  123 ms
 9  core1-mae-east-oc3-1.iad.above.net (209.133.31.225)  122 ms  116 ms  115 ms
10  sjc2-iad-oc48.sjc2.above.net (216.200.127.26)  184 ms  186 ms  185 ms
11  core5-core3-oc48.sjc2.above.net (208.185.156.66)  183 ms  184 ms  186 ms
12  sjc2-gige-main1.colo6.sjc2.above.net (208.185.156.37)  299 ms  183 ms !H  188 ms !H
13  * * *
14  * * *
...

It looks as if ABOVE.NET is having some serious routing problems.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/


From tim_one@email.msn.com  Fri Oct 27 11:43:22 2000
From: tim_one@email.msn.com (Tim Peters)
Date: Fri, 27 Oct 2000 06:43:22 -0400
Subject: [Python-Dev] Starship is still down...
In-Reply-To: <39F955D9.279864FD@lemburg.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCAEDHHNAA.tim_one@email.msn.com>

[MAL]
> It's been over a week since I posted my last gripe about
> our community server starship being unreachable.

Afraid Manus Head still gets the Most Outraged award for this one.

> Nothing has happened so far... is there any chance on getting the server
> up and running again ?

Works for me, but only very recently.  OTOH, my posts to python.org mailing
lists started black-holing, so it's not like Python-Dev will actually see
this post <wink>.  Here's a trace from my box (in Virginia); it may take a
while for recent routing changes to propagate:

  1   tnt32.tco2.da.uu.net [206.115.222.61]
  2   GigabitEthernet4-0.DR4.TCO2.Alter.Net [206.115.243.2]
  3   156.at-3-0-0.HR4.DCA1.ALTER.NET [152.63.34.50]
  4   517.ATM1-0.XR2.DCA1.ALTER.NET [152.63.36.198]
  5   294.at-7-1-0.XR2.DCA8.ALTER.NET [146.188.163.26]
  6   POS7-0.BR4.DCA8.ALTER.NET [152.63.36.25]
  7   137.39.52.102
  8   beth1br2-ge-1-0-0-0.md.us.prserv.net [165.87.29.139]
  9   sfra1br1-so-2-1-0-0.ca.us.prserv.net [165.87.233.42]
 10   sfra1sr3-ge-0-3-0-0.ca.us.prserv.net [165.87.33.139]
 11   pacbellpsfoc3.ca.us.prserv.net [165.87.161.5]
 12   core3-g2-0.snfc21.pbi.net [209.232.130.78]
 13   rback26-fe2-0.snfc21.pbi.net [216.102.187.153]
 14   adsl-63-202-160-65.dsl.snfc21.pacbell.net [63.202.160.65]
 15   starship.python.net [63.202.160.91]

> I am a bit concerned about the lack of support here: starship
> should be considered a very important part in the Python
> universe (after all, many Python extension packages and goodies
> are available from that site). With the frequent downtimes
> we recently had, I think people will get a wrong picture about
> the Python community support.

They're getting an accurate view of current Starship support.  So it goes.
Plans for better support *are* in progress, but for reasons that won't
become clear until later, you haven't heard anything about them yet.

for-that-matter-i'm-not-entirely-sure-i-have-either-ly y'rs  - tim




From jim@interet.com  Fri Oct 27 13:23:11 2000
From: jim@interet.com (James C. Ahlstrom)
Date: Fri, 27 Oct 2000 08:23:11 -0400
Subject: [Python-Dev] What to choose to replace Tkinter?
References: <LNBBLJKPBEHFEDALKOLCEECGHNAA.tim_one@email.msn.com>
Message-ID: <39F973AF.80D3BDBE@interet.com>

Tim Peters wrote:

> That's up to you and your customers.  What Guido has been telling you is
> that what the Windows installer does now (as of 1.6) to "install" Tcl/Tk is
> trivial:  it merely copies some Tcl/Tk files into the Python installation
> tree.  It no longer runs the Scriptics installer, mucks with the path,

Oh, OK.  That is much better.

JimA


From skip@mojam.com (Skip Montanaro)  Fri Oct 27 17:15:55 2000
From: skip@mojam.com (Skip Montanaro) (Skip Montanaro)
Date: Fri, 27 Oct 2000 11:15:55 -0500 (CDT)
Subject: [Python-Dev] Starship is still down...
In-Reply-To: <LNBBLJKPBEHFEDALKOLCAEDHHNAA.tim_one@email.msn.com>
References: <39F955D9.279864FD@lemburg.com>
 <LNBBLJKPBEHFEDALKOLCAEDHHNAA.tim_one@email.msn.com>
Message-ID: <14841.43579.261191.986406@beluga.mojam.com>

    Tim> Here's a trace from my box (in Virginia); ...

Tim's trace doesn't show times.  Looks to me like Pacbell is having trouble
(note the huge leap in response time):

    ...
    13  beth1sr3-so-5-1-3-0.md.us.prserv.net (165.87.99.50)  30.387 ms  27.426 ms  28.392 ms
    14  beth1br2-ge-1-0-0-0.md.us.prserv.net (165.87.29.139)  27.614 ms  27.349 ms  27.250 ms
    15  sfra1br1-so-2-1-0-0.ca.us.prserv.net (165.87.233.42)  71.581 ms  72.535 ms  72.429 ms
    16  sfra1sr3-ge-0-3-0-0.ca.us.prserv.net (165.87.33.139)  71.635 ms  71.420 ms  71.483 ms
    17  pacbellpsfoc3.ca.us.prserv.net (165.87.161.5)  71.070 ms  71.606 ms  71.301 ms
    18  core4-g2-0.snfc21.pbi.net (209.232.130.77)  70.986 ms  71.129 ms  73.628 ms
    19  rback26-fe2-0.snfc21.pbi.net (216.102.187.153)  72.696 ms  77.658 ms  83.046 ms
    20  adsl-63-202-160-65.dsl.snfc21.pacbell.net (63.202.160.65)  3841.343 ms  3705.648 ms  3911.584 ms
    21  adsl-63-202-160-91.dsl.snfc21.pacbell.net (63.202.160.91)  3683.340 ms  3867.550 ms  3653.732 ms

Skip


From petrilli@amber.org  Fri Oct 27 21:15:18 2000
From: petrilli@amber.org (Christopher Petrilli)
Date: Fri, 27 Oct 2000 16:15:18 -0400
Subject: GUI-Discussion; MacOS vs. MacOS X (was Re: [Python-Dev] Miscellaneous comments on Tkinter and related...)
In-Reply-To: <m13oTwr-000Dm8C@artcom0.artcom-gmbh.de>; from pf@artcom-gmbh.de on Wed, Oct 25, 2000 at 07:02:45PM +0200
References: <14838.64730.225260.148853@buffalo.fnal.gov> <m13oTwr-000Dm8C@artcom0.artcom-gmbh.de>
Message-ID: <20001027161518.B3942@trump.amber.org>

Peter Funk [pf@artcom-gmbh.de] wrote:
> 
> It will take years, before MacOS X will find its way onto the desk
> of the average Apple Mac user.  The Mac s mostly used in the graphics 
> and printing industry (our cutsomers) where people normally don't 
> even think about a OS upgrade, if they don't have to.  They usually
> run a mix of Photoshop, Quark XPRess, Artwork, illustrator or other 
> so called creative software on the version of the OS they had on 
> the machine when they bought it.  THese machines are usually used
> through a period of at least four years.

I think this is a bit incorrect.  Almost every Mac user that I
interact with (including all the users hre at Digital Creations) have
OS X running and using it at various levels.  Mostly it's waiting for
people like Adobe to release Carbon applications.  

Graphics designers will be the first to move to OS X, not thel ast, as 
they will ge the most fromt he increased stability and performance. It 
all depends on your market.

The best goal for Mac OS would be to aim at full Carbon compliance,
and not write to Cocoa, or to the original MacOS toolkit.  This would
let you run on all releases after 8.0 I believe (maybe even 7.6).

Chris
-- 
| Christopher Petrilli
| petrilli@amber.org


From guido@python.org  Sat Oct 28 02:42:42 2000
From: guido@python.org (Guido van Rossum)
Date: Fri, 27 Oct 2000 20:42:42 -0500
Subject: [Python-Dev] PythonLabs Team Moves to Digital Creations
Message-ID: <200010280142.UAA05020@cj20424-a.reston1.va.home.com>

To all Python users and developers:

Less than half a year ago, I moved with my team to BeOpen.com, in the
hope of finding a new permanent home for Python development.  At
BeOpen, we've done several good things for Python, such as moving the
Python and Jython development process to SourceForge, and the
successful release of Python 2.0.

Unfortunately, BeOpen.com's original plans for PythonLabs didn't work
out as hoped, and we weren't able to reach mutual agreement on
workable alternative plans -- despite trying for months.

I am proud to have found a new home for my entire team: starting
today, Tim Peters, Barry Warsaw, Jeremy Hylton, Fred Drake and myself
are working for Digital Creations.  We will be spending part of our
time on core Python development (including Jython and Mailman) and
part of our time on Python infrastructure improvements that also
benefit Zope.

Python will remain Open Source; Digital Creations has no desire to
monetize or brand the Python language or specific Python
distributions.  All future work we do on Python as Digital Creations
employees will be owned by a non-profit organization yet to be
created.  We think of this new organization as the Python Software
Foundation.  In the meantime (while the PSF is under construction) I
will own such copyrights personally.

We're excited to be working for Digital Creations: they are one of the
oldest companies active in the Python community, one of the companies
most committed to Python, and they have a great product!  Plus, we
know they have deep financial backing.  We trust that Digital
Creations will provide a stable home for Python for many years.

Digital Creations has also offered to take over hosting of the
python.org and starship sites.  On behalf of the Python community,
we're grateful for this support of the two prime community sites for
Python, and we expect to be implementing the transitions shortly.

These are exciting times for the PythonLabs team -- and also for
Python and its community.  Mainstream successes for Python are showing
up everywhere, and we're proud to be a part of such a smart and
friendly community.  A great year lies ahead!

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


From jim@digicool.com  Sat Oct 28 03:45:02 2000
From: jim@digicool.com (Jim Fulton)
Date: Fri, 27 Oct 2000 22:45:02 -0400
Subject: [Python-Dev] Re: PythonLabs Team Moves to Digital Creations
References: <mailman.972693760.7272.python-list@python.org>
Message-ID: <39FA3DAE.ADB2C8B1@digicool.com>

Guido van Rossum wrote:
> 
(snip)
> I am proud to have found a new home for my entire team: starting
> today, Tim Peters, Barry Warsaw, Jeremy Hylton, Fred Drake and myself
> are working for Digital Creations.  We will be spending part of our
> time on core Python development (including Jython and Mailman) and
> part of our time on Python infrastructure improvements that also
> benefit Zope.

Needless to say (but I'll say it anyway), Digital Creations is
proud and thrilled that the this team has joined us. 

These are indeed exciting times! 

Jim

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


From martin@loewis.home.cs.tu-berlin.de  Sat Oct 28 11:14:00 2000
From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Sat, 28 Oct 2000 12:14:00 +0200
Subject: [Python-Dev] getting at the current frame
Message-ID: <200010281014.MAA01045@loewis.home.cs.tu-berlin.de>

> which actually will look something like this in real code:
>
>    def trade(yours, mine):
>        print _('if you give me %(yours)s, i will give you %(mine)s') % {
>            'yours': yours,
>            'mine' : mine,
>            }
>
> The string wrapped in _() is what gets translated here.
>
> Okay, we all know that's a pain, right?

What's wrong with

    def trade(yours, mine):
        print _('if you give me %(yours)s, i will give you %(mine)s') % vars()

Look Ma, no magic!

Regards,
Martin


From effbot@telia.com  Sat Oct 28 11:43:05 2000
From: effbot@telia.com (Fredrik Lundh)
Date: Sat, 28 Oct 2000 12:43:05 +0200
Subject: [Python-Dev] Re: [Python-checkins] SourceForge problems
References: <14839.26627.968974.44752@cj42289-a.reston1.va.home.com>
Message-ID: <012e01c040cb$dc501b30$3c6340d5@hagrid>

fred wrote:
>   At any rate, there has been activity in the source tree; you just
> might want to do a CVS update to see what's changed.  There have been
> a number of bug fixes, a fair number of documentation updates, and
> many of the modules in the standard library have been passed through
> Tim Peter's reindent.py script (look in Tools/scripts/).

now that this has been done, emacs users might want to
add something like the following to their local configuration
(based on code by jwz, so it should work...)

:::

(defun python-mode-untabify ()
  (save-excursion
    (goto-char (point-min))
    (while (re-search-forward "[ \t]+$" nil t)
      (delete-region (match-beginning 0) (match-end 0)))
    (goto-char (point-min))
    (if (search-forward "\t" nil t)
        (untabify (1- (point)) (point-max))))
  nil)
 (add-hook 'python-mode-hook 
          '(lambda ()
             (make-local-variable 'write-contents-hooks)
             (add-hook 'write-contents-hooks 'python-mode-untabify)))

</F>



From martin@loewis.home.cs.tu-berlin.de  Sat Oct 28 11:51:20 2000
From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Sat, 28 Oct 2000 12:51:20 +0200
Subject: [Python-Dev] build problems under Solaris
Message-ID: <200010281051.MAA01290@loewis.home.cs.tu-berlin.de>

> I don't have access to a Solaris machine, so I can't do anything to
> help these users.

The patch in 117606 looks right to me: gcc on Solaris (and on any
other platform) needs -shared to build shared library; configure
currently passes -G. I haven't actually tried the patch, since it is a
pain to extract it from the SF bug report page. What happens is that
gcc passes -G to the linker, which correctly produces a shared
library.  However, gcc also links crt1/crti into the library, which
causes the reference to main.

117508 looks like a user error to me. On its own, configure would not
try to link -ldb, unless it detects the presence of db.h. My guess is
that there is a libdb in /usr/local, so a gcc configure finds it,
whereas the native compiler doesn't. Later, the linker even finds a
-ldb library, but somehow this doesn't have dbopen. So it could be
that the BSDDB installation on that system is screwed.

Regards,
Martin



From barry@scottb.demon.co.uk  Sat Oct 28 12:14:45 2000
From: barry@scottb.demon.co.uk (Barry Scott)
Date: Sat, 28 Oct 2000 12:14:45 +0100
Subject: [Python-Dev] Gradual migration
In-Reply-To: <39F82C97.12D04C85@lemburg.com>
Message-ID: <000601c040d0$474ce1d0$060210ac@private>

> > We could make integrating C++ and Python easier through CXX or Py_Cpp.
> > Perhaps we should ship one of those with Python 2.1. Anyhow, integrating
> > C++ and Python is not really so hard, in my experience.

	Integrating C++ and Python well is hard in a general library.

	CXX tries to make objects that look and feel like Python objects.
	But to do that we have to figure out the details of how python uses
	objects. You have no docs on the subject so we read the source code.

		Barry
		CXX maintainer



From barry@scottb.demon.co.uk  Sat Oct 28 12:23:50 2000
From: barry@scottb.demon.co.uk (Barry Scott)
Date: Sat, 28 Oct 2000 12:23:50 +0100
Subject: [Python-Dev] Gradual migration
In-Reply-To: <39F80C30.5448.52D32F94@localhost>
Message-ID: <000701c040d1$8beecf00$060210ac@private>

[Gordon wrote]
> All of the existing C++ interfaces / helpers deal only with type 
> objects (at least, those that I've examined, which is most of 
> them). In fact, only ExtensionClass attempts to deal with the 
> class / type split, and while it's a masterpiece, I think it's a 
> great example of everything to avoid in Py3K.

	Py_Cpp support C++ classes you can derived from in Python.
	Once I get my head around the proxy interface I'll try and
	add that to CXX. CXX today allows you to create C++ class
	that you can use from Python, but not derive from.

		Barry
		CXX maintainer




From Moshe Zadka <moshez@math.huji.ac.il>  Sun Oct 29 07:59:11 2000
From: Moshe Zadka <moshez@math.huji.ac.il> (Moshe Zadka)
Date: Sun, 29 Oct 2000 09:59:11 +0200 (IST)
Subject: [Python-Dev] development version of docs online
In-Reply-To: <14840.27182.548970.193402@cj42289-a.reston1.va.home.com>
Message-ID: <Pine.GSO.4.10.10010290956420.7911-100000@sundial>

On Thu, 26 Oct 2000, Fred L. Drake, Jr. wrote:

>   Do people want to be notified when the development copy of the
> documentation is update?  There was a comment from someone that they
> didn't know where the online copy was.  I can send the update notice
> to python-dev instead of just to myself if everyone wants it, or I can
> send it to some other (appropriate) list.

I'm for Python-Dev + doc-sig (I'm shooting myself in the foot, cause that
means I'm getting it twice. My foot is used to being shot at though)
--
Moshe Zadka <moshez@math.huji.ac.il> -- 95855124
http://advogato.org/person/moshez



From barry@wooz.org  Mon Oct 30 16:14:53 2000
From: barry@wooz.org (barry@wooz.org)
Date: Mon, 30 Oct 2000 11:14:53 -0500 (EST)
Subject: [Python-Dev] Re: getting at the current frame
References: <200010281014.MAA01045@loewis.home.cs.tu-berlin.de>
Message-ID: <14845.40573.917058.905009@anthem.concentric.net>

>>>>> "MvL" == Martin v Loewis <martin@loewis.home.cs.tu-berlin.de> writes:

    MvL> What's wrong with

    MvL>     def trade(yours, mine): print _('if you give me
    MvL> %(yours)s, i will give you %(mine)s') % vars()

    MvL> Look Ma, no magic!

Except that I also want globals() to be included and vars() doesn't
include that.  I really want:

    d = globals().copy()
    d.update(locals())

but I've also noticed that you sometimes want attribute following so
you can do things like

    _('the name of the list is %(mlist.listname)')

-Barry


From barry@wooz.org  Mon Oct 30 17:35:25 2000
From: barry@wooz.org (Barry A. Warsaw)
Date: Mon, 30 Oct 2000 12:35:25 -0500 (EST)
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Python ceval.c,2.212,2.213
References: <200010301715.JAA32564@slayer.i.sourceforge.net>
Message-ID: <14845.45405.867829.722598@anthem.concentric.net>

Well, it looks like checkin messages are flowing again.  Yay!


From mal@lemburg.com  Mon Oct 30 17:54:50 2000
From: mal@lemburg.com (M.-A. Lemburg)
Date: Mon, 30 Oct 2000 18:54:50 +0100
Subject: [Python-Dev] Re: Python Call Mechanism ([Python-checkins] CVS: python/dist/src/Python
 ceval.c,2.212,2.213)
References: <200010301715.JAA32564@slayer.i.sourceforge.net>
Message-ID: <39FDB5EA.B60EA39A@lemburg.com>

Jeremy Hylton wrote:
> 
> Update of /cvsroot/python/python/dist/src/Python
> In directory slayer.i.sourceforge.net:/tmp/cvs-serv32349/Python
> 
> Modified Files:
>         ceval.c
> ...
> N.B. The CALL_FUNCTION implementation is getting really hairy; should
> review it to see if it can be simplified.

How about a complete redesign of the whole call mechanism ?!

I have an old patch somewhere which reorganizes the Python
calling mechanism into something more sane than what we
have in ceval.c now.

Should I try to find it for someone to use as basis for the
reorg (don't have time for this myself) ?

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/


From jeremy@alum.mit.edu  Mon Oct 30 14:59:00 2000
From: jeremy@alum.mit.edu (Jeremy Hylton)
Date: Mon, 30 Oct 2000 09:59:00 -0500 (EST)
Subject: [Python-Dev] Re: Python Call Mechanism ([Python-checkins] CVS: python/dist/src/Python
 ceval.c,2.212,2.213)
In-Reply-To: <39FDB5EA.B60EA39A@lemburg.com>
References: <200010301715.JAA32564@slayer.i.sourceforge.net>
 <39FDB5EA.B60EA39A@lemburg.com>
Message-ID: <14845.36020.17063.951147@bitdiddle.concentric.net>

>>>>> "MAL" == M -A Lemburg <mal@lemburg.com> writes:

  MAL> Jeremy Hylton wrote:
  >>
  >> Update of /cvsroot/python/python/dist/src/Python In directory
  >> slayer.i.sourceforge.net:/tmp/cvs-serv32349/Python
  >>
  >> Modified Files: ceval.c ...  N.B. The CALL_FUNCTION
  >> implementation is getting really hairy; should review it to see
  >> if it can be simplified.

  MAL> How about a complete redesign of the whole call mechanism ?!

  MAL> I have an old patch somewhere which reorganizes the Python
  MAL> calling mechanism into something more sane than what we have in
  MAL> ceval.c now.

  MAL> Should I try to find it for someone to use as basis for the
  MAL> reorg (don't have time for this myself) ?

I'd be interested in looking at it.

Jeremy


From tim_one@email.msn.com  Mon Oct 30 19:36:55 2000
From: tim_one@email.msn.com (Tim Peters)
Date: Mon, 30 Oct 2000 14:36:55 -0500
Subject: [Python-Dev] New test_extcall fails on Windows -- elsewhere?  Expected?  Bug?
Message-ID: <LNBBLJKPBEHFEDALKOLCIEKPHNAA.tim_one@email.msn.com>

C:\Code\python\dist\src\PCbuild>python ../lib/test/regrtest.py test_extcall

test_extcall
test test_extcall failed -- Writing: '3', expected: ''
1 test failed: test_extcall

C:\Code\python\dist\src\PCbuild>python ../lib/test/regrtest.py -v
test_extcall

test_extcall
test_extcall
() {}
(1,) {}
(1, 2) {}
(1, 2, 3) {}
(1, 2, 3, 4, 5) {}
(1, 2, 3, 4, 5) {}
(1, 2, 3, 4, 5) {}
(1, 2, 3) {'b': 5, 'a': 4}
(1, 2, 3, 4, 5) {'b': 7, 'a': 6}
(1, 2, 3, 6, 7) {'y': 5, 'b': 9, 'x': 4, 'a': 8}
TypeError: not enough arguments to g(); expected 1, got 0
TypeError: not enough arguments to g(); expected 1, got 0
TypeError: not enough arguments to g(); expected 1, got 0
1 () {}
1 (2,) {}
1 (2, 3) {}
1 (2, 3, 4, 5) {}
0 (1, 2) {}
1 () {'d': 4, 'b': 2, 'c': 3, 'a': 1}
{'b': 2, 'c': 3, 'a': 1}
{'b': 2, 'c': 3, 'a': 1}
keyword parameter 'x' redefined in call to g()
keyword parameter 'b' redefined in function call
keywords must be strings
h() got an unexpected keyword argument 'e'
* argument must be a sequence
** argument must be a dictionary
3 512 1
3
3
unbound method must be called with instance as first argument
unbound method must be called with instance as first argument
1 test OK.




From fdrake@acm.org  Mon Oct 30 20:38:09 2000
From: fdrake@acm.org (Fred L. Drake, Jr.)
Date: Mon, 30 Oct 2000 15:38:09 -0500 (EST)
Subject: [Python-Dev] New test_extcall fails on Windows -- elsewhere?  Expected?  Bug?
In-Reply-To: <LNBBLJKPBEHFEDALKOLCIEKPHNAA.tim_one@email.msn.com>
References: <LNBBLJKPBEHFEDALKOLCIEKPHNAA.tim_one@email.msn.com>
Message-ID: <14845.56369.361598.655506@cj42289-a.reston1.va.home.com>

Tim Peters writes:
 > C:\Code\python\dist\src\PCbuild>python ../lib/test/regrtest.py test_extcall
 > 
 > test_extcall
 > test test_extcall failed -- Writing: '3', expected: ''
 > 1 test failed: test_extcall

  I get the same thing on Linux.  The output appears identical to what
Tim got.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at acm.org>
PythonLabs at Digital Creations



From jeremy@alum.mit.edu  Mon Oct 30 16:48:08 2000
From: jeremy@alum.mit.edu (Jeremy Hylton)
Date: Mon, 30 Oct 2000 11:48:08 -0500 (EST)
Subject: [Python-Dev] New test_extcall fails on Windows -- elsewhere?  Expected?  Bug?
In-Reply-To: <LNBBLJKPBEHFEDALKOLCIEKPHNAA.tim_one@email.msn.com>
References: <LNBBLJKPBEHFEDALKOLCIEKPHNAA.tim_one@email.msn.com>
Message-ID: <14845.42568.358062.805095@bitdiddle.concentric.net>

This output matches the output file I just checked in under
Lib/test/output/test_extcall.  Looks like I failed to check in this
change.

Jeremy


From tim_one@email.msn.com  Mon Oct 30 19:54:14 2000
From: tim_one@email.msn.com (Tim Peters)
Date: Mon, 30 Oct 2000 14:54:14 -0500
Subject: [Python-Dev] New test_extcall fails on Windows -- elsewhere?  Expected?  Bug?
In-Reply-To: <14845.42568.358062.805095@bitdiddle.concentric.net>
Message-ID: <LNBBLJKPBEHFEDALKOLCMELAHNAA.tim_one@email.msn.com>

[Jeremy]
> This output matches the output file I just checked in under
> Lib/test/output/test_extcall.  Looks like I failed to check in this
> change.

Thank you -- works on Windows now.  It should work on Linux too, if Linux
knows what's good for it <wink>.




From fdrake@acm.org  Mon Oct 30 20:56:13 2000
From: fdrake@acm.org (Fred L. Drake, Jr.)
Date: Mon, 30 Oct 2000 15:56:13 -0500 (EST)
Subject: [Python-Dev] New test_extcall fails on Windows -- elsewhere?  Expected?  Bug?
In-Reply-To: <LNBBLJKPBEHFEDALKOLCMELAHNAA.tim_one@email.msn.com>
References: <14845.42568.358062.805095@bitdiddle.concentric.net>
 <LNBBLJKPBEHFEDALKOLCMELAHNAA.tim_one@email.msn.com>
Message-ID: <14845.57453.54059.671795@cj42289-a.reston1.va.home.com>

Tim Peters writes:
 > Thank you -- works on Windows now.  It should work on Linux too, if Linux
 > knows what's good for it <wink>.

  It does.  ;)


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at acm.org>
PythonLabs at Digital Creations



From guido at python.org  Sun Oct  1 07:31:43 2000
From: guido at python.org (Guido van Rossum)
Date: Sun, 01 Oct 2000 00:31:43 -0500
Subject: [Python-Dev] Release candidate followed by feature freeze?
Message-ID: <200010010531.AAA15697@cj20424-a.reston1.va.home.com>

I'm considering to issue a release candidate before the final 2.0
release.  I'd like to poll opinions about this (we haven't had a
PythonLabs group meeting about this yet).

The importance of a release candidate (RC) is twofold: we announce it
widely so it (hopefully) gets a lot of testing -- necessary since a
lot of things have changed again since beta2; and we impose a checkin
stop once the RC is out, with exceptions only allowed by the release
manager to fix showstopper bugs found in the RC.

This will hopefully avoid a disaster like we had with the buggy
last-minute changes in beta2 (for which I take full responsibility).

If the idea of a RC sounds okay, I'd like to propose to release it on
October 5.  The final release would still be on October 10, or perhaps
1-2 days later.  Much less than a week between the RC and the final
release is not good because it doesn't give testers enough time to try
out the RC; much more than a week is bad because the developers get
antsy when they can't check in their changes!

This means that any current bug reports and patches that aren't in the
RC, WON'T BE FIXED in the final release!  Think about it.  This is a
good thing, so we won't be able to screw up the final release at the
last moment.

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



From thomas at xs4all.net  Sun Oct  1 14:06:48 2000
From: thomas at xs4all.net (Thomas Wouters)
Date: Sun, 1 Oct 2000 14:06:48 +0200
Subject: [Python-Dev] Changes in semantics to str()?
In-Reply-To: <200009302056.PAA14718@cj20424-a.reston1.va.home.com>; from guido@python.org on Sat, Sep 30, 2000 at 03:56:18PM -0500
References: <200009302056.PAA14718@cj20424-a.reston1.va.home.com>
Message-ID: <20001001140648.A12812@xs4all.nl>

On Sat, Sep 30, 2000 at 03:56:18PM -0500, Guido van Rossum wrote:

> Below I have included changes to listobject.c, tupleobject.c and
> dictobject.c that fix this.  The fixes change the print and str()
> callbacks for these objects to use PyObject_Str() on the contained
> items -- except if the item is a string or Unicode string.  I made
> these exceptions because I don't like the idea of str(["abc"])
> yielding [abc] -- I'm too used to the idea of seeing ['abc'] here.
> And str() of a Unicode object fails when it contains non-ASCII
> characters, so that's no good either -- it would break too much code.

Personally, I'm -0, or perhaps -1 (I'll make up my mind while going out for
some lunch/breakfast ;) I would be in favor if the str() output were only
used to display something to a user, but that's not the case. And too many
people are under the impression that the 'print' handler is the same as the
'str' handler to make that distinction now, I'm afraid. My main gripe with
this change is that it makes str() for container objects unreliable...
Strings are a special case, but class-instances are not -- so something like
UserString will be displayed without quotes. I don't like the idea of
sometimes doing 'str' and sometimes doing 'repr'.

I understand what it's trying to solve, but I don't think that's a worse
inconsistency than the one this change introduces. It's also easy to
explain: 'str(list or dict) is the same as repr(list or dict)'. The new
phrase would be something like 'str(list or dict) calls str() on the objects
it contains, except for string and unicode objects.'. And even that breaks
when you mix in instances that wrap a container. A list containing a
UserList containing a set of (unicode-)strings would display the strings
without quotes. And you can't see that the second container is a UserList.

I also don't think this change should be made between the final beta and
2.0. Jeremy, don't let him ruin your feature freeze! :-)

-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!



From jim at digicool.com  Sun Oct  1 16:32:27 2000
From: jim at digicool.com (Jim Fulton)
Date: Sun, 01 Oct 2000 10:32:27 -0400
Subject: [Python-Dev] select, signals, and "interrupted system call" (EINTR)
Message-ID: <39D74AFB.322E5187@digicool.com>

If a select-based (or, presumably, poll-based) server wants to
use signals for anything other than shutdown (e.g. closing and
reopening log files, rereading configs, etc.), then, on some 
platforms, a select call can fail with an "interrupted system
call" (EINTR) error that should be ignored.  The asyncore 
main loop should check for this error in it's select call
and the select module should make this error easier to check for.

In Python 1.5.2, the medusa select call can be changed from

        r,w,e = select.select (r,w,e, timeout)

to:

        while 1:
            try: r,w,e = select.select (r,w,e, timeout)
            except select.error, v:
                if v[0] != EINTR: raise
            else: break

I presume that this works in Python 1.6/2.0, but I
haven't tried it yet?

This depends on the structure of select.error values
and requires that we get EINTR from somewhere. (What
should the value be on NT?) 

I wonder if there should be an InterruptedSystemCall
exception somewhere that select raises in this case?

At a minimum, code like the above should be added to 
asyncore.

Thoughts?

Jim

--
Jim Fulton           mailto:jim at digicool.com
Technical Director   (888) 344-4332              Python Powered!
Digital Creations    http://www.digicool.com     http://www.python.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 rushing at nightmare.com  Sun Oct  1 21:07:59 2000
From: rushing at nightmare.com (Sam Rushing)
Date: Sun, 1 Oct 2000 12:07:59 -0700 (PDT)
Subject: [Python-Dev] [medusa] select, signals, and "interrupted system call" (EINTR)
In-Reply-To: <39D74AFB.322E5187@digicool.com>
References: <39D74AFB.322E5187@digicool.com>
Message-ID: <14807.35727.423642.721873@seattle.nightmare.com>

Jim Fulton writes:
 > The asyncore main loop should check for this error in it's select
 > call and the select module should make this error easier to check
 > for.

It might go better into the event_loop function, which I think of as a
more user-serviceable part.  [for example, the default loop vs. the
one in medusa/event_loop.py that supports schedulable events]

 > I presume that this works in Python 1.6/2.0, but I
 > haven't tried it yet?
 > 
 > This depends on the structure of select.error values
 > and requires that we get EINTR from somewhere. (What
 > should the value be on NT?) 

If it's a big problem, I guess we could use a different default
event_loop() function for win32 vs. unix.

 > At a minimum, code like the above should be added to asyncore.
 > 
 > Thoughts?

This has been asked for several times, I agree it'd be nice to have at
least a note in the docs..

-Sam




From loewis at informatik.hu-berlin.de  Sun Oct  1 21:13:41 2000
From: loewis at informatik.hu-berlin.de (Martin von Loewis)
Date: Sun, 1 Oct 2000 21:13:41 +0200 (MET DST)
Subject: [Python-Dev] Release candidate followed by feature freeze?
Message-ID: <200010011913.VAA01107@pandora.informatik.hu-berlin.de>

> I'd like to poll opinions about this (we haven't had a PythonLabs
> group meeting about this yet).

YES! I was hoping somebody would propose such a thing; I was quite
concerned that check-in procedures are still that liberate.

To report how similar projects operate: In gcc, a CVS release branch
is created at some point in time (usually months before the
release). When the code is declared frozen, all changes to the release
branch have to go through the release manager. After the release,
"important" changes to the mainline branch are manually propagated to
the release branch for subminor releases.

Regards,
Martin



From dkwolfe at pacbell.net  Sun Oct  1 23:23:03 2000
From: dkwolfe at pacbell.net (Dan Wolfe)
Date: Sun, 01 Oct 2000 14:23:03 -0700
Subject: [Python-Dev] FW: regarding the Python Developer posting...
Message-ID: <0G1R0061USP9TT@mta5.snfc21.pbi.net>

>> [commented out code that was causing seg fault in test_sre.py]

>you could try adding a Mac OS clause to the recursion limit stuff
>in Modules/_sre.c:
>
>#if !defined(USE_STACKCHECK)
>#if defined(...whatever's needed to detect Max OS X...)
[....]
>
>replace "...whatever...", and try larger values than 5000 (or smaller,
>if necessary.  10000 is clearly too large for your platform).
>
>(alternatively, you can increase the stack size.  maybe it's very small
>by default?)

the stack size is quite small by default - 512K.  After some testing I 
was able to figure out that it fails around 440 recursions... probably a 
bit too small in comparison to the other *nixes.... but then I'll defer 
to the experts in sre.

I was reading the August developer archives on the getrlimit and since 
that seem to be available, it's probably the right way to implement the 
stack check on Mac OS X.

Sure I can increase the default stack size - just a simple limit -h 
before running it in the shell... I let it run until about 7K 
recursions... even then it was only about 11MB and bumping the stack up 
by 30K or so per recursion... and I still had nearly 100MB free... and 
places to go. :-)

I'm going to write a bug report against Mac OS X and we'll see what 
happens.  In the meantime, you can hard code it to 440 and it will pass 
the test...  I've placed a patch on sourceforge that give the initial 
support for detecting Mac OS X as part of the make file but I still have 
to figure out how/where you defined MS_WIN64.... 

- Dan 




From barry at scottb.demon.co.uk  Mon Oct  2 00:19:21 2000
From: barry at scottb.demon.co.uk (Barry Scott)
Date: Sun, 1 Oct 2000 23:19:21 +0100
Subject: [Python-Dev] Patch to avoid conflict with older versions of Python.
In-Reply-To: <ECEPKNMJLHAPFFJHDOJBEEIHDLAA.MarkH@ActiveState.com>
Message-ID: <000b01c02bf5$a5edf070$060210ac@private>

I still think that Python needs to fix the problem with the API between
the core and the extensions. That way all the version checking would work
for Windows and Unix.

But since that approach has been rejected I'd take any change to python
that reduces support calls.

		BArry


> -----Original Message-----
> From: python-dev-admin at python.org [mailto:python-dev-admin at python.org]On
> Behalf Of Mark Hammond
> Sent: 29 September 2000 02:36
> To: python-dev at python.org
> Subject: [Python-Dev] Patch to avoid conflict with older versions of
> Python.
> 
> 
> Hi all,
> 	I'd like some feedback on a patch assigned to me.  It is designed to
> prevent Python extensions built for an earlier version of Python from
> crashing the new version.
> 
> I haven't actually tested the patch, but I am sure it works as advertised
> (who is db31 anyway?).
> 
> My question relates more to the "style" - the patch locates the new .pyd's
> address in memory, and parses through the MS PE/COFF format, locating the
> import table.  If then scans the import table looking for Pythonxx.dll, and
> compares any found entries with the current version.
> 
> Quite clever - a definite plus is that is should work for all old and
> future versions (of Python - dunno about Windows ;-) - but do we want this
> sort of code in Python?  Is this sort of hack, however clever, going to
> some back and bite us?
> 
> Second related question:  if people like it, is this feature something we
> can squeeze in for 2.0?
> 
> If there are no objections to any of this, I am happy to test it and check
> it in - but am not confident of doing so without some feedback.
> 
> Thanks,
> 
> Mark.
> 
> 
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://www.python.org/mailman/listinfo/python-dev
> 



From mal at lemburg.com  Mon Oct  2 09:36:49 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Mon, 02 Oct 2000 09:36:49 +0200
Subject: [Python-Dev] Release candidate followed by feature freeze?
References: <200010011913.VAA01107@pandora.informatik.hu-berlin.de>
Message-ID: <39D83B11.C1DE9EE8@lemburg.com>

Martin von Loewis wrote:
> 
> > I'd like to poll opinions about this (we haven't had a PythonLabs
> > group meeting about this yet).
> 
> YES! I was hoping somebody would propose such a thing; I was quite
> concerned that check-in procedures are still that liberate.
> 
> To report how similar projects operate: In gcc, a CVS release branch
> is created at some point in time (usually months before the
> release). When the code is declared frozen, all changes to the release
> branch have to go through the release manager. After the release,
> "important" changes to the mainline branch are manually propagated to
> the release branch for subminor releases.

+1

I think this is very good approach to the problem which we should
consider to apply to Python too.

BTW, could the nightly snapshots of the CVS tree that Jeremy
installed be made official ? 

This would be a great way to attract more beta-tester since not
everyone is willing to first set CVS on their machine just
to download the current Python development version.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From martin at loewis.home.cs.tu-berlin.de  Mon Oct  2 09:39:09 2000
From: martin at loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Mon, 2 Oct 2000 09:39:09 +0200
Subject: [Python-Dev] What is --with-next-framework
Message-ID: <200010020739.JAA01243@loewis.home.cs.tu-berlin.de>

I've been trying to understand how --with-next-framework is supposed
to work, and on what systems it is supposed to work - with little
success.

From what I understand, it will create a python2.0.dylib, and it will
pass that to the linker when linking extension modules. Fine.

What confuses me is the snippet in Modules/getpath.c, where it somehow
assumes that the Python library will live in an unversioned lib
directory relative to the location of the Python framework. How is
that supposed to work? Is anybody here willing to claim that this code
is not entirely broken?

Regards,
Martin



From mal at lemburg.com  Mon Oct  2 09:51:37 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Mon, 02 Oct 2000 09:51:37 +0200
Subject: [Python-Dev] Changes in semantics to str()?
References: <200009302056.PAA14718@cj20424-a.reston1.va.home.com>
Message-ID: <39D83E89.62F57D79@lemburg.com>

Guido van Rossum wrote:
> 
> When we changed floats to behave different on repr() than on str(), we
> briefly discussed changes to the container objects as well, but
> nothing came of it.
> 
> Currently, str() of a tuple, list or dictionary is the same as repr()
> of those objects.  This is not very consistent.  For example, when we
> have a float like 1.1 which can't be represented exactly, str() yields
> "1.1" but repr() yields "1.1000000000000001".  But if we place the
> same number in a list, it doesn't matter which function we use: we
> always get "[1.1000000000000001]".
> 
> Below I have included changes to listobject.c, tupleobject.c and
> dictobject.c that fix this.  The fixes change the print and str()
> callbacks for these objects to use PyObject_Str() on the contained
> items -- except if the item is a string or Unicode string.  I made
> these exceptions because I don't like the idea of str(["abc"])
> yielding [abc] -- I'm too used to the idea of seeing ['abc'] here.
> And str() of a Unicode object fails when it contains non-ASCII
> characters, so that's no good either -- it would break too much code.
> 
> Is it too late to check this in?  Another negative consequence would
> be that for user-defined or 3rd party extension objects that have
> different repr() and str(), like NumPy arrays, it might break some
> code -- but I think this is not very likely.

-1

I don't think that such a change is really worth breaking
code which relies on the current output of repr(list) or
str(list). As the test script from Fredrik for the Unicode
database showed there are some very subtle implications to
changes in str() and repr() -- e.g. in the mentioned case
the hash value would change.

Also, if I understand the patch correctly, str(list) would
be almost the same as '[' + ', '.join(map(str, entries)) + ']'
and '[' + ', '.join(map(repr, entries)) + ']' for repr().

While this may seem more transparent, I think it will cause
problems in practice: e.g. for large data buffers,
str(list) would now return the contents of the buffers
rather than just an abstract note about a buffer containing
the memory mapped data of file xyz.txt. As consequence, you'd
suddenly get a few MBs of output instead of a 100 char string...

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From martin at loewis.home.cs.tu-berlin.de  Mon Oct  2 09:48:37 2000
From: martin at loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Mon, 2 Oct 2000 09:48:37 +0200
Subject: [Python-Dev] Usage of --with- configure options
Message-ID: <200010020748.JAA01293@loewis.home.cs.tu-berlin.de>

I noticed that Python's configure.in does not follow the autoconf
style for using --enable- options. The autoconf documentation says

#   Some packages require, or can optionally use, other software packages
# which are already installed.  The user can give `configure' command
# line options to specify which such external software to use.  The
#  options have one of these forms:
#
#     --with-PACKAGE[=ARG]
#     --without-PACKAGE
...
#    If a software package has optional compile-time features, the user
# can give `configure' command line options to specify whether to compile
# them.  The options have one of these forms:
#
#     --enable-FEATURE[=ARG]
#     --disable-FEATURE

So --with- options should be used for integrating 3rd party libraries,
--enable- options for features that that can be independently turned
on or off.

I'd conclude that the following options are provided incorrectly in
Python 2.0: --with-pydebug (should be --enable-pydebug),
--with(out)-cycle-gc (should be --disable-cycle-gc). Is this something
that should change?

Regards,
Martin




From guido at python.org  Mon Oct  2 13:30:45 2000
From: guido at python.org (Guido van Rossum)
Date: Mon, 02 Oct 2000 06:30:45 -0500
Subject: [Python-Dev] Usage of --with- configure options
In-Reply-To: Your message of "Mon, 02 Oct 2000 09:48:37 +0200."
             <200010020748.JAA01293@loewis.home.cs.tu-berlin.de> 
References: <200010020748.JAA01293@loewis.home.cs.tu-berlin.de> 
Message-ID: <200010021130.GAA23606@cj20424-a.reston1.va.home.com>

> I noticed that Python's configure.in does not follow the autoconf
> style for using --enable- options. The autoconf documentation says
> 
> #   Some packages require, or can optionally use, other software packages
> # which are already installed.  The user can give `configure' command
> # line options to specify which such external software to use.  The
> #  options have one of these forms:
> #
> #     --with-PACKAGE[=ARG]
> #     --without-PACKAGE
> ...
> #    If a software package has optional compile-time features, the user
> # can give `configure' command line options to specify whether to compile
> # them.  The options have one of these forms:
> #
> #     --enable-FEATURE[=ARG]
> #     --disable-FEATURE
> 
> So --with- options should be used for integrating 3rd party libraries,
> --enable- options for features that that can be independently turned
> on or off.
> 
> I'd conclude that the following options are provided incorrectly in
> Python 2.0: --with-pydebug (should be --enable-pydebug),
> --with(out)-cycle-gc (should be --disable-cycle-gc). Is this something
> that should change?

I noticed that too.  (Arguably also for --with-thread?)  I think it's
a forgiveable sin against the autoconf style guide, and not worth the
work of fixing it.

Either way the autoconf --with- or --enable- syntax is stupid because
it doesn't check for spelling errors in the options.  The rationale
for that is that some folks like to pass in unsupported options to a
whole tree of configure scripts.  I think that stinks, but what can I
do.  This would make the fix even more work, because we would have to
trap --with*-pydebug and --with*-cycle-gc to give an error message,
else developers used to the old syntax would never notice the change.

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




From guido at python.org  Mon Oct  2 13:35:40 2000
From: guido at python.org (Guido van Rossum)
Date: Mon, 02 Oct 2000 06:35:40 -0500
Subject: [Python-Dev] What is --with-next-framework
In-Reply-To: Your message of "Mon, 02 Oct 2000 09:39:09 +0200."
             <200010020739.JAA01243@loewis.home.cs.tu-berlin.de> 
References: <200010020739.JAA01243@loewis.home.cs.tu-berlin.de> 
Message-ID: <200010021135.GAA23630@cj20424-a.reston1.va.home.com>

> I've been trying to understand how --with-next-framework is supposed
> to work, and on what systems it is supposed to work - with little
> success.
> 
> From what I understand, it will create a python2.0.dylib, and it will
> pass that to the linker when linking extension modules. Fine.
> 
> What confuses me is the snippet in Modules/getpath.c, where it somehow
> assumes that the Python library will live in an unversioned lib
> directory relative to the location of the Python framework. How is
> that supposed to work? Is anybody here willing to claim that this code
> is not entirely broken?

It's most likely broken.  Which suggests that nobody has tried it in a
*looooooong* time.  I have no idea what the --with-next-framework
option does, and I have no idea what a NeXT framework is.

Why are we still trying to support NeXT?  Isn't it completely
obsolete?

I propose to rip out --with-next-framework and be done with it.  If
you feel --with-next-framework is worth having, feel free to propose
platform-specific fixes to getpathp.c.

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



From fdrake at beopen.com  Mon Oct  2 15:22:19 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Mon, 2 Oct 2000 09:22:19 -0400 (EDT)
Subject: [Python-Dev] Usage of --with- configure options
In-Reply-To: <200010020748.JAA01293@loewis.home.cs.tu-berlin.de>
References: <200010020748.JAA01293@loewis.home.cs.tu-berlin.de>
Message-ID: <14808.35851.589320.360123@cj42289-a.reston1.va.home.com>

Martin v. Loewis writes:
 > I'd conclude that the following options are provided incorrectly in
 > Python 2.0: --with-pydebug (should be --enable-pydebug),
 > --with(out)-cycle-gc (should be --disable-cycle-gc). Is this something
 > that should change?

  Yes, if only to make it more consistent with existing practice.  A
harder one to change would be --enable-threads, because we've used
that for so long already.  Perhaps --enable-threads should be added,
and use that in the README instead of --with-threads.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From fredrik at pythonware.com  Mon Oct  2 15:41:21 2000
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Mon, 2 Oct 2000 15:41:21 +0200
Subject: [Python-Dev] Release candidate followed by feature freeze?
References: <200010010531.AAA15697@cj20424-a.reston1.va.home.com>
Message-ID: <001601c02c76$73a1cac0$0900a8c0@SPIFF>

guido wrote:
> If the idea of a RC sounds okay

Sure does.

> I'd like to propose to release it on October 5. 

Hmm.  My plan was to to work on the remaining SRE issues on
Saturday, leaving Sunday-Tuesday for final "burn-in"...

</F>




From petrilli at amber.org  Mon Oct  2 16:14:23 2000
From: petrilli at amber.org (Christopher Petrilli)
Date: Mon, 2 Oct 2000 10:14:23 -0400
Subject: [Python-Dev] What is --with-next-framework
In-Reply-To: <200010021135.GAA23630@cj20424-a.reston1.va.home.com>; from guido@python.org on Mon, Oct 02, 2000 at 06:35:40AM -0500
References: <200010020739.JAA01243@loewis.home.cs.tu-berlin.de> <200010021135.GAA23630@cj20424-a.reston1.va.home.com>
Message-ID: <20001002101423.A18958@trump.amber.org>

Guido van Rossum [guido at python.org] wrote:
> > I've been trying to understand how --with-next-framework is supposed
> > to work, and on what systems it is supposed to work - with little
> > success.
> > 
> > From what I understand, it will create a python2.0.dylib, and it will
> > pass that to the linker when linking extension modules. Fine.
> > 
> > What confuses me is the snippet in Modules/getpath.c, where it somehow
> > assumes that the Python library will live in an unversioned lib
> > directory relative to the location of the Python framework. How is
> > that supposed to work? Is anybody here willing to claim that this code
> > is not entirely broken?
> 
> It's most likely broken.  Which suggests that nobody has tried it in a
> *looooooong* time.  I have no idea what the --with-next-framework
> option does, and I have no idea what a NeXT framework is.

A NeXT Framework is a way of building software on NeXTstep/OpenStep
machines, and as far as I can tell, it continues largely unmodified on 
MacOS X (which is more OpenStep than MacOS at many layers).  We just
got our development copies of MacOS X here at Digital Creations, so we 
can take a look, but... as I recall, Jeffrey Shell wasn't able to get
Python running without using these options.

> Why are we still trying to support NeXT?  Isn't it completely
> obsolete?

I know of a few dozen large organizations still on OpenStep, and with
MacOS X I'd say it's far frrom obsolete, if anything it's more likely
than ever to be a"strong platform".

> I propose to rip out --with-next-framework and be done with it.  If
> you feel --with-next-framework is worth having, feel free to propose
> platform-specific fixes to getpathp.c.

I think it should be auto-detected, there's just no reason not to.
The uname of a MacOS X box is quite different than a Mac OX 9 box
(which has no uname :-).  Hopefully we can get a chance to look at
this at work this week.

Chris
-- 
| Christopher Petrilli
| petrilli at amber.org



From thomas at xs4all.net  Mon Oct  2 19:23:19 2000
From: thomas at xs4all.net (Thomas Wouters)
Date: Mon, 2 Oct 2000 19:23:19 +0200
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules readline.c,2.32,2.33
In-Reply-To: <200010021553.IAA01251@slayer.i.sourceforge.net>; from gvanrossum@users.sourceforge.net on Mon, Oct 02, 2000 at 08:53:12AM -0700
References: <200010021553.IAA01251@slayer.i.sourceforge.net>
Message-ID: <20001002192319.C12812@xs4all.nl>

On Mon, Oct 02, 2000 at 08:53:12AM -0700, Guido van Rossum wrote:

> Update of /cvsroot/python/python/dist/src/Modules
> In directory slayer.i.sourceforge.net:/tmp/cvs-serv1200

> Modified Files:
> 	readline.c 
> Log Message:
> Supporting rl_library_version is more trouble than it's worth --
> readline doesn't have it before readline 2.2 and there's no
> compile-time way to find out which readline version is in use.

But we can detect whether readline has rl_library_version during runtime,
and #ifdef it ;) I think the readline version info is useful enough to
warrant the extra #define and #ifdef... I can whip it up tonight, if the
autoconf check is desired ;P

-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!



From guido at python.org  Mon Oct  2 20:54:31 2000
From: guido at python.org (Guido van Rossum)
Date: Mon, 02 Oct 2000 13:54:31 -0500
Subject: [Python-Dev] What is --with-next-framework
In-Reply-To: Your message of "Mon, 02 Oct 2000 10:14:23 -0400."
             <20001002101423.A18958@trump.amber.org> 
References: <200010020739.JAA01243@loewis.home.cs.tu-berlin.de> <200010021135.GAA23630@cj20424-a.reston1.va.home.com>  
            <20001002101423.A18958@trump.amber.org> 
Message-ID: <200010021854.NAA01120@cj20424-a.reston1.va.home.com>

[Argument for the continued viability of OpenStep noted.]

> I think it should be auto-detected, there's just no reason not to.
> The uname of a MacOS X box is quite different than a Mac OX 9 box
> (which has no uname :-).  Hopefully we can get a chance to look at
> this at work this week.

Hm...  That might not get there in time for the 2.0 Release Candidate,
and after that it's an absolute code freeze (with exceptions only for
showstopper bugfixes) until 2.0 is released.

I guess MacOS X itself is still in beta, so we can afford to require
the creation of additional patches to fully support it after 2.0 is
released.

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




From petrilli at trump.amber.org  Mon Oct  2 19:56:03 2000
From: petrilli at trump.amber.org (Christopher Petrilli)
Date: Mon, 2 Oct 2000 13:56:03 -0400
Subject: [Python-Dev] What is --with-next-framework
In-Reply-To: <200010021854.NAA01120@cj20424-a.reston1.va.home.com>; from guido@python.org on Mon, Oct 02, 2000 at 01:54:31PM -0500
References: <200010020739.JAA01243@loewis.home.cs.tu-berlin.de> <200010021135.GAA23630@cj20424-a.reston1.va.home.com> <20001002101423.A18958@trump.amber.org> <200010021854.NAA01120@cj20424-a.reston1.va.home.com>
Message-ID: <20001002135603.C18958@trump.amber.org>

Guido van Rossum [guido at python.org] wrote:
> [Argument for the continued viability of OpenStep noted.]
> 
> > I think it should be auto-detected, there's just no reason not to.
> > The uname of a MacOS X box is quite different than a Mac OX 9 box
> > (which has no uname :-).  Hopefully we can get a chance to look at
> > this at work this week.
> 
> Hm...  That might not get there in time for the 2.0 Release Candidate,
> and after that it's an absolute code freeze (with exceptions only for
> showstopper bugfixes) until 2.0 is released.
> 
> I guess MacOS X itself is still in beta, so we can afford to require
> the creation of additional patches to fully support it after 2.0 is
> released.

MacOS X is in beta until Q1 (and I'd bet the END of Q1), so if there's 
a 2.1 planned sometime around there, which I believe there is, then
it'd be fine to roll it into that level in my opinion.

Chris
-- 
| Christopher Petrilli
| petrilli at amber.org



From guido at python.org  Mon Oct  2 21:15:37 2000
From: guido at python.org (Guido van Rossum)
Date: Mon, 02 Oct 2000 14:15:37 -0500
Subject: [Python-Dev] Changes in semantics to str()?
In-Reply-To: Your message of "Sun, 01 Oct 2000 14:06:48 +0200."
             <20001001140648.A12812@xs4all.nl> 
References: <200009302056.PAA14718@cj20424-a.reston1.va.home.com>  
            <20001001140648.A12812@xs4all.nl> 
Message-ID: <200010021915.OAA01219@cj20424-a.reston1.va.home.com>

I guess Thomas has settled the fate of my str() patch -- UserString
won't be dealt with properly.  I hereby withdraw the patch.

(I'm not sure what Marc-Andre means by buffer objects whose str() is
long but whose repr() is short, but it's probably a similar issue.)

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



From guido at python.org  Mon Oct  2 21:19:24 2000
From: guido at python.org (Guido van Rossum)
Date: Mon, 02 Oct 2000 14:19:24 -0500
Subject: [Python-Dev] Release candidate followed by feature freeze?
In-Reply-To: Your message of "Sun, 01 Oct 2000 21:13:41 +0200."
             <200010011913.VAA01107@pandora.informatik.hu-berlin.de> 
References: <200010011913.VAA01107@pandora.informatik.hu-berlin.de> 
Message-ID: <200010021919.OAA01232@cj20424-a.reston1.va.home.com>

> YES! I was hoping somebody would propose such a thing; I was quite
> concerned that check-in procedures are still that liberate.

Good.  We will have a release candidate then.

> To report how similar projects operate: In gcc, a CVS release branch
> is created at some point in time (usually months before the
> release). When the code is declared frozen, all changes to the release
> branch have to go through the release manager. After the release,
> "important" changes to the mainline branch are manually propagated to
> the release branch for subminor releases.

I am reluctant to use CVS branches (my experience with the branch for
1.6 suggests again that this is not at all smooth).

About the timing for the release candidate (RC): I think we need a
week +/- two days between the RC and the final release; this is needed
to make sure that the RC is actually tried out by enough people and
that the bug reports (if any) have been processed.  I believe we can
refrain from checkin in for a week but not much longer.

Fredrik Lundh mentions that he can't get his final batch of SRE
patches in before Saturday.  So the only realistic timing is to do the
RC on Monday (Oct 9) and the final release a week later (Oct 16).

Everybody okay with this?

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



From mal at lemburg.com  Mon Oct  2 20:35:27 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Mon, 02 Oct 2000 20:35:27 +0200
Subject: [Python-Dev] Changes in semantics to str()?
References: <200009302056.PAA14718@cj20424-a.reston1.va.home.com>  
	            <20001001140648.A12812@xs4all.nl> <200010021915.OAA01219@cj20424-a.reston1.va.home.com>
Message-ID: <39D8D56F.F279B9E5@lemburg.com>

Guido van Rossum wrote:
> 
> I guess Thomas has settled the fate of my str() patch -- UserString
> won't be dealt with properly.  I hereby withdraw the patch.
> 
> (I'm not sure what Marc-Andre means by buffer objects whose str() is
> long but whose repr() is short, but it's probably a similar issue.)
>

Example for the record:

>>> b = buffer('long string')
>>> b
<read-only buffer for 0x82a0160, ptr 0x82a0174, size 11 at 0x82db170>
>>> l = [b]
>>> l
[<read-only buffer for 0x82a0160, ptr 0x82a0174, size 11 at 0x82db170>]
>>> [str(b)]
['long string']

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From nas at arctrix.com  Mon Oct  2 13:48:59 2000
From: nas at arctrix.com (Neil Schemenauer)
Date: Mon, 2 Oct 2000 04:48:59 -0700
Subject: [Python-Dev] Release candidate followed by feature freeze?
In-Reply-To: <200010021919.OAA01232@cj20424-a.reston1.va.home.com>; from guido@python.org on Mon, Oct 02, 2000 at 02:19:24PM -0500
References: <200010011913.VAA01107@pandora.informatik.hu-berlin.de> <200010021919.OAA01232@cj20424-a.reston1.va.home.com>
Message-ID: <20001002044859.A9639@glacier.fnational.com>

On Mon, Oct 02, 2000 at 02:19:24PM -0500, Guido van Rossum wrote:
> So the only realistic timing is to do the RC on Monday (Oct 9)
> and the final release a week later (Oct 16).
> 
> Everybody okay with this?

What is going to be the fate of the GC?  There are currently two
reported bugs which I have been unable to reproduce.  If its
going to be disabled for 2.0 then it should be disabled in the
beta release.

  Neil



From effbot at telia.com  Mon Oct  2 21:11:58 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Mon, 2 Oct 2000 21:11:58 +0200
Subject: [Python-Dev] Re: [Bug #115845] sre: maxsplit as keyword argument
References: <200010021341.GAA26413@bush.i.sourceforge.net>
Message-ID: <003e01c02ca4$a7e2ef20$766940d5@hagrid>

http://sourceforge.net/bugs/?func=detailbug&bug_id=115845&group_id=5470

> Details: Split gives TypeError when called as a method of compiled
> regular expression object with maxsplit as keyword argument.
> This error is only in sre, pre is OK.
> 
> Python 1.6 (#2, Sep  6 2000, 18:20:07) [C] on osf1V4
> >>> import re
> >>> patt = re.compile(' ')
> >>> list = patt.split("a b c",50)              # OK
> >>> list = re.split(' ',"a b c",maxsplit=50)   # OK     
> >>> list = patt.split("a b c",maxsplit=50)     # ERROR
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
> TypeError: this function takes no keyword arguments
> 
> >>> import pre
> >>> patt = pre.compile(' ')
> >>> list = patt.split("a b c",maxsplit=50)     # OK

is this really a bug?  should users expect to be able to use
keyword arguments anywhere?

</F>




From guido at python.org  Mon Oct  2 22:09:32 2000
From: guido at python.org (Guido van Rossum)
Date: Mon, 02 Oct 2000 15:09:32 -0500
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules readline.c,2.32,2.33
In-Reply-To: Your message of "Mon, 02 Oct 2000 19:23:19 +0200."
             <20001002192319.C12812@xs4all.nl> 
References: <200010021553.IAA01251@slayer.i.sourceforge.net>  
            <20001002192319.C12812@xs4all.nl> 
Message-ID: <200010022009.PAA01439@cj20424-a.reston1.va.home.com>

> But we can detect whether readline has rl_library_version during runtime,
> and #ifdef it ;) I think the readline version info is useful enough to
> warrant the extra #define and #ifdef... I can whip it up tonight, if the
> autoconf check is desired ;P

Actually, I'm not sure what difference the readline version makes --
why would you need it?

Also, I'm not sure that the configure check is enough -- it's possible
that readline lives in a non-standard place where configure can't find
it but ppointed to by the Setup file.

I think it's just not worth it.

Please don't.

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



From guido at python.org  Mon Oct  2 22:18:57 2000
From: guido at python.org (Guido van Rossum)
Date: Mon, 02 Oct 2000 15:18:57 -0500
Subject: [Python-Dev] Re: [Bug #115845] sre: maxsplit as keyword argument
In-Reply-To: Your message of "Mon, 02 Oct 2000 21:11:58 +0200."
             <003e01c02ca4$a7e2ef20$766940d5@hagrid> 
References: <200010021341.GAA26413@bush.i.sourceforge.net>  
            <003e01c02ca4$a7e2ef20$766940d5@hagrid> 
Message-ID: <200010022018.PAA01525@cj20424-a.reston1.va.home.com>

> http://sourceforge.net/bugs/?func=detailbug&bug_id=115845&group_id=5470
> 
> > Details: Split gives TypeError when called as a method of compiled
> > regular expression object with maxsplit as keyword argument.
> > This error is only in sre, pre is OK.
> > 
> > Python 1.6 (#2, Sep  6 2000, 18:20:07) [C] on osf1V4
> > >>> import re
> > >>> patt = re.compile(' ')
> > >>> list = patt.split("a b c",50)              # OK
> > >>> list = re.split(' ',"a b c",maxsplit=50)   # OK     
> > >>> list = patt.split("a b c",maxsplit=50)     # ERROR
> > Traceback (most recent call last):
> >   File "<stdin>", line 1, in ?
> > TypeError: this function takes no keyword arguments
> > 
> > >>> import pre
> > >>> patt = pre.compile(' ')
> > >>> list = patt.split("a b c",maxsplit=50)     # OK
> 
> is this really a bug?  should users expect to be able to use
> keyword arguments anywhere?

Unclear, but the names were documented, and it worked before (when
pattern objects were Python instances) -- so who knows how much code
there's lying around that assumes this.  Well, we know it's more than
zero, because the bug report came from soemone who ran into this. :-)

Can we at PythonLabs help by adding keyword arguments to all of the
_sre.c functions?  I presume it's a pretty straightforward change.

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



From effbot at telia.com  Mon Oct  2 21:35:45 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Mon, 2 Oct 2000 21:35:45 +0200
Subject: [Python-Dev] Re: [Bug #115845] sre: maxsplit as keyword argument
References: <200010021341.GAA26413@bush.i.sourceforge.net>              <003e01c02ca4$a7e2ef20$766940d5@hagrid>  <200010022018.PAA01525@cj20424-a.reston1.va.home.com>
Message-ID: <014001c02ca8$44f7eb00$766940d5@hagrid>

> Can we at PythonLabs help by adding keyword arguments to all of the
> _sre.c functions?  I presume it's a pretty straightforward change.

if anyone can post (or point me to) an example showing
how to use the keyword API, I can take if from there.

</F>




From guido at python.org  Mon Oct  2 23:06:00 2000
From: guido at python.org (Guido van Rossum)
Date: Mon, 02 Oct 2000 16:06:00 -0500
Subject: [Python-Dev] Re: [Bug #115845] sre: maxsplit as keyword argument
In-Reply-To: Your message of "Mon, 02 Oct 2000 21:35:45 +0200."
             <014001c02ca8$44f7eb00$766940d5@hagrid> 
References: <200010021341.GAA26413@bush.i.sourceforge.net> <003e01c02ca4$a7e2ef20$766940d5@hagrid> <200010022018.PAA01525@cj20424-a.reston1.va.home.com>  
            <014001c02ca8$44f7eb00$766940d5@hagrid> 
Message-ID: <200010022106.QAA01620@cj20424-a.reston1.va.home.com>

> if anyone can post (or point me to) an example showing
> how to use the keyword API, I can take if from there.

Grep the Modules directory for PyArg_ParseTupleAndKeywords.  It's used
in the mmap, parser, pyexpat and sha modules.

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



From fdrake at beopen.com  Mon Oct  2 22:04:30 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Mon, 2 Oct 2000 16:04:30 -0400 (EDT)
Subject: [Python-Dev] Re: [Bug #115845] sre: maxsplit as keyword argument
In-Reply-To: <014001c02ca8$44f7eb00$766940d5@hagrid>
References: <200010021341.GAA26413@bush.i.sourceforge.net>
	<003e01c02ca4$a7e2ef20$766940d5@hagrid>
	<200010022018.PAA01525@cj20424-a.reston1.va.home.com>
	<014001c02ca8$44f7eb00$766940d5@hagrid>
Message-ID: <14808.59982.32731.732799@cj42289-a.reston1.va.home.com>

Fredrik Lundh writes:
 > if anyone can post (or point me to) an example showing
 > how to use the keyword API, I can take if from there.

  This is documented in the Extending & Embedding manual.  The parser
module (Modules/parsermodule.c) uses this.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From MarkH at ActiveState.com  Tue Oct  3 00:37:13 2000
From: MarkH at ActiveState.com (Mark Hammond)
Date: Tue, 3 Oct 2000 09:37:13 +1100
Subject: [Python-Dev] Release candidate followed by feature freeze?
In-Reply-To: <001601c02c76$73a1cac0$0900a8c0@SPIFF>
Message-ID: <ECEPKNMJLHAPFFJHDOJBGEOBDLAA.MarkH@ActiveState.com>

> guido wrote:
> > If the idea of a RC sounds okay
>
> Sure does.
>
> > I'd like to propose to release it on October 5.
>
> Hmm.  My plan was to to work on the remaining SRE issues on
> Saturday, leaving Sunday-Tuesday for final "burn-in"...

Also FYI, I intend applying the previous-version-crash patch tomorrow (or
late today), so those extra few days for /F would also prevent this patch
going out _too_ green...

Mark.




From fdrake at beopen.com  Tue Oct  3 02:23:13 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Mon, 2 Oct 2000 20:23:13 -0400 (EDT)
Subject: [Python-Dev] Development HTML docs online
Message-ID: <14809.9969.61986.897165@cj42289-a.reston1.va.home.com>

  I've set things up so I can easily "publish" the Python
documentation online without actually building a release.  It's not
entirely automatic, but I can push it online easily, so you'll be able
to see what I'm doing.  It can include more than just what's in CVS,
but I try not to have too much waiting to checkin at once.
  Check it out:

	ftp://python.beopen.com/pub/docco/devel/index.html


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From guido at python.org  Tue Oct  3 04:36:03 2000
From: guido at python.org (Guido van Rossum)
Date: Mon, 02 Oct 2000 21:36:03 -0500
Subject: [Python-Dev] Release candidate followed by feature freeze?
In-Reply-To: Your message of "Mon, 02 Oct 2000 04:48:59 MST."
             <20001002044859.A9639@glacier.fnational.com> 
References: <200010011913.VAA01107@pandora.informatik.hu-berlin.de> <200010021919.OAA01232@cj20424-a.reston1.va.home.com>  
            <20001002044859.A9639@glacier.fnational.com> 
Message-ID: <200010030236.VAA02702@cj20424-a.reston1.va.home.com>

> What is going to be the fate of the GC?  There are currently two
> reported bugs which I have been unable to reproduce.  If its
> going to be disabled for 2.0 then it should be disabled in the
> beta release.

Good point.  I see only the one that's assigned to you (reported by
Rob Hooft):

http://sourceforge.net/bugs/?group_id=5470&func=detailbug&bug_id=115341

What's the other?

Hooft's problem makes heavy use of Tkinter and Pmw, it seems.  Maybe
that's a clue?  Does he also use threads?  Is he willing to send his
entire program over?  (If you don't have time, we may have time at
PythonLabs!)

Anyway, I'm not yet ready to disable GC by default -- that's sensible
but also defeats the purpose...

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



From gward at python.net  Tue Oct  3 06:08:45 2000
From: gward at python.net (Greg Ward)
Date: Tue, 3 Oct 2000 00:08:45 -0400
Subject: [Python-Dev] ANNOUNCE: Distutils 1.0
Message-ID: <20001003000845.A1812@beelzebub>

                     Python Distribution Utilities
                              release 1.0
                            October 2, 2000

The Python Distribution Utilities, or Distutils for short, are a
collection of modules that aid in the development, distribution, and
installation of Python modules.  (It is intended that ultimately the
Distutils will grow up into a system for distributing and installing
whole Python applications, but for now their scope is limited to module
distributions.)

The Distutils are a standard part of Python 1.6 and 2.0; if you are running
1.6 or 2.0, you don't need to install the Distutils separately.  (However,
you might want to upgrade if you're running Python 1.6.)  This release is
primarily so that you can add the Distutils to a Python 1.5.2 installation
-- you will then be able to install modules that require the Distutils, or
use the Distutils to distribute your own modules.

Distutils 1.0 is the version that will be released with Python 2.0 (unless
last-minute bugs pop up).

More information is available at the Distutils web page:

    http://www.python.org/sigs/distutils-sig/

and in the README.txt included in the Distutils source distribution.

You can download the Distutils from

    http://www.python.org/sigs/distutils-sig/download.html

Trivial patches can be sent to me (Greg Ward) at gward at python.net.
Larger patches should be discussed on the Distutils mailing list:
distutils-sig at python.org.

        Greg
-- 
Greg Ward                                      gward at python.net
http://starship.python.net/~gward/
And now for something completely different.



From fredrik at pythonware.com  Tue Oct  3 10:52:37 2000
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Tue, 3 Oct 2000 10:52:37 +0200
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib cgi.py,1.53,1.54
References: <200010030832.BAA05615@slayer.i.sourceforge.net>
Message-ID: <011801c02d17$48659b10$0900a8c0@SPIFF>

> Change first line to #!/usr/bin/env python (really just to test check-in).

hmm.  cgi.py is a CGI script.  according to the Python FAQ, CGI
scripts should use an explicit path, not /usr/bin/env:

    "Note -- *don't* do this for CGI scripts. The $PATH variable
    for CGI scripts is often very minimal, so you need to use the
    actual absolute pathname of the interpreter."

(since this comes up over and over again, maybe someone should
add a comment to the file?)

</F>




From ping at lfw.org  Tue Oct  3 12:15:13 2000
From: ping at lfw.org (Ka-Ping Yee)
Date: Tue, 3 Oct 2000 03:15:13 -0700 (PDT)
Subject: [Python-Dev] Re: CVS: python/dist/src/Lib cgi.py,1.53,1.54
In-Reply-To: <011801c02d17$48659b10$0900a8c0@SPIFF>
Message-ID: <Pine.LNX.4.10.10010030310460.744-100000@skuld.kingmanhall.org>

On Tue, 3 Oct 2000, Fredrik Lundh wrote:
> > Change first line to #!/usr/bin/env python (really just to test check-in).
> 
> hmm.  cgi.py is a CGI script.  according to the Python FAQ, CGI
> scripts should use an explicit path, not /usr/bin/env:
> 
>     "Note -- *don't* do this for CGI scripts. The $PATH variable
>     for CGI scripts is often very minimal, so you need to use the
>     actual absolute pathname of the interpreter."

The $PATH variable for CGI scripts may be minimal, but minimal
as it is, Python should still be on it.  Using /usr/bin/python
works for half the people and /usr/local/bin/python works for
the other half... /usr/bin/env is supposed to work for everyone.

If this has already been argued soundly to death, i'm happy to
back out the change and add a comment.  It was a meaningless
change for me anyway.

Oh well.  Anyway, i'm glad CVS commit *finally* works for me.
Sorry for the extra hassle.


-- ?!ng

"To be human is to continually change.  Your desire to remain as you are
is what ultimately limits you."
    -- The Puppet Master, Ghost in the Shell




From nas at arctrix.com  Tue Oct  3 08:41:18 2000
From: nas at arctrix.com (Neil Schemenauer)
Date: Mon, 2 Oct 2000 23:41:18 -0700
Subject: [Python-Dev] Release candidate followed by feature freeze?
In-Reply-To: <200010030236.VAA02702@cj20424-a.reston1.va.home.com>; from guido@python.org on Mon, Oct 02, 2000 at 09:36:03PM -0500
References: <200010011913.VAA01107@pandora.informatik.hu-berlin.de> <200010021919.OAA01232@cj20424-a.reston1.va.home.com> <20001002044859.A9639@glacier.fnational.com> <200010030236.VAA02702@cj20424-a.reston1.va.home.com>
Message-ID: <20001002234118.A11108@glacier.fnational.com>

On Mon, Oct 02, 2000 at 09:36:03PM -0500, Guido van Rossum wrote:
> What's the other?

Some people from Origin Systems have reported a crash.  They are
using Python in a large application (probably related to the
Ultima Online game).  I will put the bug report in the database
today.

They are using a custom version of cPickle that may be causing
the problem.  It is an instance object which is causing the
trouble.  My malloc() == NULL patch for classobject.c did not fix
things.  They still haven't reported back regarding the cPickle
fix.

> Hooft's problem makes heavy use of Tkinter and Pmw, it seems.
> Maybe that's a clue?

I don't think _tkinter does anything special (unlike cPickle and
new).

> Does he also use threads?

His interpreter has threads enabled it seems.  Maybe I should get
him to test without threads, assuming he doesn't require them.

> Is he willing to send his entire program over?


From bwarsaw at beopen.com  Tue Oct  3 15:49:23 2000
From: bwarsaw at beopen.com (Barry A. Warsaw)
Date: Tue, 3 Oct 2000 09:49:23 -0400 (EDT)
Subject: [Python-Dev] Re: CVS: python/dist/src/Lib cgi.py,1.53,1.54
References: <011801c02d17$48659b10$0900a8c0@SPIFF>
	<Pine.LNX.4.10.10010030310460.744-100000@skuld.kingmanhall.org>
Message-ID: <14809.58339.707476.273418@anthem.concentric.net>

>>>>> "KY" == Ka-Ping Yee <ping at lfw.org> writes:

    KY> The $PATH variable for CGI scripts may be minimal, but minimal
    KY> as it is, Python should still be on it.

Well, maybe. :) E.g. Mailman's cgi wrapper program explicitly removes
$PATH from the environment before calling python with a compiled in
absolute path.

Which leads me to ask: how often are you calling cgi.py directly
anyway?  That'll just run the text() function which isn't terribly
useful other than to debug your cgi setup.  Usually you're calling
some other module that imports cgi, and in that case this line won't
have any effect.  And besides, it's not very safe to call a script
directly so I'd recommend a wrapper program anyway.
    
I'd say this one is rather harmless.

-Barry



From guido at python.org  Tue Oct  3 16:58:00 2000
From: guido at python.org (Guido van Rossum)
Date: Tue, 03 Oct 2000 09:58:00 -0500
Subject: [Python-Dev] Re: CVS: python/dist/src/Lib cgi.py,1.53,1.54
In-Reply-To: Your message of "Tue, 03 Oct 2000 03:15:13 MST."
             <Pine.LNX.4.10.10010030310460.744-100000@skuld.kingmanhall.org> 
References: <Pine.LNX.4.10.10010030310460.744-100000@skuld.kingmanhall.org> 
Message-ID: <200010031458.JAA05661@cj20424-a.reston1.va.home.com>

> > hmm.  cgi.py is a CGI script.  according to the Python FAQ, CGI
> > scripts should use an explicit path, not /usr/bin/env:
> > 
> >     "Note -- *don't* do this for CGI scripts. The $PATH variable
> >     for CGI scripts is often very minimal, so you need to use the
> >     actual absolute pathname of the interpreter."
> 
> The $PATH variable for CGI scripts may be minimal, but minimal
> as it is, Python should still be on it.  Using /usr/bin/python
> works for half the people and /usr/local/bin/python works for
> the other half... /usr/bin/env is supposed to work for everyone.

No.  On a typical Unix system (Linux perhaps excluded), /usr/local/bin
is not on the default $PATH.

> If this has already been argued soundly to death, i'm happy to
> back out the change and add a comment.  It was a meaningless
> change for me anyway.

I backed it out for you.  It really has been argued to death.

Glad CVS works for you!

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



From jeremy at beopen.com  Tue Oct  3 17:37:21 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Tue, 3 Oct 2000 11:37:21 -0400 (EDT)
Subject: [Python-Dev] Release candidate followed by feature freeze?
In-Reply-To: <20001002234118.A11108@glacier.fnational.com>
References: <200010011913.VAA01107@pandora.informatik.hu-berlin.de>
	<200010021919.OAA01232@cj20424-a.reston1.va.home.com>
	<20001002044859.A9639@glacier.fnational.com>
	<200010030236.VAA02702@cj20424-a.reston1.va.home.com>
	<20001002234118.A11108@glacier.fnational.com>
Message-ID: <14809.64817.295610.920807@bitdiddle.concentric.net>

>>>>> "NS" == Neil Schemenauer <nas at arctrix.com> writes:

  [GvR writes:]
  >> Anyway, I'm not yet ready to disable GC by default -- that's
  >> sensible but also defeats the purpose...

  NS> Okay.  I think I've found a possible problem.  When I set
  NS> threshold0 to 1 in the C code, weird things start happening.
  NS> I'm looking into it.

I agree that it isn't too useful to ship the garbage collector, but
have it turned off.  On the other hand, we're going to get a lot of
unhappy users if GC bugs cause inexplicable crashes in large
programs.  It would be hard to sell Python for important applications,
e.g. long-running server processes, if there was a small possibility
that the program could crash through no fault of its own.

Jeremy




From bwarsaw at beopen.com  Tue Oct  3 17:39:19 2000
From: bwarsaw at beopen.com (Barry A. Warsaw)
Date: Tue, 3 Oct 2000 11:39:19 -0400 (EDT)
Subject: [Python-Dev] Suggested change for Setup.in
Message-ID: <14809.64935.157146.681813@anthem.concentric.net>

I have a small suggestion for Modules/Setup.in.  On Linux (RH6.1) with
the zlib rpm installed, all I need to enable this module is the
following line:

    zlib zlibmodule.c -lz

but Setup.in has this suggestion, which I think is too hard for people
to figure out what to do:

    zlib zlibmodule.c -I$(prefix)/include -L$(exec_prefix)/lib -lz

The standard build options will already include the right -I and -L
flags for this to Just Work.  I suggest we make the common case
(Linux?) simple, and let others figure out what the right -I and -L
flags are.  I submit that even if they /do/ have to handcraft -I and
-L, the defaults in Setup.in are pretty meaningless.

A worthy change?  For 2.0 final?

-Barry



From guido at python.org  Tue Oct  3 19:31:47 2000
From: guido at python.org (Guido van Rossum)
Date: Tue, 03 Oct 2000 12:31:47 -0500
Subject: [Python-Dev] Canvas.Canvas.bbox() return value
Message-ID: <200010031731.MAA08827@cj20424-a.reston1.va.home.com>

Hi Fredrik,

Re this bug report:

http://sourceforge.net/bugs/?func=detailbug&bug_id=110677&group_id=5470

I can take care of the Canvas issues, but I need your advice on
bbox().  He's right that the bbox() method the Canvas class in the
Canvas module is different from all other bbox() methods: it returns a
tuple of tuples ((x1,y1),(x2,y2)) instead of a flat 4-tuple
(x,y1,x2,y2).

Do you think it's worth not breaking existing code here???

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



From bwarsaw at beopen.com  Tue Oct  3 18:34:51 2000
From: bwarsaw at beopen.com (Barry A. Warsaw)
Date: Tue, 3 Oct 2000 12:34:51 -0400 (EDT)
Subject: [Python-Dev] Small memory leak in unicodeobject.c
Message-ID: <14810.2731.466997.243906@anthem.concentric.net>

I've found a small memory leak in unicodeobject.c, in the way
_PyUnicode_Fini() shuts down.  Take a loop such as:

-------------------- snip snip --------------------
#include "Python.h"

int main(int argc, char** argv)
{
    int i;

    while (1) {
        Py_Initialize();
        Py_Finalize();
    }
    return 0;
}
-------------------- snip snip --------------------

and you'll find that unicode_empty leaks.  This is because, while
_PyUnicode_Fini() decrefs unicode_empty, it never actually gets
freed.  Instead it gets placed on the already freed unicode_freelist!
See _PyUnicode_Free() for why.

I've come up with the following nasty hack to force unicode_empty to
really be freed in _PyUnicode_Fini().  Maybe there's a better way to
do this.  Note that moving the decref of unicode_empty to above the
freeing of unicode_freelist didn't plug the memory leak for me (but
I'm quite tired so maybe I missed something! ;} ).

Below is the proposed patch.
-Barry

-------------------- snip snip --------------------
Index: unicodeobject.c
===================================================================
RCS file: /cvsroot/python/python/dist/src/Objects/unicodeobject.c,v
retrieving revision 2.64
diff -u -r2.64 unicodeobject.c
--- unicodeobject.c	2000/09/26 05:46:01	2.64
+++ unicodeobject.c	2000/10/03 16:31:32
@@ -5234,7 +5234,11 @@
 	PyObject_DEL(v);
     }
     unicode_freelist = NULL;
-    unicode_freelist_size = 0;
+    /* XXX This is a hack to force the freeing of unicode_empty's memory.
+     * Otherwise, it'll get placed on the already freed free list.
+     */
+    unicode_freelist_size = MAX_UNICODE_FREELIST_SIZE;
     Py_XDECREF(unicode_empty);
     unicode_empty = NULL;
+    unicode_freelist_size = 0;
 }



From effbot at telia.com  Tue Oct  3 19:08:05 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Tue, 3 Oct 2000 19:08:05 +0200
Subject: [Python-Dev] Canvas.Canvas.bbox() return value
References: <200010031731.MAA08827@cj20424-a.reston1.va.home.com>
Message-ID: <001801c02d5c$801d0300$766940d5@hagrid>

> Hi Fredrik,
> 
> Re this bug report:
> 
> http://sourceforge.net/bugs/?func=detailbug&bug_id=110677&group_id=5470
> 
> I can take care of the Canvas issues, but I need your advice on
> bbox().  He's right that the bbox() method the Canvas class in the
> Canvas module is different from all other bbox() methods: it returns a
> tuple of tuples ((x1,y1),(x2,y2)) instead of a flat 4-tuple
> (x,y1,x2,y2).
> 
> Do you think it's worth not breaking existing code here???

no idea -- I don't think I've ever used that module (!).

(I'd deprecate the entire module if I were in charge -- there
are better ways to put objects on the canvas)

but in case someone's using it, it's probably best to leave things
as they are...

</F>




From thomas at xs4all.net  Tue Oct  3 19:07:11 2000
From: thomas at xs4all.net (Thomas Wouters)
Date: Tue, 3 Oct 2000 19:07:11 +0200
Subject: [Python-Dev] Suggested change for Setup.in
In-Reply-To: <14809.64935.157146.681813@anthem.concentric.net>; from bwarsaw@beopen.com on Tue, Oct 03, 2000 at 11:39:19AM -0400
References: <14809.64935.157146.681813@anthem.concentric.net>
Message-ID: <20001003190711.D12812@xs4all.nl>

On Tue, Oct 03, 2000 at 11:39:19AM -0400, Barry A. Warsaw wrote:

> but Setup.in has this suggestion, which I think is too hard for people
> to figure out what to do:

>     zlib zlibmodule.c -I$(prefix)/include -L$(exec_prefix)/lib -lz

> The standard build options will already include the right -I and -L
> flags for this to Just Work.  I suggest we make the common case
> (Linux?) simple, and let others figure out what the right -I and -L
> flags are.  I submit that even if they /do/ have to handcraft -I and
> -L, the defaults in Setup.in are pretty meaningless.

> A worthy change?  For 2.0 final?

What about including both -I$(prefix)/include and -L$(exec_prefix)/lib by
default, for all modules, if those directories already exist ? Because zlib
is not the only module that has this problem. On BSDI and Solaris, the
same problem exists for curses, readline and gdbm, at least. If you are
installing in a completely separate tree, for whatever reason, either those
include/lib directories won't exist, they won't contain anything useful, or
they will contain the actual libraries you want to link with, anyway ;-P

And if you are installing in a 'standard' tree, like /usr, /usr/local,
/usr/contrib, /opt, or whatever, the optional GNU stuff is likely to be
there, too. If you don't fall under any of these cases, you'll have to do
what you have to do now, figure it out by hand.

I don't think changing the zlib line alone is going to matter much; it stops
working 'out of the box' for the slightly-less common case of non-linux
platforms (and not even all linux platforms ! There is no reason why a
distribution would install zlib in /usr.) I would prefer adding a
comment that clarifies the -I/-L lines, over removing them altogether, if we
aren't including $prefix/include and $exec_prefix/lib by default.

I-compile-on-BSDI-a-lot--and-every-little-bit-helps-;-)

-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!



From jeremy at beopen.com  Tue Oct  3 19:13:39 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Tue, 3 Oct 2000 13:13:39 -0400 (EDT)
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/test test_pty.py,1.4,1.5
In-Reply-To: <200010031651.JAA06853@slayer.i.sourceforge.net>
References: <200010031651.JAA06853@slayer.i.sourceforge.net>
Message-ID: <14810.5059.445654.876073@bitdiddle.concentric.net>

Thomas,

Thanks for taking care of this.  One nit on the checkin procedure,
pleae reference the SF bug number when you're fixing a bug.  Also,
report the revision number of the changed file when you close the bug.

Thanks,
Jeremy



From fdrake at beopen.com  Tue Oct  3 19:08:06 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Tue, 3 Oct 2000 13:08:06 -0400 (EDT)
Subject: [Python-Dev] Suggested change for Setup.in
In-Reply-To: <14809.64935.157146.681813@anthem.concentric.net>
References: <14809.64935.157146.681813@anthem.concentric.net>
Message-ID: <14810.4726.855657.955145@cj42289-a.reston1.va.home.com>

Barry A. Warsaw writes:
 > A worthy change?  For 2.0 final?

  This is good; even better would be the configure magic to make it
work automatically, similar to what we have for bsddb.  Given the
short time frame, your approach is good.  There may be other modules
that need similar adjustments in Setup.in.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From mal at lemburg.com  Tue Oct  3 19:13:40 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Tue, 03 Oct 2000 19:13:40 +0200
Subject: [Python-Dev] Small memory leak in unicodeobject.c
References: <14810.2731.466997.243906@anthem.concentric.net>
Message-ID: <39DA13C4.B1855D9A@lemburg.com>

"Barry A. Warsaw" wrote:
> 
> I've found a small memory leak in unicodeobject.c, in the way
> _PyUnicode_Fini() shuts down.  Take a loop such as:
> 
> -------------------- snip snip --------------------
> #include "Python.h"
> 
> int main(int argc, char** argv)
> {
>     int i;
> 
>     while (1) {
>         Py_Initialize();
>         Py_Finalize();
>     }
>     return 0;
> }
> -------------------- snip snip --------------------
> 
> and you'll find that unicode_empty leaks.  This is because, while
> _PyUnicode_Fini() decrefs unicode_empty, it never actually gets
> freed.  Instead it gets placed on the already freed unicode_freelist!
> See _PyUnicode_Free() for why.
> 
> I've come up with the following nasty hack to force unicode_empty to
> really be freed in _PyUnicode_Fini().  Maybe there's a better way to
> do this.  Note that moving the decref of unicode_empty to above the
> freeing of unicode_freelist didn't plug the memory leak for me (but
> I'm quite tired so maybe I missed something! ;} ).

It would be easier to simply move the Py_DECREF() in front of the
cleanup code for the free list. That way, unicode_empty would
be placed on the free list, but then immedialtely cleaned up
by the following code.

Should I check in such a patch ?
 
> Below is the proposed patch.
> -Barry
> 
> -------------------- snip snip --------------------
> Index: unicodeobject.c
> ===================================================================
> RCS file: /cvsroot/python/python/dist/src/Objects/unicodeobject.c,v
> retrieving revision 2.64
> diff -u -r2.64 unicodeobject.c
> --- unicodeobject.c     2000/09/26 05:46:01     2.64
> +++ unicodeobject.c     2000/10/03 16:31:32
> @@ -5234,7 +5234,11 @@
>         PyObject_DEL(v);
>      }
>      unicode_freelist = NULL;
> -    unicode_freelist_size = 0;
> +    /* XXX This is a hack to force the freeing of unicode_empty's memory.
> +     * Otherwise, it'll get placed on the already freed free list.
> +     */
> +    unicode_freelist_size = MAX_UNICODE_FREELIST_SIZE;
>      Py_XDECREF(unicode_empty);
>      unicode_empty = NULL;
> +    unicode_freelist_size = 0;
>  }
> 
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://www.python.org/mailman/listinfo/python-dev

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From guido at python.org  Tue Oct  3 20:28:08 2000
From: guido at python.org (Guido van Rossum)
Date: Tue, 03 Oct 2000 13:28:08 -0500
Subject: [Python-Dev] Suggested change for Setup.in
In-Reply-To: Your message of "Tue, 03 Oct 2000 11:39:19 -0400."
             <14809.64935.157146.681813@anthem.concentric.net> 
References: <14809.64935.157146.681813@anthem.concentric.net> 
Message-ID: <200010031828.NAA09229@cj20424-a.reston1.va.home.com>

> I have a small suggestion for Modules/Setup.in.  On Linux (RH6.1) with
> the zlib rpm installed, all I need to enable this module is the
> following line:
> 
>     zlib zlibmodule.c -lz
> 
> but Setup.in has this suggestion, which I think is too hard for people
> to figure out what to do:
> 
>     zlib zlibmodule.c -I$(prefix)/include -L$(exec_prefix)/lib -lz
> 
> The standard build options will already include the right -I and -L
> flags for this to Just Work.  I suggest we make the common case
> (Linux?) simple, and let others figure out what the right -I and -L
> flags are.  I submit that even if they /do/ have to handcraft -I and
> -L, the defaults in Setup.in are pretty meaningless.
> 
> A worthy change?  For 2.0 final?

Check it in right now.

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



From effbot at telia.com  Tue Oct  3 19:54:44 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Tue, 3 Oct 2000 19:54:44 +0200
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/test test_pty.py,1.4,1.5
References: <200010031651.JAA06853@slayer.i.sourceforge.net> <14810.5059.445654.876073@bitdiddle.concentric.net>
Message-ID: <005901c02d63$05cb5dc0$766940d5@hagrid>

> Thanks for taking care of this.  One nit on the checkin procedure,
> pleae reference the SF bug number when you're fixing a bug.  Also,
> report the revision number of the changed file when you close the bug.

do you really need both?  the former is easy, the latter is more
of a PITA, at least with the CVS setup I'm using here...

</F>




From guido at python.org  Tue Oct  3 20:58:20 2000
From: guido at python.org (Guido van Rossum)
Date: Tue, 03 Oct 2000 13:58:20 -0500
Subject: [Python-Dev] Small memory leak in unicodeobject.c
In-Reply-To: Your message of "Tue, 03 Oct 2000 12:34:51 -0400."
             <14810.2731.466997.243906@anthem.concentric.net> 
References: <14810.2731.466997.243906@anthem.concentric.net> 
Message-ID: <200010031858.NAA09564@cj20424-a.reston1.va.home.com>

> Index: unicodeobject.c
> ===================================================================
> RCS file: /cvsroot/python/python/dist/src/Objects/unicodeobject.c,v
> retrieving revision 2.64
> diff -u -r2.64 unicodeobject.c
> --- unicodeobject.c	2000/09/26 05:46:01	2.64
> +++ unicodeobject.c	2000/10/03 16:31:32
> @@ -5234,7 +5234,11 @@
>  	PyObject_DEL(v);
>      }
>      unicode_freelist = NULL;
> -    unicode_freelist_size = 0;
> +    /* XXX This is a hack to force the freeing of unicode_empty's memory.
> +     * Otherwise, it'll get placed on the already freed free list.
> +     */
> +    unicode_freelist_size = MAX_UNICODE_FREELIST_SIZE;
>      Py_XDECREF(unicode_empty);
>      unicode_empty = NULL;
> +    unicode_freelist_size = 0;
>  }

Doesn't it make more sense to decref unicode_empty sooner?  The loop
over the free list won't touch it:

Index: unicodeobject.c
===================================================================
RCS file: /cvsroot/python/python/dist/src/Objects/unicodeobject.c,v
retrieving revision 2.64
diff -c -r2.64 unicodeobject.c
*** unicodeobject.c	2000/09/26 05:46:01	2.64
--- unicodeobject.c	2000/10/03 17:55:34
***************
*** 5225,5230 ****
--- 5225,5232 ----
  {
      PyUnicodeObject *u = unicode_freelist;
  
+     Py_XDECREF(unicode_empty);
+     unicode_empty = NULL;
      while (u != NULL) {
  	PyUnicodeObject *v = u;
  	u = *(PyUnicodeObject **)u;
***************
*** 5235,5240 ****
      }
      unicode_freelist = NULL;
      unicode_freelist_size = 0;
-     Py_XDECREF(unicode_empty);
-     unicode_empty = NULL;
  }
--- 5237,5240 ----


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



From mal at lemburg.com  Tue Oct  3 20:02:39 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Tue, 03 Oct 2000 20:02:39 +0200
Subject: [Python-Dev] Small memory leak in unicodeobject.c
References: <14810.2731.466997.243906@anthem.concentric.net> <200010031858.NAA09564@cj20424-a.reston1.va.home.com>
Message-ID: <39DA1F3F.9EFA41EB@lemburg.com>

Guido van Rossum wrote:
> 
> > Index: unicodeobject.c
> > ===================================================================
> > RCS file: /cvsroot/python/python/dist/src/Objects/unicodeobject.c,v
> > retrieving revision 2.64
> > diff -u -r2.64 unicodeobject.c
> > --- unicodeobject.c   2000/09/26 05:46:01     2.64
> > +++ unicodeobject.c   2000/10/03 16:31:32
> > @@ -5234,7 +5234,11 @@
> >       PyObject_DEL(v);
> >      }
> >      unicode_freelist = NULL;
> > -    unicode_freelist_size = 0;
> > +    /* XXX This is a hack to force the freeing of unicode_empty's memory.
> > +     * Otherwise, it'll get placed on the already freed free list.
> > +     */
> > +    unicode_freelist_size = MAX_UNICODE_FREELIST_SIZE;
> >      Py_XDECREF(unicode_empty);
> >      unicode_empty = NULL;
> > +    unicode_freelist_size = 0;
> >  }
> 
> Doesn't it make more sense to decref unicode_empty sooner? 

Right. That's the change I proposed to Barry in my last mail.
Please check this in.

Thanks,
Marc-Andre

> The loop
> over the free list won't touch it:
> 
> Index: unicodeobject.c
> ===================================================================
> RCS file: /cvsroot/python/python/dist/src/Objects/unicodeobject.c,v
> retrieving revision 2.64
> diff -c -r2.64 unicodeobject.c
> *** unicodeobject.c     2000/09/26 05:46:01     2.64
> --- unicodeobject.c     2000/10/03 17:55:34
> ***************
> *** 5225,5230 ****
> --- 5225,5232 ----
>   {
>       PyUnicodeObject *u = unicode_freelist;
> 
> +     Py_XDECREF(unicode_empty);
> +     unicode_empty = NULL;
>       while (u != NULL) {
>         PyUnicodeObject *v = u;
>         u = *(PyUnicodeObject **)u;
> ***************
> *** 5235,5240 ****
>       }
>       unicode_freelist = NULL;
>       unicode_freelist_size = 0;
> -     Py_XDECREF(unicode_empty);
> -     unicode_empty = NULL;
>   }
> --- 5237,5240 ----
> 
> --Guido van Rossum (home page: http://www.python.org/~guido/)
> 
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://www.python.org/mailman/listinfo/python-dev

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From bwarsaw at beopen.com  Tue Oct  3 22:35:10 2000
From: bwarsaw at beopen.com (Barry A. Warsaw)
Date: Tue, 3 Oct 2000 16:35:10 -0400 (EDT)
Subject: [Python-Dev] Small memory leak in unicodeobject.c
References: <14810.2731.466997.243906@anthem.concentric.net>
	<39DA13C4.B1855D9A@lemburg.com>
Message-ID: <14810.17150.777092.128211@anthem.concentric.net>

>>>>> "M" == M  <mal at lemburg.com> writes:

    M> It would be easier to simply move the Py_DECREF() in front of
    M> the cleanup code for the free list. That way, unicode_empty
    M> would be placed on the free list, but then immedialtely cleaned
    M> up by the following code.

I know that's the obvious fix -- and it was the first thing I tried,
but it doesn't work!  (I thought I mentioned that in my original
message).

Verifying after a cvs up still shows unicode_empty leaking (I loop
through the Py_Initialize/Py_Finalize loop 10 times):

-------------------- snip snip --------------------
       240 bytes     10 chunks allocated at unicodeobject.c, 227
                          malloc()
                  _PyUnicode_New()  unicodeobject.c, 227
                 _PyUnicode_Init()  unicodeobject.c, 5217
                   Py_Initialize()  pythonrun.c, 125
                            main()
        30 bytes     10 chunks allocated at unicodeobject.c, 230
                          malloc()
                  _PyUnicode_New()  unicodeobject.c, 230
                 _PyUnicode_Init()  unicodeobject.c, 5217
                   Py_Initialize()  pythonrun.c, 125
                            main()
-------------------- snip snip --------------------

So let me step through the code and figure out what's wrong...

-Barry



From loewis at informatik.hu-berlin.de  Tue Oct  3 22:39:06 2000
From: loewis at informatik.hu-berlin.de (Martin von Loewis)
Date: Tue, 3 Oct 2000 22:39:06 +0200 (MET DST)
Subject: [Python-Dev] Release candidate followed by feature freeze?
Message-ID: <200010032039.WAA27659@pandora.informatik.hu-berlin.de>

> It would be hard to sell Python for important applications,
> e.g. long-running server processes, if there was a small possibility
> that the program could crash through no fault of its own.

There is always a small possibility that the program could crash
through no faults of its own - i.e. I don't believe that Python is bug
free without gc. I'd agree that bugs in the gc are more serious than
other bugs.

If it turns out that there are serious bugs in 2.0 (whether in the gc
or elsewhere), I'd hope BeOpen will release 2.0.1 shortly after they
get fixed.

Regards,
Martin



From bwarsaw at beopen.com  Tue Oct  3 22:42:25 2000
From: bwarsaw at beopen.com (Barry A. Warsaw)
Date: Tue, 3 Oct 2000 16:42:25 -0400 (EDT)
Subject: [Python-Dev] Small memory leak in unicodeobject.c
References: <14810.2731.466997.243906@anthem.concentric.net>
	<39DA13C4.B1855D9A@lemburg.com>
Message-ID: <14810.17585.567814.278594@anthem.concentric.net>

Oh the problem is obvious.  You have to initialize the local variable
`u' /after/ unicode_empty is freed otherwise it doesn't point to the
proper start of the free list.

I'll check that change in.
-Barry



From MarkH at ActiveState.com  Wed Oct  4 00:58:14 2000
From: MarkH at ActiveState.com (Mark Hammond)
Date: Wed, 4 Oct 2000 09:58:14 +1100
Subject: [Python-Dev] pep42 procedure?
Message-ID: <ECEPKNMJLHAPFFJHDOJBOEAJDMAA.MarkH@ActiveState.com>

Please excuse my ignorance...

I am in the process of applying the patch to prevent 1.5/1.6 extensions
crashing 2.0 under Windows.

Based on the feedback here (ie, "this should be a short term patch"), the
various other patches that try to do the same thing, and the belief by some
that we should be more like Unix anyway, I believe we should try and
capture this entire issue in a more formal manner.

The 2 logical places would be as a bug, and in pep42.  However, after
applying this patch, it doesnt really qualify as a bug!  Putting it in
pep42 is slightly suspect, as it is not a thought-out feature request yet -
however, I believe capturing it there, with links to the relevant patches
and discussions would be valuable.

So, assuming this sounds reasonable - a bug, or pep42?  If pep42, what is
the procedure for changing it?  I couldnt find it (or any pep) in the CVS
repository, and the source-force pages would show me the peps, but not
their source.  I do remember seeing this mentioned some time ago, but can't
locate that mail either...

Thanks,

Mark.




From trentm at ActiveState.com  Wed Oct  4 01:08:09 2000
From: trentm at ActiveState.com (Trent Mick)
Date: Tue, 3 Oct 2000 16:08:09 -0700
Subject: [Python-Dev] change to Lib/popen2.py break test_popen2 on windows
Message-ID: <20001003160809.A18387@ActiveState.com>

Fred's checkin:
http://www.python.org/pipermail/python-checkins/2000-September/008355.html
breaks test_popen2.py on windows.

This is because test_popen2.py attempts to refer to popen2's internal
'_active' variable, which is now explicitly deleted on Windows platforms.

test_popen2.py should be updated for the new popen2 semantics.


sorry-no-patch-ly yours,
Trent

-- 
Trent Mick
TrentM at ActiveState.com



From trentm at ActiveState.com  Wed Oct  4 01:10:09 2000
From: trentm at ActiveState.com (Trent Mick)
Date: Tue, 3 Oct 2000 16:10:09 -0700
Subject: [Python-Dev] change to Lib/popen2.py break test_popen2 on windows
In-Reply-To: <20001003160809.A18387@ActiveState.com>; from trentm@ActiveState.com on Tue, Oct 03, 2000 at 04:08:09PM -0700
References: <20001003160809.A18387@ActiveState.com>
Message-ID: <20001003161009.B18387@ActiveState.com>

On Tue, Oct 03, 2000 at 04:08:09PM -0700, Trent Mick wrote:
> 
> Fred's checkin:
> http://www.python.org/pipermail/python-checkins/2000-September/008355.html
> breaks test_popen2.py on windows.
> 
> This is because test_popen2.py attempts to refer to popen2's internal
> '_active' variable, which is now explicitly deleted on Windows platforms.
> 
> test_popen2.py should be updated for the new popen2 semantics.
> 

Geez, you are fast Tim! (for others: he patched test_popen.py after I sent my
email but before my email made it to python-dev!)


Trent


-- 
Trent Mick
TrentM at ActiveState.com



From skip at mojam.com  Wed Oct  4 02:54:55 2000
From: skip at mojam.com (Skip Montanaro)
Date: Tue, 3 Oct 2000 19:54:55 -0500 (CDT)
Subject: [Python-Dev] pep42 procedure?
In-Reply-To: <ECEPKNMJLHAPFFJHDOJBOEAJDMAA.MarkH@ActiveState.com>
References: <ECEPKNMJLHAPFFJHDOJBOEAJDMAA.MarkH@ActiveState.com>
Message-ID: <14810.32735.229954.547385@beluga.mojam.com>

    Mark> So, assuming this sounds reasonable - a bug, or pep42?  

I think neither.  This topic seems to have generated a lot of discussion.  I
think it deserves a bit more elaboration than what you'd find reasonable for
pep42.  Also, it would be kinda nice to add it to the Python FAQ with a
reference to a specific pep for all the gory details of the problem and
solution(s).

Skip



From MarkH at ActiveState.com  Wed Oct  4 05:58:25 2000
From: MarkH at ActiveState.com (Mark Hammond)
Date: Wed, 4 Oct 2000 14:58:25 +1100
Subject: [Python-Dev] pep42 procedure?
In-Reply-To: <14810.32735.229954.547385@beluga.mojam.com>
Message-ID: <ECEPKNMJLHAPFFJHDOJBAEBJDMAA.MarkH@ActiveState.com>

> I think neither.  This topic seems to have generated a lot of
> discussion.  I
> think it deserves a bit more elaboration than what you'd find
> reasonable for
> pep42.  Also, it would be kinda nice to add it to the Python FAQ with a
> reference to a specific pep for all the gory details of the problem and
> solution(s).

That would be a great idea, if only we had a PEP author.  To be honest, I
really dont care too much about this issue, and have been doing my level
best to avoid it.  But Tim knows that, and delights in assigning related
patches to me ;-)  I certainly don't care enough to own a pep on it.

The way things stand, I have a checkin ready to go, and am unwilling to
commit to any sort of pep in the short or medium term.  The best I could do
is to add links to the 3 or 4 other patches submitted for the same thing,
and pep42 seemed ideal.

So given this, what should I do - just check it in, and leave it to the
collective memory? ;-)

Mark.




From tim_one at email.msn.com  Wed Oct  4 06:58:46 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Wed, 4 Oct 2000 00:58:46 -0400
Subject: [Python-Dev] CIV
Message-ID: <LNBBLJKPBEHFEDALKOLCAEIDHJAA.tim_one@email.msn.com>

No, that's not 104, it's a Call for Indentation Volunteers!

An item that mistakenly got dropped on the floor before 2.0b1 was to ensure
that the standard Python libraries follow the recommended "4-space indents,
no hard tabs" guideline.  Since 100s of files (especially older ones in
oddball directories) are affected, I moved that it into PEP42 rather than
risk destabilizing the release after 2.0b1.

So it will happen instead soon after 2.0final is released.  I looked at
existing tools for doing this, and found they all left way too much manual
fiddling to bear,  too prone to screw up on comment lines (e.g., try running
your favorite tool over pindent.py:  does the output bear any resemblance to
the input?!  The Emacs pymode does OK there because pindent comments match
its conventions for "indenting comment lines", but nothing else even gets
close; OTOH,

    if 1:    # some insane people like
             # writing comments
             # like this too

and nobody knows what to do about that).

Attached is a new tool that tries much harder to get perverse comments right
(everything else is easy).  Try it and gripe at will.  Since I wrote it
while on vacation, it's public domain <0.5 wink>.

regularly y'rs  - tim

#! /usr/bin/env python

# Released to the public domain, by Tim Peters, 03 October 2000.

"""reindent [-d][-r][-v] path ...

-d  Dry run.  Analyze, but don't make any changes to, files.
-r  Recurse.  Search for all .py files in subdirectories too.
-v  Verbose.  Print informative msgs; else no output.

Change Python (.py) files to use 4-space indents and no hard tab characters.
Also trim excess whitespace from ends of lines, and empty lines at the ends
of files.  Ensure the last line ends with a newline.

Pass one or more file and/or directory paths.  When a directory path, all
.py files within the directory will be examined, and, if the -r option is
given, likewise recursively for subdirectories.

Overwrites files in place, renaming the originals with a .bak extension.
If reindent finds nothing to change, the file is left alone.  If reindent
does change a file, the changed file is a fixed-point for reindent (i.e.,
running reindent on the resulting .py file won't change it again).

The hard part of reindenting is figuring out what to do with comment
lines.  So long as the input files get a clean bill of health from
tabnanny.py, reindent should do a good job.
"""

import tokenize
import os
import sys

verbose = 0
recurse = 0
dryrun  = 0

def errprint(*args):
    sep = ""
    for arg in args:
        sys.stderr.write(sep + str(arg))
        sep = " "
    sys.stderr.write("\n")

def main():
    import getopt
    global verbose, recurse, dryrun
    try:
        opts, args = getopt.getopt(sys.argv[1:], "drv")
    except getopt.error, msg:
        errprint(msg)
        return
    for o, a in opts:
        if o == '-d':
            dryrun += 1
        elif o == '-r':
            recurse += 1
        elif o == '-v':
            verbose += 1
    if not args:
        errprint("Usage:", __doc__)
        return
    for arg in args:
        check(arg)

def check(file):
    if os.path.isdir(file) and not os.path.islink(file):
        if verbose:
            print "listing directory", file
        names = os.listdir(file)
        for name in names:
            fullname = os.path.join(file, name)
            if ((recurse and os.path.isdir(fullname) and
                 not os.path.islink(fullname))
                or name.lower().endswith(".py")):
                check(fullname)
        return

    if verbose:
        print "checking", file, "...",
    try:
        f = open(file)
    except IOError, msg:
        errprint("%s: I/O Error: %s" % (file, str(msg)))
        return

    r = Reindenter(f)
    f.close()
    if r.run():
        if verbose:
            print "changed."
            if dryrun:
                print "But this is a dry run, so leaving it alone."
        if not dryrun:
            bak = file + ".bak"
            if os.path.exists(bak):
                os.remove(bak)
            os.rename(file, bak)
            if verbose:
                print "renamed", file, "to", bak
            f = open(file, "w")
            r.write(f)
            f.close()
            if verbose:
                print "wrote new", file
    else:
        if verbose:
            print "unchanged."

class Reindenter:

    def __init__(self, f):
        self.find_stmt = 1  # next token begins a fresh stmt?
        self.level = 0      # current indent level

        # Raw file lines.
        self.raw = f.readlines()

        # File lines, rstripped & tab-expanded.  Dummy at start is so
        # that we can use tokenize's 1-based line numbering easily.
        # Note that a line is all-blank iff it's "\n".
        self.lines = [line.rstrip().expandtabs() + "\n"
                      for line in self.raw]
        self.lines.insert(0, None)
        self.index = 1  # index into self.lines of next line

        # List of (lineno, indentlevel) pairs, one for each stmt and
        # comment line.  indentlevel is -1 for comment lines, as a
        # signal that tokenize doesn't know what to do about them;
        # indeed, they're our headache!
        self.stats = []

    def run(self):
        tokenize.tokenize(self.getline, self.tokeneater)
        # Remove trailing empty lines.
        lines = self.lines
        while lines and lines[-1] == "\n":
            lines.pop()
        # Sentinel.
        stats = self.stats
        stats.append((len(lines), 0))
        # Map count of leading spaces to # we want.
        have2want = {}
        # Program after transformation.
        after = self.after = []
        for i in range(len(stats)-1):
            thisstmt, thislevel = stats[i]
            nextstmt = stats[i+1][0]
            have = getlspace(lines[thisstmt])
            want = thislevel * 4
            if want < 0:
                # A comment line.
                if have:
                    # An indented comment line.  If we saw the same
                    # indentation before, reuse what it most recently
                    # mapped to.
                    want = have2want.get(have, -1)
                    if want < 0:
                        # Then it probably belongs to the next real stmt.
                        for j in xrange(i+1, len(stats)-1):
                            jline, jlevel = stats[j]
                            if jlevel >= 0:
                                if have == getlspace(lines[jline]):
                                    want = jlevel * 4
                                break
                    if want < 0:           # Maybe it's a hanging
                                           # comment like this one,
                        # in which case we should shift it like its base
                        # line got shifted.
                        for j in xrange(i-1, -1, -1):
                            jline, jlevel = stats[j]
                            if jlevel >= 0:
                                want = have + getlspace(after[jline-1]) - \
                                       getlspace(lines[jline])
                                break
                    if want < 0:
                        # Still no luck -- leave it alone.
                        want = have
                else:
                    want = 0
            assert want >= 0
            have2want[have] = want
            diff = want - have
            if diff == 0 or have == 0:
                after.extend(lines[thisstmt:nextstmt])
            else:
                for line in lines[thisstmt:nextstmt]:
                    if diff > 0:
                        if line == "\n":
                            after.append(line)
                        else:
                            after.append(" " * diff + line)
                    else:
                        remove = min(getlspace(line), -diff)
                        after.append(line[remove:])
        return self.raw != self.after

    def write(self, f):
        f.writelines(self.after)

    # Line-getter for tokenize.
    def getline(self):
        if self.index >= len(self.lines):
            line = ""
        else:
            line = self.lines[self.index]
            self.index += 1
        return line

    # Line-eater for tokenize.
    def tokeneater(self, type, token, (sline, scol), end, line,
                   INDENT=tokenize.INDENT,
                   DEDENT=tokenize.DEDENT,
                   NEWLINE=tokenize.NEWLINE,
                   COMMENT=tokenize.COMMENT,
                   NL=tokenize.NL):

        if type == NEWLINE:
            # A program statement, or ENDMARKER, will eventually follow,
            # after some (possibly empty) run of tokens of the form
            #     (NL | COMMENT)* (INDENT | DEDENT+)?
            self.find_stmt = 1

        elif type == INDENT:
            self.find_stmt = 1
            self.level += 1

        elif type == DEDENT:
            self.find_stmt = 1
            self.level -= 1

        elif type == COMMENT:
            if self.find_stmt:
                self.stats.append((sline, -1))
                # but we're still looking for a new stmt, so leave
                # find_stmt alone

        elif type == NL:
            pass

        elif self.find_stmt:
            # This is the first "real token" following a NEWLINE, so it
            # must be the first token of the next program statement, or an
            # ENDMARKER.
            self.find_stmt = 0
            if line:   # not endmarker
                self.stats.append((sline, self.level))

# Count number of leading blanks.
def getlspace(line):
    i, n = 0, len(line)
    while i < n and line[i] == " ":
        i += 1
    return i

if __name__ == '__main__':
    main()





From bwarsaw at beopen.com  Wed Oct  4 08:06:14 2000
From: bwarsaw at beopen.com (Barry A. Warsaw)
Date: Wed, 4 Oct 2000 02:06:14 -0400 (EDT)
Subject: [Python-Dev] pep42 procedure?
References: <ECEPKNMJLHAPFFJHDOJBOEAJDMAA.MarkH@ActiveState.com>
Message-ID: <14810.51414.59852.855231@anthem.concentric.net>

>>>>> "MH" == Mark Hammond <MarkH at ActiveState.com> writes:

    MH> I couldnt find it (or any pep) in the CVS repository, and the
    MH> source-force pages would show me the peps, but not their
    MH> source.

The PEPs are located in the nondist directory, under nondist/peps!

-Barry



From bwarsaw at beopen.com  Wed Oct  4 08:07:06 2000
From: bwarsaw at beopen.com (Barry A. Warsaw)
Date: Wed, 4 Oct 2000 02:07:06 -0400 (EDT)
Subject: [Python-Dev] forwarded message from aahz@panix.com
Message-ID: <14810.51466.486982.938180@anthem.concentric.net>

An embedded message was scrubbed...
From: aahz at panix.com
Subject: htmllib.HTMLescape()
Date: Tue, 3 Oct 2000 16:26:32 -0700 (PDT)
Size: 1672
URL: <http://mail.python.org/pipermail/python-dev/attachments/20001004/159fd0b6/attachment.eml>

From thomas at xs4all.net  Wed Oct  4 08:16:58 2000
From: thomas at xs4all.net (Thomas Wouters)
Date: Wed, 4 Oct 2000 08:16:58 +0200
Subject: [Python-Dev] pep42 procedure?
In-Reply-To: <ECEPKNMJLHAPFFJHDOJBAEBJDMAA.MarkH@ActiveState.com>; from MarkH@ActiveState.com on Wed, Oct 04, 2000 at 02:58:25PM +1100
References: <14810.32735.229954.547385@beluga.mojam.com> <ECEPKNMJLHAPFFJHDOJBAEBJDMAA.MarkH@ActiveState.com>
Message-ID: <20001004081658.E12812@xs4all.nl>

On Wed, Oct 04, 2000 at 02:58:25PM +1100, Mark Hammond wrote:

[ Mark wants to apply a patch that prevents crashes on windows when loading
extentions linked with old Python DLLs, but doesn't know where to document
it: PEP 42 or the bug report(s) ]

[ Skip proposes a separate PEP ]

[ Mark doesn't have time to write a PEP ]

> So given this, what should I do - just check it in, and leave it to the
> collective memory? ;-)

PEP 42 is the meaning of life PEP, meaning that it's everything that needs
to be done before python-dev can rest in pieces. I don't think that a solved
issue is in its place there, even if it had such a section. A PEP on its own
would probably be the best spot, because even if it's a 'temporary' solution
now, we or someone else might need the info later. And a PEP doesn't have to
be that hard to write ;)

And besides, you don't have to be the person to write the PEP, someone else
can. And if noone suitable volunteers, perhaps a checkin-message giving
'full' documentation, the necessary sourcecode comments and a reference to
both in the bugreport message will suffice... But I'm willing to PEPify
whatever docs or comments you write on this issue, Mark. I will need some
guidance on what exactly is the issue, but I'm sure I'll get that from one
of you Windows lovers ! :-)

And no, I don't think Python should be more like UNIX. Windows, yes, but
it's not Python's job to turn Windows into a halfhearted UNIX ;-P Besides,
that would only alienate the Windows users with Uni(x)fobia.

Unix-unix-unix-ly y'rs,

-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!



From ping at lfw.org  Wed Oct  4 13:02:51 2000
From: ping at lfw.org (Ka-Ping Yee)
Date: Wed, 4 Oct 2000 04:02:51 -0700 (PDT)
Subject: [Python-Dev] Installing python in /usr/bin
Message-ID: <Pine.LNX.4.10.10010040357390.4474-100000@skuld.kingmanhall.org>

The cgi.py discussion brought my attention to this comment from Guido:

> No, no, no!  The /usr/bin/env form *fails* on most platforms (except
> Linux) because Python is not installed in any of the default "bin"
> directories -- /usr/local/bin is the standard install place and that's
> not in the default path.

So the natural question to ask is -- why not install Python in /usr/bin
like everyone else?

Perhaps a while ago Python wasn't popular enough to belong in /usr/bin
and decided to modestly stay out of the way in /usr/local/bin instead?

But by now, i think it's quite qualified to take its seat in /usr/bin
along with all the other standard Unix binaries like /usr/bin/vi,
/usr/bin/ftp, /usr/bin/perl, etc.  Python *should* be in the default
binary directory.

Your thoughts?


-- ?!ng




From thomas at xs4all.net  Wed Oct  4 13:35:28 2000
From: thomas at xs4all.net (Thomas Wouters)
Date: Wed, 4 Oct 2000 13:35:28 +0200
Subject: [Python-Dev] Installing python in /usr/bin
In-Reply-To: <Pine.LNX.4.10.10010040357390.4474-100000@skuld.kingmanhall.org>; from ping@lfw.org on Wed, Oct 04, 2000 at 04:02:51AM -0700
References: <Pine.LNX.4.10.10010040357390.4474-100000@skuld.kingmanhall.org>
Message-ID: <20001004133528.G12812@xs4all.nl>

On Wed, Oct 04, 2000 at 04:02:51AM -0700, Ka-Ping Yee wrote:

> So the natural question to ask is -- why not install Python in /usr/bin
> like everyone else?

> Perhaps a while ago Python wasn't popular enough to belong in /usr/bin
> and decided to modestly stay out of the way in /usr/local/bin instead?

The only reason is the hysterical one: it's always been that way.
Traditionally, /usr/local/bin was the place for user-installed binaries.
This sets them apart from the the vendor-supplied binaries (commonly in /bin
and /usr/bin, where /bin are the tools necessary to boot and mount /usr, and
/usr/bin is the rest) and the vendor-installed 3rd-party binaries (commonly
in /usr/contrib/bin, or /opt/bin, or /opt/gnu/bin, and the like.)

> But by now, i think it's quite qualified to take its seat in /usr/bin
> along with all the other standard Unix binaries like /usr/bin/vi,
> /usr/bin/ftp, /usr/bin/perl, etc.  Python *should* be in the default
> binary directory.

Perl only resides in /usr/bin if the vendor (or distribution-maker, in the
case of the Free OSes) put it there. The default for Perl is /usr/local as
well. In fact, almost all source packages default to /usr/local; I have yet
to see a package that uses autoconf and does not have /usr/local as the
default prefix, for instance.

I think the best solution is just for every OS to put /usr/local/bin in
their path, and not pretend they delivered the Definitive Collection of
Useful Programs. Installing Python in /usr can do more damage than good --
think of all the people that are used to have it installed in /usr/local,
don't specify a prefix because they 'know' it's /usr/local by default, and
end up filling up their minimal /usr partition with Python ;)

-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!



From gward at python.net  Tue Oct  3 06:08:45 2000
From: gward at python.net (Greg Ward)
Date: Tue, 3 Oct 2000 00:08:45 -0400
Subject: [Python-Dev] ANNOUNCE: Distutils 1.0
Message-ID: <mailman.970578302.4920.clpa-moderators@python.org>

                     Python Distribution Utilities
                              release 1.0
                            October 2, 2000

The Python Distribution Utilities, or Distutils for short, are a
collection of modules that aid in the development, distribution, and
installation of Python modules.  (It is intended that ultimately the
Distutils will grow up into a system for distributing and installing
whole Python applications, but for now their scope is limited to module
distributions.)

The Distutils are a standard part of Python 1.6 and 2.0; if you are running
1.6 or 2.0, you don't need to install the Distutils separately.  (However,
you might want to upgrade if you're running Python 1.6.)  This release is
primarily so that you can add the Distutils to a Python 1.5.2 installation
-- you will then be able to install modules that require the Distutils, or
use the Distutils to distribute your own modules.

Distutils 1.0 is the version that will be released with Python 2.0 (unless
last-minute bugs pop up).

More information is available at the Distutils web page:

    http://www.python.org/sigs/distutils-sig/

and in the README.txt included in the Distutils source distribution.

You can download the Distutils from

    http://www.python.org/sigs/distutils-sig/download.html

Trivial patches can be sent to me (Greg Ward) at gward at python.net.
Larger patches should be discussed on the Distutils mailing list:
distutils-sig at python.org.

        Greg
-- 
Greg Ward                                      gward at python.net
http://starship.python.net/~gward/
And now for something completely different.




From bwarsaw at beopen.com  Wed Oct  4 15:44:40 2000
From: bwarsaw at beopen.com (Barry A. Warsaw)
Date: Wed, 4 Oct 2000 09:44:40 -0400 (EDT)
Subject: [Python-Dev] Installing python in /usr/bin
References: <Pine.LNX.4.10.10010040357390.4474-100000@skuld.kingmanhall.org>
	<20001004133528.G12812@xs4all.nl>
Message-ID: <14811.13384.137080.196973@anthem.concentric.net>

>>>>> "TW" == Thomas Wouters <thomas at xs4all.net> writes:

    TW> The only reason is the hysterical one: it's always been that
    TW> way.  Traditionally, /usr/local/bin was the place for
    TW> user-installed binaries.

Yes exactly.

And in fact on my RH6.1 system, I have Python in both /usr/bin and
/usr/local/bin.  RedHat sticks its rpms in /usr/bin, and right now,
1.5.2 resides there.  My dev copy gets installed from source into
/usr/local/bin, and that's the current CVS snapshot.  This is as it
should be and all is right in the world.

The rule is -- and ought to be -- that the default install location in
a build-from-source distro is /usr/local.  rpms or other package
installs can install where ever is appropriate for that platform
(e.g. if someone were to build a Solaris pkg distro, it probably ought
to install to /opt by default).

if-it-ain't-broke...-ly y'rs,
-Barry



From nas at arctrix.com  Wed Oct  4 11:46:36 2000
From: nas at arctrix.com (Neil Schemenauer)
Date: Wed, 4 Oct 2000 02:46:36 -0700
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules cPickle.c,2.52,2.53
In-Reply-To: <200010041622.JAA17363@slayer.i.sourceforge.net>; from nascheme@users.sourceforge.net on Wed, Oct 04, 2000 at 09:22:31AM -0700
References: <200010041622.JAA17363@slayer.i.sourceforge.net>
Message-ID: <20001004024636.A13475@glacier.fnational.com>

On Wed, Oct 04, 2000 at 09:22:31AM -0700, Neil Schemenauer wrote:
> Update of /cvsroot/python/python/dist/src/Modules
> In directory slayer.i.sourceforge.net:/tmp/cvs-serv16887/Modules
> 
> Modified Files:
> 	cPickle.c 
> Log Message:
> - Fix a GC bug caused by PyDict_New() failing.
> 
> 
> Index: cPickle.c
> ===================================================================
> RCS file: /cvsroot/python/python/dist/src/Modules/cPickle.c,v
> retrieving revision 2.52
> retrieving revision 2.53
> diff -C2 -r2.52 -r2.53
> *** cPickle.c	2000/09/07 14:35:37	2.52
> --- cPickle.c	2000/10/04 16:22:26	2.53
> ***************
> *** 2876,2880 ****
>                 Py_INCREF(cls);
>                 UNLESS (inst->in_dict=PyDict_New()) {
> !                 Py_DECREF(inst);
>                   goto err;
>                 }
> --- 2876,2881 ----
>                 Py_INCREF(cls);
>                 UNLESS (inst->in_dict=PyDict_New()) {
> !                 inst = (PyInstanceObject *) PyObject_AS_GC(inst);
> !                 PyObject_DEL(inst);
>                   goto err;
>                 }

I aways seem to think harder when reviewing a commit message than
a diff. :(  I just realized that this commit subtly modifies
cPickle's behavior.  Before the change instances __del__ methods
would be called if allocating __dict__ failed.  After the change
they are not.  I think the new behavior is better but the
question is will it break existing code?  I think probably not.

BTW, pickle seems to follow the new behavior.

  Neil



From esr at snark.thyrsus.com  Wed Oct  4 19:17:39 2000
From: esr at snark.thyrsus.com (Eric S. Raymond)
Date: Wed, 4 Oct 2000 13:17:39 -0400
Subject: [Python-Dev] Proposal -- makefile patches and scripts to generate python RPMs
Message-ID: <200010041717.NAA03509@snark.thyrsus.com>

In the course of maintaining fetchmail, I've developed effective
techniques for integrating RPM and lsm generation into the release machinery
of a package.  I'm willing to do this for Python; it will involve
adding a makefile production and a couple of scripts to the
distribution.

The benefit would be that we could generate correct RPMs automatically
and ship them with each release.  I think RPM is a sufficiently
important distribution format to justify this effort.  Comments?
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

The prestige of government has undoubtedly been lowered considerably
by the Prohibition law. For nothing is more destructive of respect for
the government and the law of the land than passing laws which cannot
be enforced. It is an open secret that the dangerous increase of crime
in this country is closely connected with this.
	-- Albert Einstein, "My First Impression of the U.S.A.", 1921



From effbot at telia.com  Wed Oct  4 19:25:37 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Wed, 4 Oct 2000 19:25:37 +0200
Subject: [Python-Dev] Proposal -- makefile patches and scripts to generate python RPMs
References: <200010041717.NAA03509@snark.thyrsus.com>
Message-ID: <002c01c02e28$1dc20d00$766940d5@hagrid>

eric wrote:
> In the course of maintaining fetchmail, I've developed effective
> techniques for integrating RPM and lsm generation into the release machinery
> of a package.  I'm willing to do this for Python; it will involve
> adding a makefile production and a couple of scripts to the
> distribution.
> 
> The benefit would be that we could generate correct RPMs automatically
> and ship them with each release.  I think RPM is a sufficiently
> important distribution format to justify this effort.  Comments?

isn't this a distutils thing?  see:

ftp://python.beopen.com/pub/docco/devel/dist/creating-rpms.html

(lazy programmers just press the "deploy" button, of course ;-)

</F>




From akuchlin at mems-exchange.org  Wed Oct  4 20:02:19 2000
From: akuchlin at mems-exchange.org (Andrew Kuchling)
Date: Wed, 4 Oct 2000 14:02:19 -0400
Subject: [Python-Dev] Proposal -- makefile patches and scripts to generate python RPMs
In-Reply-To: <002c01c02e28$1dc20d00$766940d5@hagrid>; from effbot@telia.com on Wed, Oct 04, 2000 at 07:25:37PM +0200
References: <200010041717.NAA03509@snark.thyrsus.com> <002c01c02e28$1dc20d00$766940d5@hagrid>
Message-ID: <20001004140219.A5125@kronos.cnri.reston.va.us>

On Wed, Oct 04, 2000 at 07:25:37PM +0200, Fredrik Lundh wrote:
>isn't this a distutils thing?  see:
>ftp://python.beopen.com/pub/docco/devel/dist/creating-rpms.html
>(lazy programmers just press the "deploy" button, of course ;-)

It's not immediately obvious that the Distutils 1.0, which after all
mostly aims to support installing Python modules, can be applied to
installing Python itself, what with all the libraries and scripts and
such that Python needs.  It certainly is something to aim for, and I
intend to work on this some more after 2.0, but the attempt might run
into missing Distutil features.  Whether it's worth adding rules for
RPM in the meantime is up to the Pythoneers; I'm 0 on it.  (Not +0 or
-0, just 0 -- a Nirvana-like state of utter unconcern.)

--amk




From gward at mems-exchange.org  Wed Oct  4 20:13:01 2000
From: gward at mems-exchange.org (Greg Ward)
Date: Wed, 4 Oct 2000 14:13:01 -0400
Subject: [Python-Dev] Proposal -- makefile patches and scripts to generate python RPMs
In-Reply-To: <002c01c02e28$1dc20d00$766940d5@hagrid>; from effbot@telia.com on Wed, Oct 04, 2000 at 07:25:37PM +0200
References: <200010041717.NAA03509@snark.thyrsus.com> <002c01c02e28$1dc20d00$766940d5@hagrid>
Message-ID: <20001004141301.A31167@ludwig.cnri.reston.va.us>

On 04 October 2000, Fredrik Lundh said:
> isn't this a distutils thing?  see:
> 
> ftp://python.beopen.com/pub/docco/devel/dist/creating-rpms.html

But the Distutils brag line is:

  The Python Distribution Utilities, or Distutils for short, are a
  collection of modules that aid in the development, distribution, and
  installation of Python modules.

If that first sentence were instead

  The Python Distribution Utilities, or Distutils for short, are a
  collection of modules that aid in the development, distribution, and
  installation of Python.

then you'd have a point.

What a difference one little word can make...

        Greg



From gward at mems-exchange.org  Wed Oct  4 20:16:20 2000
From: gward at mems-exchange.org (Greg Ward)
Date: Wed, 4 Oct 2000 14:16:20 -0400
Subject: [Python-Dev] Adding a section to PEP 0042
Message-ID: <20001004141620.A31293@ludwig.cnri.reston.va.us>

I need to add an entry to PEP 0042 about the lack of cross-compilation
support, because that's a bug report that was assigned to me, and needs
to be marked "Closed/Feature Request/Later" and put in PEP 0042.  Seems
to me that I should just add a section on "Build/Installation" to the
PEP -- anyone disagree?  This might also be a good place to gather
other gripes about Python's build/installation machinery...

        Greg
-- 
Greg Ward - software developer                gward at mems-exchange.org
MEMS Exchange / CNRI                           voice: +1-703-262-5376
Reston, Virginia, USA                            fax: +1-703-262-5367



From effbot at telia.com  Wed Oct  4 20:53:48 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Wed, 4 Oct 2000 20:53:48 +0200
Subject: [Python-Dev] Proposal -- makefile patches and scripts to generate python RPMs
References: <200010041717.NAA03509@snark.thyrsus.com> <002c01c02e28$1dc20d00$766940d5@hagrid> <20001004141301.A31167@ludwig.cnri.reston.va.us>
Message-ID: <007901c02e34$81e32ce0$766940d5@hagrid>

greg wrote:
> If that first sentence were instead
> 
>   The Python Distribution Utilities, or Distutils for short, are a
>   collection of modules that aid in the development, distribution, and
>   installation of Python.
> 
> then you'd have a point.
> 
> What a difference one little word can make...

so why not fix it?  cannot be too hard to remove one
little word, can it? ;-)

</F>




From loewis at informatik.hu-berlin.de  Wed Oct  4 22:31:23 2000
From: loewis at informatik.hu-berlin.de (Martin von Loewis)
Date: Wed, 4 Oct 2000 22:31:23 +0200 (MET DST)
Subject: [Python-Dev] htmllib.HTMLescape()
Message-ID: <200010042031.WAA17378@pandora.informatik.hu-berlin.de>

> Someone just pointed out on c.l.py that we need an HTMLescape()
> function that takes a string and converts special characters to
> entities.  I'm not on python-dev, so could you please forward this
> and find out whether I need to run a PEP?

Doesn't xml.sax.saxutils.escape do what you want (together with
htmlentitydefs)? I was going to say that this is quite a small change
to warrant a PEP - but there are two obvious approaches (working from
scratch, or working on top of xml.sax.saxutils.escape - perhaps
modifying and relocating that function), so *some* design probably
needs to be recorded in a PEP.

Regards,
Martin



From trentm at ActiveState.com  Wed Oct  4 23:17:37 2000
From: trentm at ActiveState.com (Trent Mick)
Date: Wed, 4 Oct 2000 14:17:37 -0700
Subject: [Python-Dev] test_sre.py fails on Win64 because PyOS_CheckStack *never* fails
Message-ID: <20001004141737.A16659@ActiveState.com>

I did not follow the discussion a while back regarding the implementation and
use of PyOS_CheckStack on Windows. In any case, its use (USE_STACKCHECK)
instead of recursion limit checking (USE_RECURSION_LIMIT) in _sre.c results
in this test:
    test(r"""sre.match(r'(x)*', 50000*'x').span()""", (0, 50000), RuntimeError)
in test_sre.py failing on Win64.


This is because PyOS_CheckStack seem to *never* fail on Win64. Three
possibilites:
  (1) I don't understand the PyOS_CheckStack code or I am misintepreting the
      problem.
  (2) The semantics of _alloca() has changed for Win64 such that a stack
      overflow exception is no longer thrown if space cannot be allocated.
      NOTE: I changed the number of pointers allocated in PyOS_CheckStack
            from 2048 to over 1 *Tera*byte and it *still* did not fail.
  (3) I am stoopid.


In any case, I would like to *not* define USE_STACKCHECK on Win64 for the
time being (and for 2.0, unless a Win64 angel comes to me in the next couple
of days). Does anybody have a problem with me checking this in?

*** Include\pythonrun.h~     Wed Oct 04 14:18:00 2000
--- Include\pythonrun.h      Wed Oct 04 13:17:17 2000
***************
*** 88,94 ****
     to a 8k margin. */
  #define PYOS_STACK_MARGIN 2048

! #if defined(WIN32) && defined(_MSC_VER)
  /* Enable stack checking under Microsoft C */
  #define USE_STACKCHECK
  #endif
--- 88,94 ----
     to a 8k margin. */
  #define PYOS_STACK_MARGIN 2048

! #if defined(WIN32) && !defined(MS_WIN64) && defined(_MSC_VER)
  /* Enable stack checking under Microsoft C */
  #define USE_STACKCHECK
  #endif


Thanks,
Trent

-- 
Trent Mick
TrentM at ActiveState.com



From effbot at telia.com  Wed Oct  4 23:34:50 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Wed, 4 Oct 2000 23:34:50 +0200
Subject: [Python-Dev] test_sre.py fails on Win64 because PyOS_CheckStack *never* fails
References: <20001004141737.A16659@ActiveState.com>
Message-ID: <000701c02e4a$edf6b580$766940d5@hagrid>

trent wrote:
> I did not follow the discussion a while back regarding the implementation and
> use of PyOS_CheckStack on Windows. In any case, its use (USE_STACKCHECK)
> instead of recursion limit checking (USE_RECURSION_LIMIT) in _sre.c results
> in this test:
>     test(r"""sre.match(r'(x)*', 50000*'x').span()""", (0, 50000), RuntimeError)
> in test_sre.py failing on Win64.

note that the test assumes that 50000 iterations would be
enough to hit the stack limit.  maybe Win64 has a *huge*
stack?

what does this little program do:

    import sre
    sre.match(r'(x)*', 50000*'x').span()

if it prints (0, 50000), all is well, and the *test* should be
disabled (or modified) on Win64...

</F>




From jeremy at beopen.com  Wed Oct  4 23:35:26 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Wed, 4 Oct 2000 17:35:26 -0400 (EDT)
Subject: [Python-Dev] Proposal -- makefile patches and scripts to generate python RPMs
In-Reply-To: <200010041717.NAA03509@snark.thyrsus.com>
References: <200010041717.NAA03509@snark.thyrsus.com>
Message-ID: <14811.41630.554137.351253@bitdiddle.concentric.net>

>>>>> "ESR" == Eric S Raymond <esr at snark.thyrsus.com> writes:

  ESR> In the course of maintaining fetchmail, I've developed
  ESR> effective techniques for integrating RPM and lsm generation
  ESR> into the release machinery of a package.  I'm willing to do
  ESR> this for Python; it will involve adding a makefile production
  ESR> and a couple of scripts to the distribution.

  ESR> The benefit would be that we could generate correct RPMs
  ESR> automatically and ship them with each release.  I think RPM is
  ESR> a sufficiently important distribution format to justify this
  ESR> effort.  Comments?

We are now distributing RPMs for RH 6 with Python and have plans to
support other distributions we have access to, namely those available
on the SF compile farm.

This page has the RPMs:
http://www.pythonlabs.com/products/python2.0/download_python2.0b2.html

Can you compare this approach to using a hand-crafted .spec file for
the RPMs?  It took a little while to figure out how to generate the
.spec, but now that it has been created it does not seem hard to
maintain.

I imagine, without knowing any details of what you propose, that this
is primarily beneficial for people who do not know how to build RPMs.

Jeremy




From effbot at telia.com  Wed Oct  4 23:43:41 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Wed, 4 Oct 2000 23:43:41 +0200
Subject: [Python-Dev] test_sre.py fails on Win64 because PyOS_CheckStack *never* fails
References: <20001004141737.A16659@ActiveState.com>
Message-ID: <000b01c02e4c$2ac63980$766940d5@hagrid>

trent wrote:
> This is because PyOS_CheckStack seem to *never* fail on Win64. Three
> possibilites:
>   (1) I don't understand the PyOS_CheckStack code or I am misintepreting the
>       problem.
>   (2) The semantics of _alloca() has changed for Win64 such that a stack
>       overflow exception is no longer thrown if space cannot be allocated.
>       NOTE: I changed the number of pointers allocated in PyOS_CheckStack
>             from 2048 to over 1 *Tera*byte and it *still* did not fail.

me again: didn't read the note carefully enough, so I didn't
quite figure out what you said...

:::

what happens if you run this program (on my win95 box, it
counts up to 8, and stops).

#include <malloc.h>
#include <excpt.h>

int __inline
PyOS_CheckStack()
{
    __try {
        _alloca(100000);
        return 0;
    } __except (EXCEPTION_EXECUTE_HANDLER) {
        /* just ignore all errors */
    }
    return 1;
}

void
callme(int i)
{
    char buf[100000];
    if (PyOS_CheckStack())
        return;
    printf("%d\n", i);
    memset(buf, 0, sizeof buf);
    callme(i+1);
}

int
main()
{
    callme(0);
}

:::

if it goes on and on and on, check the assembler output from
this program.

(maybe the win64 compiler is smarter than I -- if it realizes that I
don't actually use the return value from _alloca, it may of course
remove the entire thing...)

</F>




From esr at thyrsus.com  Wed Oct  4 23:56:38 2000
From: esr at thyrsus.com (Eric S. Raymond)
Date: Wed, 4 Oct 2000 17:56:38 -0400
Subject: [Python-Dev] Proposal -- makefile patches and scripts to generate python RPMs
In-Reply-To: <14811.41630.554137.351253@bitdiddle.concentric.net>; from jeremy@beopen.com on Wed, Oct 04, 2000 at 05:35:26PM -0400
References: <200010041717.NAA03509@snark.thyrsus.com> <14811.41630.554137.351253@bitdiddle.concentric.net>
Message-ID: <20001004175638.A4423@thyrsus.com>

Jeremy Hylton <jeremy at beopen.com>:
> We are now distributing RPMs for RH 6 with Python and have plans to
> support other distributions we have access to, namely those available
> on the SF compile farm.
> 
> This page has the RPMs:
> http://www.pythonlabs.com/products/python2.0/download_python2.0b2.html
> 
> Can you compare this approach to using a hand-crafted .spec file for
> the RPMs?  It took a little while to figure out how to generate the
> .spec, but now that it has been created it does not seem hard to
> maintain.
> 
> I imagine, without knowing any details of what you propose, that this
> is primarily beneficial for people who do not know how to build RPMs.

Actually, the point of my approach is *not* to hand-craft the spec file.
What I normally do is write a specfile generator script in shell, which
takes the release version as an argument.  Most of the point of the generator
script is so the file list part of the specfile never has to be handhacked.

So, for example, a specfile generator script for Python would know that for
each library file foo.py in the Python X.Y release tree, it needs to generate 
a file entry /usr/lib/pythonX.Y/foo.py -- that way whenever a module is
added to the library it will automatically ripple through to the RPM.

Then I embed something like this in the Makefile:

# Make RPMs.  You need to be root to make this work
RPMROOT=/usr/src/redhat
RPM = rpm
RPMFLAGS = -ba
rpm: dist
	cp foo-$(VERSION).tar.gz foo.xpm $(RPMROOT)/SOURCES;
	$(srcdir)/specgen.sh $(VERSION) >$(RPMROOT)/SPECS/foo.spec
	cd $(RPMROOT)/SPECS; $(RPM) $(RPMFLAGS) foo.spec	
	cp $(RPMROOT)/RPMS/`arch|sed 's/i[4-9]86/i386/'`/foo*-$(VERSION)*.rpm $(srcdir)
	cp $(RPMROOT)/SRPMS/foo*-$(VERSION)*.src.rpm $(srcdir)

Hey presto!  Instant RPMs.  I use this approach for several of my projects.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

The most foolish mistake we could possibly make would be to permit 
the conquered Eastern peoples to have arms.  History teaches that all 
conquerors who have allowed their subject races to carry arms have 
prepared their own downfall by doing so.
        -- Hitler, April 11 1942, revealing the real agenda of "gun control"



From nas at arctrix.com  Wed Oct  4 18:12:04 2000
From: nas at arctrix.com (Neil Schemenauer)
Date: Wed, 4 Oct 2000 09:12:04 -0700
Subject: [Python-Dev] Proposal -- makefile patches and scripts to generate python RPMs
In-Reply-To: <20001004175638.A4423@thyrsus.com>; from esr@thyrsus.com on Wed, Oct 04, 2000 at 05:56:38PM -0400
References: <200010041717.NAA03509@snark.thyrsus.com> <14811.41630.554137.351253@bitdiddle.concentric.net> <20001004175638.A4423@thyrsus.com>
Message-ID: <20001004091204.A787@glacier.fnational.com>

On Wed, Oct 04, 2000 at 05:56:38PM -0400, Eric S. Raymond wrote:
> Jeremy Hylton <jeremy at beopen.com>:
> > Can you compare this approach to using a hand-crafted .spec file for
> > the RPMs?  It took a little while to figure out how to generate the
> > .spec, but now that it has been created it does not seem hard to
> > maintain.
> Actually, the point of my approach is *not* to hand-craft the spec file.

Okay, but we already have the spec file.  Why is your approach
better?  Is your script that generates the the spec easier to
maintain then the spec file itself?  Is it just as flexible?  If
so then Red Hat screwed up designing RPM.  I can see the utility
of such as script but I don't see how it helps in this situation.

  Neil



From esr at thyrsus.com  Thu Oct  5 04:23:18 2000
From: esr at thyrsus.com (Eric S. Raymond)
Date: Wed, 4 Oct 2000 22:23:18 -0400
Subject: [Python-Dev] Proposal -- makefile patches and scripts to generate python RPMs
In-Reply-To: <20001004091204.A787@glacier.fnational.com>; from nas@arctrix.com on Wed, Oct 04, 2000 at 09:12:04AM -0700
References: <200010041717.NAA03509@snark.thyrsus.com> <14811.41630.554137.351253@bitdiddle.concentric.net> <20001004175638.A4423@thyrsus.com> <20001004091204.A787@glacier.fnational.com>
Message-ID: <20001004222318.E4742@thyrsus.com>

Neil Schemenauer <nas at arctrix.com>:
> On Wed, Oct 04, 2000 at 05:56:38PM -0400, Eric S. Raymond wrote:
> > Jeremy Hylton <jeremy at beopen.com>:
> > > Can you compare this approach to using a hand-crafted .spec file for
> > > the RPMs?  It took a little while to figure out how to generate the
> > > .spec, but now that it has been created it does not seem hard to
> > > maintain.
> > Actually, the point of my approach is *not* to hand-craft the spec file.
> 
> Okay, but we already have the spec file.  Why is your approach
> better?  Is your script that generates the the spec easier to
> maintain then the spec file itself?  Is it just as flexible?  If
> so then Red Hat screwed up designing RPM.  I can see the utility
> of such as script but I don't see how it helps in this situation.

The main thing a specfile generator can accomplish is to automate the
generation of the file list so that (for example) when we add a new
library module the specfile doesn't have to be hand-edited.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

"Guard with jealous attention the public liberty.  Suspect every one
who approaches that jewel.  Unfortunately, nothing will preserve it
but downright force.  Whenever you give up that force, you are
inevitably ruined."
	-- Patrick Henry, speech of June 5 1788



From nas at arctrix.com  Wed Oct  4 23:43:50 2000
From: nas at arctrix.com (Neil Schemenauer)
Date: Wed, 4 Oct 2000 14:43:50 -0700
Subject: [Python-Dev] Release candidate followed by feature freeze?
In-Reply-To: <200010030236.VAA02702@cj20424-a.reston1.va.home.com>; from guido@python.org on Mon, Oct 02, 2000 at 09:36:03PM -0500
References: <200010011913.VAA01107@pandora.informatik.hu-berlin.de> <200010021919.OAA01232@cj20424-a.reston1.va.home.com> <20001002044859.A9639@glacier.fnational.com> <200010030236.VAA02702@cj20424-a.reston1.va.home.com>
Message-ID: <20001004144350.A434@glacier.fnational.com>

On Mon, Oct 02, 2000 at 09:36:03PM -0500, Guido van Rossum wrote:
> Hooft's problem makes heavy use of Tkinter and Pmw, it seems.  Maybe
> that's a clue?

Rob was kind enough to send me some code to trigger the bug.  The
winner is ... tupleobject.c!  When MAXSAVESIZE is zero Rob's
program seems to work fine.  I think Pmw uses lots of tuples.

Looking closely at the code I see that _PyTuple_Resize is almost
certainly buggy.  I think something is wrong with PyTuple_New as
well.  I'll have to come up with a patch later as it is much to
late now for me to fully understand such hairy code. :(

  Neil



From pf at artcom-gmbh.de  Thu Oct  5 07:55:19 2000
From: pf at artcom-gmbh.de (Peter Funk)
Date: Thu, 5 Oct 2000 07:55:19 +0200 (MEST)
Subject: [Python-Dev] irritating 'No such file or directory' message (was Re: [Python-checkins] CVS: python/nondist/peps pep-0004.txt,NONE,1.1)
In-Reply-To: <200010042240.PAA14714@slayer.i.sourceforge.net> from Barry Warsaw at "Oct 4, 2000  3:40:33 pm"
Message-ID: <m13h3zz-000DmMC@artcom0.artcom-gmbh.de>

Hi,

Barry Warsaw :
> Update of /cvsroot/python/python/nondist/peps
> In directory slayer.i.sourceforge.net:/tmp/cvs-serv14669
> 
> Added Files:
> 	pep-0004.txt 
> Log Message:
> Added PEP 4, Deprecation of Standard Modules, Martin von Loewis
> 
> 
> ***** Error reading new file: (2, 'No such file or directory')

Whenever Barry adds a new file to the CVS, its initial content
is invisible on the checkins mailing list due to the error message
above.  However if for example fdrake adds a new file (for example the
support.py recently added to the doc subtree) then this doesn't happen.
Is there anybody out there able to fix this for future checkins-mails?

Regards, Peter



From fdrake at beopen.com  Thu Oct  5 08:23:10 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Thu, 5 Oct 2000 02:23:10 -0400 (EDT)
Subject: [Python-Dev] irritating 'No such file or directory' message (was Re: [Python-checkins] CVS: python/nondist/peps pep-0004.txt,NONE,1.1)
In-Reply-To: <m13h3zz-000DmMC@artcom0.artcom-gmbh.de>
References: <200010042240.PAA14714@slayer.i.sourceforge.net>
	<m13h3zz-000DmMC@artcom0.artcom-gmbh.de>
Message-ID: <14812.7758.940994.732616@cj42289-a.reston1.va.home.com>

Peter Funk writes:
 > Whenever Barry adds a new file to the CVS, its initial content
 > is invisible on the checkins mailing list due to the error message
 > above.  However if for example fdrake adds a new file (for example the
 > support.py recently added to the doc subtree) then this doesn't happen.
 > Is there anybody out there able to fix this for future checkins-mails?

  Wow!  I had noticed the bolluxed messages, but hadn't tied it to
Barry!  But I just checked the added files for this month and
spot-checked the ones from last month, and Barry's all exhibit this
problem, and no one else's do.
  I wonder if something is wrong with his SourceForge account?  Barry,
check your group memberships, please!  If nothing obvious is wrong,
submit a support request, because this is definately annoying.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From tim_one at email.msn.com  Thu Oct  5 09:09:20 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Thu, 5 Oct 2000 03:09:20 -0400
Subject: [Python-Dev] change to Lib/popen2.py break test_popen2 on windows
In-Reply-To: <20001003161009.B18387@ActiveState.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCOEKMHJAA.tim_one@email.msn.com>

[Trent Mick, pointing out that test_popen2 was busted on Windows]
> Geez, you are fast Tim! (for others: he patched test_popen.py
> after I sent my email but before my email made it to python-dev!)

I hate to be honest, but I actually pointed out the test_popen2 failure on
Python-Dev last week.  However, I was On Vacation(tm) then, so thought
merely mentioning it would shame someone else into fixing it.  At this
point, I'll happily settle for that somebody else eventually *noticed* it!

our-windows-testing-dept-may-be-on-permanent-vacation-ly y'rs  - tim





From tim_one at email.msn.com  Thu Oct  5 09:09:17 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Thu, 5 Oct 2000 03:09:17 -0400
Subject: [Python-Dev] pep42 procedure?
In-Reply-To: <ECEPKNMJLHAPFFJHDOJBAEBJDMAA.MarkH@ActiveState.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCMEKMHJAA.tim_one@email.msn.com>

[Mark Hammond]
> That would be a great idea, if only we had a PEP author.  To be honest,
> I really dont care too much about this issue, and have been doing my
> level best to avoid it.  But Tim knows that, and delights in assigning
> related patches to me ;-)  I certainly don't care enough to own a pep
> on it. ...

I assign them to you because there's barely a line of Windows startup code
you didn't write, and you gave Windows the notion of naming the main DLL
differently across (some) different releases thus creating the possibility
for the problem these patches are trying to solve <wink>.  That's not to say
it's "your problem", but is to say you've thought more about "stuff like
this" than anyone else, and have very particular ideas about how you want
"stuff like this" done:  you're the best qualified.

That said, the subject of the PEP shouldn't be competing hacks to worm
around Windows-specific startup problems, it should be an actual design for
binary compatibility across iterations of the C API, or at least a reliable
way for extensions to *know* they're not getting a version of the Python
core they can use.

we're-only-hacking-because-we've-ignored-the-real-problem-ly y'rs  - tim





From martin at loewis.home.cs.tu-berlin.de  Thu Oct  5 09:44:52 2000
From: martin at loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Thu, 5 Oct 2000 09:44:52 +0200
Subject: [Python-Dev] Proposal -- makefile patches and scripts to generate python RPMs
Message-ID: <200010050744.JAA00782@loewis.home.cs.tu-berlin.de>

> The main thing a specfile generator can accomplish is to automate
> the generation of the file list so that (for example) when we add a
> new library module the specfile doesn't have to be hand-edited.

That sounds similar to the rationale for having automatically
generated dependency files for make, e.g. by gcc -MM. Many projects
use this as a convenience, and it kind-of works. However, I still like
it better to have dependencies explicitly recorded in the
Makefiles. That requires more discipline, but is easier to understand,
and the behaviour is more reproducable.

So given the option of using an existing hand-written spec file, and
having some magic generate one for me, I'd always use the hand-written
one. The magic is only good if there is no hand-written one.

Regards,
Martin




From fredrik at pythonware.com  Thu Oct  5 09:50:37 2000
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Thu, 5 Oct 2000 09:50:37 +0200
Subject: [Python-Dev] Release candidate followed by feature freeze?
References: <200010011913.VAA01107@pandora.informatik.hu-berlin.de> <200010021919.OAA01232@cj20424-a.reston1.va.home.com> <20001002044859.A9639@glacier.fnational.com> <200010030236.VAA02702@cj20424-a.reston1.va.home.com> <20001004144350.A434@glacier.fnational.com>
Message-ID: <00e301c02ea0$f3ea5680$0900a8c0@SPIFF>

neil wrote:
> On Mon, Oct 02, 2000 at 09:36:03PM -0500, Guido van Rossum wrote:
> > Hooft's problem makes heavy use of Tkinter and Pmw, it seems.  Maybe
> > that's a clue?
> 
> Rob was kind enough to send me some code to trigger the bug.  The
> winner is ... tupleobject.c!  When MAXSAVESIZE is zero Rob's
> program seems to work fine.  I think Pmw uses lots of tuples.

The new version of Tkinter contains a _flatten function written in C,
which uses PyTuple_Resize extensively.

To check if Rob's program works better without it, you can comment
out the "_flatten = _tkinter._flatten" line in Tkinter.py (it's line 70 or
so, iirc).

</F>




From larsga at garshol.priv.no  Thu Oct  5 10:36:33 2000
From: larsga at garshol.priv.no (Lars Marius Garshol)
Date: 05 Oct 2000 10:36:33 +0200
Subject: [Python-Dev] htmllib.HTMLescape()
In-Reply-To: <200010042031.WAA17378@pandora.informatik.hu-berlin.de>
References: <200010042031.WAA17378@pandora.informatik.hu-berlin.de>
Message-ID: <m3itr7elbi.fsf@lambda.garshol.priv.no>

* Martin von Loewis
| 
| Doesn't xml.sax.saxutils.escape do what you want (together with
| htmlentitydefs)? I was going to say that this is quite a small
| change to warrant a PEP - but there are two obvious approaches
| (working from scratch, or working on top of xml.sax.saxutils.escape
| - perhaps modifying and relocating that function), so *some* design
| probably needs to be recorded in a PEP.

It would probably help, but now that Python has Unicode support there
should be some way to convert string data to a legacy encoding and
represent all characters not available in that encoding using numeric
character references.  This would be very useful for both XML and
HTML.  The difficulty, I assume, lies in figuring out which encodings
support what characters.

--Lars M.




From nas at arctrix.com  Thu Oct  5 07:59:38 2000
From: nas at arctrix.com (Neil Schemenauer)
Date: Wed, 4 Oct 2000 22:59:38 -0700
Subject: [Python-Dev] Release candidate followed by feature freeze?
In-Reply-To: <00e301c02ea0$f3ea5680$0900a8c0@SPIFF>; from fredrik@pythonware.com on Thu, Oct 05, 2000 at 09:50:37AM +0200
References: <200010011913.VAA01107@pandora.informatik.hu-berlin.de> <200010021919.OAA01232@cj20424-a.reston1.va.home.com> <20001002044859.A9639@glacier.fnational.com> <200010030236.VAA02702@cj20424-a.reston1.va.home.com> <20001004144350.A434@glacier.fnational.com> <00e301c02ea0$f3ea5680$0900a8c0@SPIFF>
Message-ID: <20001004225938.A802@glacier.fnational.com>

On Thu, Oct 05, 2000 at 09:50:37AM +0200, Fredrik Lundh wrote:
> The new version of Tkinter contains a _flatten function written in C,
> which uses PyTuple_Resize extensively.
> 
> To check if Rob's program works better without it, you can comment
> out the "_flatten = _tkinter._flatten" line in Tkinter.py (it's line 70 or
> so, iirc).

That fixes the crash as well.

  Neil



From bwarsaw at beopen.com  Thu Oct  5 15:33:53 2000
From: bwarsaw at beopen.com (Barry A. Warsaw)
Date: Thu, 5 Oct 2000 09:33:53 -0400 (EDT)
Subject: [Python-Dev] irritating 'No such file or directory' message (was Re: [Python-checkins] CVS: python/nondist/peps pep-0004.txt,NONE,1.1)
References: <200010042240.PAA14714@slayer.i.sourceforge.net>
	<m13h3zz-000DmMC@artcom0.artcom-gmbh.de>
	<14812.7758.940994.732616@cj42289-a.reston1.va.home.com>
Message-ID: <14812.33601.730022.889777@anthem.concentric.net>

>>>>> "Fred" == Fred L Drake, Jr <fdrake at beopen.com> writes:

    Fred>   Wow!  I had noticed the bolluxed messages, but hadn't tied
    Fred> it to Barry!  But I just checked the added files for this
    Fred> month and spot-checked the ones from last month, and Barry's
    Fred> all exhibit this problem, and no one else's do.  I wonder if
    Fred> something is wrong with his SourceForge account?  Barry,
    Fred> check your group memberships, please!  If nothing obvious is
    Fred> wrong, submit a support request, because this is definately
    Fred> annoying.

I don't understand why this is happening, esp. just for me!  My
primary group is users and I'm definitely in the python group as
well.  Why would it be a permission problem anyway, since that's not
what the error message is saying?

Better log messages in syncmail would help diagnose this, but I
haven't got the time right now to hack on that.

-Barry



From pf at artcom-gmbh.de  Thu Oct  5 15:54:58 2000
From: pf at artcom-gmbh.de (Peter Funk)
Date: Thu, 5 Oct 2000 15:54:58 +0200 (MEST)
Subject: [Python-Dev] irritating 'No such file or directory' message (was Re: [Python-checkins] CVS: python/nondist/peps pep-0004.txt
In-Reply-To: <14812.33601.730022.889777@anthem.concentric.net> from "Barry A. Warsaw" at "Oct 5, 2000  9:33:53 am"
Message-ID: <m13hBUA-000DmMC@artcom0.artcom-gmbh.de>

Hi,

Barry A. Warsaw:
> 
> >>>>> "Fred" == Fred L Drake, Jr <fdrake at beopen.com> writes:
> 
>     Fred>   Wow!  I had noticed the bolluxed messages, but hadn't tied
>     Fred> it to Barry!  But I just checked the added files for this
>     Fred> month and spot-checked the ones from last month, and Barry's
>     Fred> all exhibit this problem, and no one else's do.  I wonder if
>     Fred> something is wrong with his SourceForge account?  Barry,
>     Fred> check your group memberships, please!  If nothing obvious is
>     Fred> wrong, submit a support request, because this is definately
>     Fred> annoying.
> 
> I don't understand why this is happening, esp. just for me!  My
> primary group is users and I'm definitely in the python group as
> well.  Why would it be a permission problem anyway, since that's not
> what the error message is saying?
> 
> Better log messages in syncmail would help diagnose this, but I
> haven't got the time right now to hack on that.

Just speculating: it has something todo with the current directory 
where the cvs commit command is executed in or it depends on the 
difference that the PEPs are under nondist and Freds files were under dist.

Possible ugly workaround for Barry: for new files first commit an empty 
file and then the real file just a moment later. ;-)

Regards, Peter
-- 
Peter Funk, Oldenburger Str.86, D-27777 Ganderkesee, Germany, Fax:+49 4222950260
office: +49 421 20419-0 (ArtCom GmbH, Grazer Str.8, D-28359 Bremen)



From jeremy at beopen.com  Thu Oct  5 16:42:31 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Thu, 5 Oct 2000 10:42:31 -0400 (EDT)
Subject: [Python-Dev] Release candidate schedule
Message-ID: <14812.37719.248406.924744@bitdiddle.concentric.net>

There are still a number of open bugs that need to be addressed before
we can issue a release candidate.  We plan to issue the release
candidate on Monday and the final release a week later.

According to the Sourceforge bug report --
http://sourceforge.net/bugs/reporting/?group_id=5470&run_report=1&tech=1
-- the following people still have open bugs:

akuchlin (3) 
bwarsaw (3) 
dcjim (2) 
effbot (5) 
fdrake (4) 
gvanrossum (12) 
gward (1) 
jackjansen (1) 
jhylton (8) 
lemburg (2) 
mhammond (5) 
nascheme (3) 
tim_one (5)

I don't expect that every bug will be closed before 2.0 final, but
there are some open bugs about test failures and build problems with
2.0 beta releases.  We should address these if at all possible.

Please review your open bugs and make sure you aren't forgetting about
something.  If you have bugs that will not be fixed for 2.0, make sure
they have a fairly low priority.  If you have bugs you will not be
able to address, assign them to me.

Jeremy



From effbot at telia.com  Thu Oct  5 16:53:48 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Thu, 5 Oct 2000 16:53:48 +0200
Subject: [Python-Dev] Release candidate followed by feature freeze?
References: <200010011913.VAA01107@pandora.informatik.hu-berlin.de> <200010021919.OAA01232@cj20424-a.reston1.va.home.com> <20001002044859.A9639@glacier.fnational.com> <200010030236.VAA02702@cj20424-a.reston1.va.home.com> <20001004144350.A434@glacier.fnational.com> <00e301c02ea0$f3ea5680$0900a8c0@SPIFF> <20001004225938.A802@glacier.fnational.com>
Message-ID: <002501c02edc$1302b040$766940d5@hagrid>

what's the current release schedule, btw?

is the repository frozen, or do we still have a chance to fix
the GC tuple problem and SRE's "nothing to repeat" bug?

</F>




From effbot at telia.com  Thu Oct  5 16:51:25 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Thu, 5 Oct 2000 16:51:25 +0200
Subject: [Python-Dev] Release candidate followed by feature freeze?
References: <200010011913.VAA01107@pandora.informatik.hu-berlin.de> <200010021919.OAA01232@cj20424-a.reston1.va.home.com> <20001002044859.A9639@glacier.fnational.com> <200010030236.VAA02702@cj20424-a.reston1.va.home.com> <20001004144350.A434@glacier.fnational.com> <00e301c02ea0$f3ea5680$0900a8c0@SPIFF> <20001004225938.A802@glacier.fnational.com>
Message-ID: <002401c02edc$12aec3e0$766940d5@hagrid>

> > To check if Rob's program works better without it, you can comment
> > out the "_flatten = _tkinter._flatten" line in Tkinter.py (it's line 70 or
> > so, iirc).
> 
> That fixes the crash as well.

in other words, _PyTuple_Resize needs some work...

(or does _flatten do something wrong?  it starts by creating
a tuple, and if it needs more space, it doubles the size one or
more times, and ends by calling Resize again to set the final
size...)

:::

btw, the start of Resize looks a bit strange: should that
DECREF really be there?  should least be an XDECREF, or
am I missing something?

 if (v == NULL || !PyTuple_Check(v) || v->ob_refcnt != 1) {
  *pv = 0;
  Py_DECREF(v); /* really? what if v is NULL? */
  PyErr_BadInternalCall();
  return -1;
 }

</F>




From mal at lemburg.com  Thu Oct  5 17:00:12 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Thu, 05 Oct 2000 17:00:12 +0200
Subject: [Python-Dev] Proposal -- makefile patches and scripts to generate 
 python RPMs
References: <200010041717.NAA03509@snark.thyrsus.com> <002c01c02e28$1dc20d00$766940d5@hagrid> <20001004140219.A5125@kronos.cnri.reston.va.us>
Message-ID: <39DC977C.89D14AB1@lemburg.com>

Andrew Kuchling wrote:
> 
> On Wed, Oct 04, 2000 at 07:25:37PM +0200, Fredrik Lundh wrote:
> >isn't this a distutils thing?  see:
> >ftp://python.beopen.com/pub/docco/devel/dist/creating-rpms.html
> >(lazy programmers just press the "deploy" button, of course ;-)
> 
> It's not immediately obvious that the Distutils 1.0, which after all
> mostly aims to support installing Python modules, can be applied to
> installing Python itself, what with all the libraries and scripts and
> such that Python needs.  It certainly is something to aim for, and I
> intend to work on this some more after 2.0, but the attempt might run
> into missing Distutil features.  Whether it's worth adding rules for
> RPM in the meantime is up to the Pythoneers; I'm 0 on it.  (Not +0 or
> -0, just 0 -- a Nirvana-like state of utter unconcern.)

distutils is not useful for installing Python (it needs Python
to start with), but it does a pretty good job at finding the
needed files and can generate RPMs which can be used without
distutils or Python. It even allows adding handcrafted sections
to the resulting RPM.

If anybody plans to help in this direction, I'd suggest to add
those efforts to the build_rpm command in distutils (and the
build_deb command for that matter).

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From akuchlin at mems-exchange.org  Thu Oct  5 17:24:32 2000
From: akuchlin at mems-exchange.org (Andrew Kuchling)
Date: Thu, 5 Oct 2000 11:24:32 -0400
Subject: [Python-Dev] Proposal -- makefile patches and scripts to generate python RPMs
In-Reply-To: <39DC977C.89D14AB1@lemburg.com>; from mal@lemburg.com on Thu, Oct 05, 2000 at 05:00:12PM +0200
References: <200010041717.NAA03509@snark.thyrsus.com> <002c01c02e28$1dc20d00$766940d5@hagrid> <20001004140219.A5125@kronos.cnri.reston.va.us> <39DC977C.89D14AB1@lemburg.com>
Message-ID: <20001005112432.A30233@kronos.cnri.reston.va.us>

On Thu, Oct 05, 2000 at 05:00:12PM +0200, M.-A. Lemburg wrote:
>distutils is not useful for installing Python (it needs Python
>to start with), ...

Note that the Distutils doesn't need many C-based modules: _sre,
posix, and string are about it.  So those modules could be
automatically compiled into the Python binary (perhaps being moved
from Modules/ into Python/ to signify their new importance) and the
resulting binary should have enough marbles to run a setup.py script
that would build everything else in Modules/.  

The downside is that you could no longer compile those 3 modules as
dynamically loadable, but the upside is that the setup.py could be
smarter about detecting which libraries are available on the system,
and compiling everything which can be.  This would, one hopes, make
Setup file hacking a thing of the past...

--amk





From tismer at appliedbiometrics.com  Thu Oct  5 16:33:54 2000
From: tismer at appliedbiometrics.com (Christian Tismer)
Date: Thu, 05 Oct 2000 17:33:54 +0300
Subject: [Python-Dev] Stackless Python Mailing List
Message-ID: <39DC9152.7998DFC0@appliedbiometrics.com>

Hi Pythoneers (without or not without Stack (yet:))

there have been a couple of interviews, and some
articles on Stackless Python are published or in
preparation. I recognize an increasing number
of individual emails concerning Stackless Python.

This lets me take the opportunity to start a mailing
list on Stackless Python, an overdue task.

The goal of this list is two-fold:
On the one hand, people should have a forum to
discuss their use of SLP, its further development,
concurrency in general, and more.
The other reason is to increase the support for SLP,
with the final goal to get it merged into Standard Python.
There are a couple of ways to help me with that, see
http://starShip.python.net/mailman/listinfo/stackless

Everybody who is interested in Stackless Python and
all the related topics may feel invited to join this
discussion group.

cheers - chris

-- 
Christian Tismer             :^)   <mailto:tismer at appliedbiometrics.com>
Applied Biometrics GmbH      :     Have a break! Take a ride on Python's
Kaunstr. 26                  :    *Starship* http://starship.python.net
14163 Berlin                 :     PGP key -> http://wwwkeys.pgp.net
PGP Fingerprint       E182 71C7 1A9D 66E9 9D15  D3CC D4D7 93E2 1FAE F6DF
     where do you want to jump today?   http://www.stackless.com



From nas at arctrix.com  Thu Oct  5 10:40:28 2000
From: nas at arctrix.com (Neil Schemenauer)
Date: Thu, 5 Oct 2000 01:40:28 -0700
Subject: [Python-Dev] Release candidate followed by feature freeze?
In-Reply-To: <002401c02edc$12aec3e0$766940d5@hagrid>; from effbot@telia.com on Thu, Oct 05, 2000 at 04:51:25PM +0200
References: <200010011913.VAA01107@pandora.informatik.hu-berlin.de> <200010021919.OAA01232@cj20424-a.reston1.va.home.com> <20001002044859.A9639@glacier.fnational.com> <200010030236.VAA02702@cj20424-a.reston1.va.home.com> <20001004144350.A434@glacier.fnational.com> <00e301c02ea0$f3ea5680$0900a8c0@SPIFF> <20001004225938.A802@glacier.fnational.com> <002401c02edc$12aec3e0$766940d5@hagrid>
Message-ID: <20001005014028.A1055@glacier.fnational.com>

On Thu, Oct 05, 2000 at 04:51:25PM +0200, Fredrik Lundh wrote:
> in other words, _PyTuple_Resize needs some work...

Yup.  I've attached a patch which I believe fixes some GC bugs in
addition to making it simpler.

> btw, the start of Resize looks a bit strange: should that
> DECREF really be there?  should least be an XDECREF, or
> am I missing something?
> 
>  if (v == NULL || !PyTuple_Check(v) || v->ob_refcnt != 1) {
>   *pv = 0;
>   Py_DECREF(v); /* really? what if v is NULL? */
>   PyErr_BadInternalCall();
>   return -1;
>  }

I think your right.  Here's a fun little program:

    from _tkinter import _flatten
    import random # don't ask me why
    for x in xrange(10000):
        print x
        t = _flatten([(0,)*x]*x)

It gives:

    0
    1
    2
    3
    4
    5
    Segmentation fault

on the two Linux machines I've tested it on.  It also crashes
with GC disabled.

  Neil


*** Objects/tupleobject.c	Thu Oct  5 11:31:30 2000
--- tupleobject.c	Thu Oct  5 10:47:44 2000
***************
*** 500,531 ****
  	} else 
  #endif		
  	{
! #ifdef WITH_CYCLE_GC
! 		PyGC_Head *g = PyObject_AS_GC((PyObject *)v);
! 		PyObject_GC_Fini((PyObject *)v);
! 		g = (PyGC_Head *)
! 			PyObject_REALLOC((char *)g, sizeof(PyTupleObject) 
! 					+ PyGC_HEAD_SIZE
! 					+ newsize * sizeof(PyObject *));
! 		if (g == NULL) {
! 			sv = NULL;
! 		} else {
! 			sv = (PyTupleObject *)PyObject_FROM_GC(g);
! 		}
! #else
  		sv = (PyTupleObject *)
! 			PyObject_REALLOC((char *)v, sizeof(PyTupleObject) 
! 					+ PyGC_HEAD_SIZE
! 					+ newsize * sizeof(PyObject *));
! #endif
! 		*pv = (PyObject *) sv;
  		if (sv == NULL) {
! 			PyObject_GC_Init((PyObject *)v);
! 			v = (PyTupleObject *) PyObject_AS_GC(v);
  			PyObject_DEL(v);
  			PyErr_NoMemory();
  			return -1;
  		}
  	}
  	_Py_NewReference((PyObject *)sv);
  	for (i = sv->ob_size; i < newsize; i++)
--- 500,519 ----
  	} else 
  #endif		
  	{
! 		PyObject_GC_Fini(v);
! 		v = (PyObject *) PyObject_AS_GC(v);
  		sv = (PyTupleObject *)
! 			PyObject_REALLOC((char *)v, sizeof(PyTupleObject)
! 					 + PyGC_HEAD_SIZE
! 					 + newsize * sizeof(PyObject *));
  		if (sv == NULL) {
! 			*pv = NULL;
  			PyObject_DEL(v);
  			PyErr_NoMemory();
  			return -1;
  		}
+ 		sv = (PyTupleObject *) PyObject_FROM_GC(sv);
+ 		*pv = (PyObject *) sv;
  	}
  	_Py_NewReference((PyObject *)sv);
  	for (i = sv->ob_size; i < newsize; i++)






From guido at python.org  Thu Oct  5 20:22:49 2000
From: guido at python.org (Guido van Rossum)
Date: Thu, 05 Oct 2000 13:22:49 -0500
Subject: [Python-Dev] forwarded message from aahz@panix.com
In-Reply-To: Your message of "Wed, 04 Oct 2000 02:07:06 -0400."
             <14810.51466.486982.938180@anthem.concentric.net> 
References: <14810.51466.486982.938180@anthem.concentric.net> 
Message-ID: <200010051822.NAA14228@cj20424-a.reston1.va.home.com>

[Aahz]
> Someone just pointed out on c.l.py that we need an HTMLescape() function
> that takes a string and converts special characters to entities.  I'm
> not on python-dev, so could you please forward this and find out whether
> I need to run a PEP?

Has someone pointed out yet that this is done by cgi.escape()?

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



From guido at python.org  Thu Oct  5 20:24:20 2000
From: guido at python.org (Guido van Rossum)
Date: Thu, 05 Oct 2000 13:24:20 -0500
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules cPickle.c,2.52,2.53
In-Reply-To: Your message of "Wed, 04 Oct 2000 02:46:36 MST."
             <20001004024636.A13475@glacier.fnational.com> 
References: <200010041622.JAA17363@slayer.i.sourceforge.net>  
            <20001004024636.A13475@glacier.fnational.com> 
Message-ID: <200010051824.NAA14253@cj20424-a.reston1.va.home.com>

> I aways seem to think harder when reviewing a commit message than
> a diff. :(  I just realized that this commit subtly modifies
> cPickle's behavior.  Before the change instances __del__ methods
> would be called if allocating __dict__ failed.  After the change
> they are not.  I think the new behavior is better but the
> question is will it break existing code?  I think probably not.

This is goodness.  Don't worry about breaking code -- it probably
*fixes* code.  Most __del__ methods don't know what to do when the
instance variables haven't been defined yet!

> BTW, pickle seems to follow the new behavior.

Even better.

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



From guido at python.org  Thu Oct  5 20:29:27 2000
From: guido at python.org (Guido van Rossum)
Date: Thu, 05 Oct 2000 13:29:27 -0500
Subject: [Python-Dev] Adding a section to PEP 0042
In-Reply-To: Your message of "Wed, 04 Oct 2000 14:16:20 -0400."
             <20001004141620.A31293@ludwig.cnri.reston.va.us> 
References: <20001004141620.A31293@ludwig.cnri.reston.va.us> 
Message-ID: <200010051829.NAA14300@cj20424-a.reston1.va.home.com>

> I need to add an entry to PEP 0042 about the lack of cross-compilation
> support, because that's a bug report that was assigned to me, and needs
> to be marked "Closed/Feature Request/Later" and put in PEP 0042.  Seems
> to me that I should just add a section on "Build/Installation" to the
> PEP -- anyone disagree?  This might also be a good place to gather
> other gripes about Python's build/installation machinery...

+1

(I think the "Library" section is growing too big and may be split in
"Lib" and "Modules" sections.)

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



From guido at python.org  Thu Oct  5 20:33:47 2000
From: guido at python.org (Guido van Rossum)
Date: Thu, 05 Oct 2000 13:33:47 -0500
Subject: [Python-Dev] Proposal -- makefile patches and scripts to generate python RPMs
In-Reply-To: Your message of "Thu, 05 Oct 2000 09:44:52 +0200."
             <200010050744.JAA00782@loewis.home.cs.tu-berlin.de> 
References: <200010050744.JAA00782@loewis.home.cs.tu-berlin.de> 
Message-ID: <200010051833.NAA14356@cj20424-a.reston1.va.home.com>

Whatever the outcome of this discussion, this is too late for 2.0.

But I tend to side with Jeremy and Martin -- "explicit is better".
I do want Jeremy to check his RPM generation scripts in, so they can
be improved in a truly open source project.  (Maybe in Tools/rpm?)

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



From guido at python.org  Thu Oct  5 20:43:30 2000
From: guido at python.org (Guido van Rossum)
Date: Thu, 05 Oct 2000 13:43:30 -0500
Subject: [Python-Dev] Release candidate followed by feature freeze?
In-Reply-To: Your message of "Thu, 05 Oct 2000 16:53:48 +0200."
             <002501c02edc$1302b040$766940d5@hagrid> 
References: <200010011913.VAA01107@pandora.informatik.hu-berlin.de> <200010021919.OAA01232@cj20424-a.reston1.va.home.com> <20001002044859.A9639@glacier.fnational.com> <200010030236.VAA02702@cj20424-a.reston1.va.home.com> <20001004144350.A434@glacier.fnational.com> <00e301c02ea0$f3ea5680$0900a8c0@SPIFF> <20001004225938.A802@glacier.fnational.com>  
            <002501c02edc$1302b040$766940d5@hagrid> 
Message-ID: <200010051843.NAA14435@cj20424-a.reston1.va.home.com>

> what's the current release schedule, btw?

Let me give that a shot...

-   Feature Freeze Now.  I.e. it's too late for anything even vaguely
    resembling a feature -- even if it's been discussed to death.

-   Bugfix Checkin Freeze Saturday (Oct 7)
    Starting Saturday, all checkins must be coordinated with the
    releasemeister (still Jeremy).

-   Release Candidate Monday (Oct 9)

-   Final Release Monday week (Oct 16)

Between the Release Candidate and the Final Release, all checkins must
fix bugs and must be approved by the releasemeister.

> is the repository frozen, or do we still have a chance to fix
> the GC tuple problem and SRE's "nothing to repeat" bug?

Simple bugfixes are okay till Saturday.  Bugfixes that are complex and
may break other stuff should be discussed with the releasemeister,
possibly cc'ing python-dev.

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



From effbot at telia.com  Thu Oct  5 20:05:54 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Thu, 5 Oct 2000 20:05:54 +0200
Subject: [Python-Dev] Release candidate followed by feature freeze?
References: <200010011913.VAA01107@pandora.informatik.hu-berlin.de> <200010021919.OAA01232@cj20424-a.reston1.va.home.com> <20001002044859.A9639@glacier.fnational.com> <200010030236.VAA02702@cj20424-a.reston1.va.home.com> <20001004144350.A434@glacier.fnational.com> <00e301c02ea0$f3ea5680$0900a8c0@SPIFF> <20001004225938.A802@glacier.fnational.com> <002401c02edc$12aec3e0$766940d5@hagrid> <20001005014028.A1055@glacier.fnational.com>
Message-ID: <002a01c02ef6$ee698860$766940d5@hagrid>

neil wrote:
> Yup.  I've attached a patch which I believe fixes some GC bugs in
> addition to making it simpler.

don't have the slightest idea how the GC stuff works,
but it sure looks right: just go ahead and check it in...

> > btw, the start of Resize looks a bit strange: should that
> > DECREF really be there?  should least be an XDECREF, or
> > am I missing something?
> > 
> >  if (v == NULL || !PyTuple_Check(v) || v->ob_refcnt != 1) {
> >   *pv = 0;
> >   Py_DECREF(v); /* <- really? what if v is NULL? */
> >   PyErr_BadInternalCall();
> >   return -1;
> >  }
> 
> I think your right.  Here's a fun little program:
> 
>     from _tkinter import _flatten
>     import random # don't ask me why
>     for x in xrange(10000):
>         print x
>         t = _flatten([(0,)*x]*x)
> 
> It gives:
> 
>     0
>     1
>     2
>     3
>     4
>     5
>     Segmentation fault

guido?

</F>




From jim at digicool.com  Thu Oct  5 20:10:42 2000
From: jim at digicool.com (Jim Fulton)
Date: Thu, 05 Oct 2000 14:10:42 -0400
Subject: [Python-Dev] Re: [medusa] select, signals, and "interrupted system call" (EINTR)
References: <39D74AFB.322E5187@digicool.com> <14807.35727.423642.721873@seattle.nightmare.com>
Message-ID: <39DCC422.90E4D0D5@digicool.com>

Sam Rushing wrote:
> 
> Jim Fulton writes:
>  > The asyncore main loop should check for this error in it's select
>  > call and the select module should make this error easier to check
>  > for.
> 
> It might go better into the event_loop function, which I think of as a
> more user-serviceable part.  [for example, the default loop vs. the
> one in medusa/event_loop.py that supports schedulable events]

Don't you think anyone using select on Unix would want this?
This isn't really an application-specific thing is it?

>  > I presume that this works in Python 1.6/2.0, but I
>  > haven't tried it yet?
>  >
>  > This depends on the structure of select.error values
>  > and requires that we get EINTR from somewhere. (What
>  > should the value be on NT?)
> 
> If it's a big problem, I guess we could use a different default
> event_loop() function for win32 vs. unix.

Or we could put this in the poll function and reraise the error on 
NT, as my change does.
 
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 aahz at panix.com  Thu Oct  5 21:52:47 2000
From: aahz at panix.com (aahz at panix.com)
Date: Thu, 5 Oct 2000 12:52:47 -0700 (PDT)
Subject: [Python-Dev] forwarded message from aahz@panix.com
In-Reply-To: <200010051822.NAA14228@cj20424-a.reston1.va.home.com> from "Guido van Rossum" at Oct 05, 2000 01:22:49 PM
Message-ID: <200010051952.PAA05883@panix6.panix.com>

> [Aahz]
>> Someone just pointed out on c.l.py that we need an HTMLescape() function
>> that takes a string and converts special characters to entities.  I'm
>> not on python-dev, so could you please forward this and find out whether
>> I need to run a PEP?
> 
> Has someone pointed out yet that this is done by cgi.escape()?

Yeah, I missed that earlier.  But after thinking some more, there are a
fair number of browser-like bits of software that fail to render many of
the special characters correctly (e.g. trademark).  This is frequently
due to character set issues; entities almost always render correctly,
though.  Therefore a general translation routine is probably handy.

cgi.escape() only handles "&", "<", ">".  I'm not sure whether cgi.escape
ought to be expanded to handle all characters or a new routine should be
added.  Martin van Loewis suggested xml.sax.saxutils.escape(), but I
have zero familiarity with XML and am waiting for 2.0final.  Perhaps
this should be taken off-line?
-- 
                      --- Aahz (Copyright 2000 by aahz at pobox.com)

Androgynous poly kinky vanilla queer het    <*>     http://www.rahul.net/aahz/
Hugs and backrubs -- I break Rule 6

There's a difference between a person who gets shit zie doesn't
deserve and a person who gets more shit than zie deserves.  --Aahz



From skip at mojam.com  Thu Oct  5 21:54:56 2000
From: skip at mojam.com (Skip Montanaro)
Date: Thu, 5 Oct 2000 14:54:56 -0500 (CDT)
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src configure,1.157,1.158 configure.in,1.166,1.167
In-Reply-To: <200010051845.LAA16072@slayer.i.sourceforge.net>
References: <200010051845.LAA16072@slayer.i.sourceforge.net>
Message-ID: <14812.56464.380651.537610@beluga.mojam.com>

    Barry> Apparently, on SunOS 4.1.4_JL (and other?) OSes, -d on an empty
    Barry> string always returns true.  This closes SF bug #115392.

There was a big thread recently on the tramp mailing list (similar to efs
for remote file editing in Emacs, but uses ssh/scp instead) about trying to
find a portable way to test for the existence of a file.  After trying all
sorts of stuff, the final result was pretty ugly, as I recall.

-- 
Skip Montanaro (skip at mojam.com)
http://www.mojam.com/
http://www.musi-cal.com/



From guido at python.org  Thu Oct  5 23:07:29 2000
From: guido at python.org (Guido van Rossum)
Date: Thu, 05 Oct 2000 16:07:29 -0500
Subject: [Python-Dev] forwarded message from aahz@panix.com
In-Reply-To: Your message of "Thu, 05 Oct 2000 12:52:47 MST."
             <200010051952.PAA05883@panix6.panix.com> 
References: <200010051952.PAA05883@panix6.panix.com> 
Message-ID: <200010052107.QAA20988@cj20424-a.reston1.va.home.com>

> Yeah, I missed that earlier.  But after thinking some more, there are a
> fair number of browser-like bits of software that fail to render many of
> the special characters correctly (e.g. trademark).  This is frequently
> due to character set issues; entities almost always render correctly,
> though.  Therefore a general translation routine is probably handy.

But character set issues also make it impossible to provide such a
translation routine: the current party line is that the encoding of
8-bit strings is unknown and that only ASCII can be assumed.

> cgi.escape() only handles "&", "<", ">".  I'm not sure whether cgi.escape
> ought to be expanded to handle all characters or a new routine should be
> added.  Martin van Loewis suggested xml.sax.saxutils.escape(), but I
> have zero familiarity with XML and am waiting for 2.0final.  Perhaps
> this should be taken off-line?

xml.sax.saxutils.escape() is a generalization of cgi.escape() -- read
the source (Lib/xml/sax/saxutils.py).  It allows you to specify
additional things to be replaced by entities by passing in a
dictionary mapping chars (or strings) to entities.

If you know that you are dealing with Latin-1, you could use the table
in htmlentitydefs.py to construct a table.

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



From jeremy at beopen.com  Thu Oct  5 22:13:34 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Thu, 5 Oct 2000 16:13:34 -0400 (EDT)
Subject: [Python-Dev] forwarded message from aahz@panix.com
In-Reply-To: <200010051952.PAA05883@panix6.panix.com>
References: <200010051822.NAA14228@cj20424-a.reston1.va.home.com>
	<200010051952.PAA05883@panix6.panix.com>
Message-ID: <14812.57582.25916.131290@bitdiddle.concentric.net>

>>>>> "AM" == aahz  <aahz at panix.com> writes:

  >> [Aahz]
  >>> Someone just pointed out on c.l.py that we need an HTMLescape()
  >>> function that takes a string and converts special characters to
  >>> entities.  I'm not on python-dev, so could you please forward
  >>> this and find out whether I need to run a PEP?
  >>
  >> Has someone pointed out yet that this is done by cgi.escape()?

  AM> Yeah, I missed that earlier.  But after thinking some more,
  AM> there are a fair number of browser-like bits of software that
  AM> fail to render many of the special characters correctly
  AM> (e.g. trademark).  This is frequently due to character set
  AM> issues; entities almost always render correctly, though.
  AM> Therefore a general translation routine is probably handy.

  AM> cgi.escape() only handles "&", "<", ">".  I'm not sure whether
  AM> cgi.escape ought to be expanded to handle all characters or a
  AM> new routine should be added.  Martin van Loewis suggested
  AM> xml.sax.saxutils.escape(), but I have zero familiarity with XML
  AM> and am waiting for 2.0final.  Perhaps this should be taken
  AM> off-line?

Perhaps we should take it to python-list -- or maybe we should form a
web-sig and work on it there.

There are definitely some tricky issues to work out.  I attempted to
work out some of the same issues for internationalization support in
Mailman's pipermail archives.

The escape function in cgi should stay minimal, because it deals with
the only truly essential characters.  If the browser interprets an
HTML page as iso-8859-1 ("Latin 1") then characters > chr(127) are
going to be rendered properly.  You can add an explicit meta tag to
the HTML page and the server will return the charset in the headers.

This seems quite a bit simpler than trying to escape all characters >
chr(127), except if you have to deal with old browsers that don't
support the charset specified by the HTTP header.

Jeremy



From thomas at xs4all.net  Thu Oct  5 23:40:22 2000
From: thomas at xs4all.net (Thomas Wouters)
Date: Thu, 5 Oct 2000 23:40:22 +0200
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src configure,1.157,1.158 configure.in,1.166,1.167
In-Reply-To: <200010051845.LAA16072@slayer.i.sourceforge.net>; from bwarsaw@users.sourceforge.net on Thu, Oct 05, 2000 at 11:45:55AM -0700
References: <200010051845.LAA16072@slayer.i.sourceforge.net>
Message-ID: <20001005234022.I12812@xs4all.nl>

On Thu, Oct 05, 2000 at 11:45:55AM -0700, Barry Warsaw wrote:
> Update of /cvsroot/python/python/dist/src
> In directory slayer.i.sourceforge.net:/tmp/cvs-serv14007

> Modified Files:
> 	configure configure.in 
> Log Message:
> Change all occurances of
> 
> 	test -d "$directory"
> to
> 	test ! -z "directory" -a -d "directory"

> Apparently, on SunOS 4.1.4_JL (and other?) OSes, -d on an empty string
> always returns true.  This closes SF bug #115392.

> --- 3103,3110 ----
>       USE_THREAD_MODULE="#"
>   else
> !     if test ! -z $with_threads -a -d $with_threads
>       then LDFLAGS="$LDFLAGS -L$with_threads"
>       fi
> !     if test ! -z $withval -a -d $withval
>       then LDFLAGS="$LDFLAGS -L$withval"
>       fi

Is this really going to work ? I always see 'portable' shell code do
something like

if [ "X${spam}" != "X" ] ...

instead of 'test -z', eventhough even BSDI test has -z. (The portable code
I'm talking about are mostly BSDI /etc/rc* scripts... BSDI's /bin/sh is
minimal, compared to modern day equivalents.) My /bin/sh-knowledge is
decidedly less impressive than my Python knowledge, but I thought something
like 

if test ! -z $withval -a -d $withval

where $withval is empty, would be parsed as

if test ! -z -a -d

which would be, uhm, wrong ? But like I said, I don't really know what I'm
talking about here, there could be another perfectly valid reason for BSDI
to use the roundabout way, instead of using -z.

-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!



From jeremy at beopen.com  Fri Oct  6 00:12:09 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Thu, 5 Oct 2000 18:12:09 -0400 (EDT)
Subject: [Python-Dev] Proposal -- makefile patches and scripts to generate python RPMs
In-Reply-To: <200010051833.NAA14356@cj20424-a.reston1.va.home.com>
References: <200010050744.JAA00782@loewis.home.cs.tu-berlin.de>
	<200010051833.NAA14356@cj20424-a.reston1.va.home.com>
Message-ID: <14812.64697.601359.920302@bitdiddle.concentric.net>

>>>>> "GvR" == Guido van Rossum <guido at python.org> writes:

  GvR> Whatever the outcome of this discussion, this is too late for
  GvR> 2.0.  But I tend to side with Jeremy and Martin -- "explicit is
  GvR> better".  I do want Jeremy to check his RPM generation scripts
  GvR> in, so they can be improved in a truly open source project.
  GvR> (Maybe in Tools/rpm?)

I don't actually use a script to generate the RPM.  I wrote a .spec
file by hand and use it to generate the RPMs using the rpm command.
I could check in the spec file, which I would end up changing every
time we do a release -- to update the version number, change the
Setup.in patch, etc.  I should probably also include the patch file
along with the .spec file.

I also wrote a smal distutils setup script for 2.0b2, which I should
check in somewhere.  Not sure where...

BTW, I've attached the spec file below.  You can get it from the
.src.rpm on pythonlabs.com, but that's pretty inconvenient if you're
merely curious.

Jeremy

%define name BeOpen-Python
%define version 2.0b2
%define release 1
%define __prefix /usr/local

Summary: An interpreted, interactive, object-oriented programming language.
Name: %{name}
Version: %{version}
Release: %{release}
Copyright: Modified CNRI Open Source License
Group: Development/Languages
Source: %{name}-%{version}.tar.bz2
Source1: html-%{version}.tar.bz2
Patch0: %{name}-%{version}-Setup.patch
BuildRoot: /var/tmp/%{name}-%{version}-root
Prefix: %{__prefix}
URL: http://www.pythonlabs.com/
Vendor: BeOpen PythonLabs
Packager: Jeremy Hylton <jeremy at beopen.com>

%description
Python is an interpreted, interactive, object-oriented programming
language.  It incorporates modules, exceptions, dynamic typing, very high
level dynamic data types, and classes. Python combines remarkable power
with very clear syntax. It has interfaces to many system calls and
libraries, as well as to various window systems, and is extensible in C or
C++. It is also usable as an extension language for applications that need
a programmable interface.  Finally, Python is portable: it runs on many
brands of UNIX, on PCs under Windows, MS-DOS, and OS/2, and on the
Mac.

%changelog
* Thu Oct  5 2000 Jeremy Hylton <jeremy at beopen.com>
- added bin/python2.0 to files list (suggested by Martin v. L?wis)

* Tue Sep 26 2000 Jeremy Hylton <jeremy at beopen.com>
- updated for release 1 of 2.0b2
- use .bz2 version of Python source

* Tue Sep 12 2000 Jeremy Hylton <jeremy at beopen.com>
- Version 2 of 2.0b1
- Make the package relocatable.  Thanks to Suchandra Thapa.
- Exclude Tkinter from main RPM.  If it is in a separate RPM, it is
  easier to track Tk releases.

%prep
%setup -n Python-%{version}
%patch0 
%setup -D -T -a 1 -n Python-%{version}
# This command drops the HTML files in the top-level build directory.
# That's not perfect, but it will do for now.

%build
./configure
make

%install
[ -d $RPM_BUILD_ROOT ] && rm -fr $RPM_BUILD_ROOT
mkdir -p $RPM_BUILD_ROOT%{__prefix}
make prefix=$RPM_BUILD_ROOT%{__prefix} install

%clean
rm -fr $RPM_BUILD_ROOT

%files
%defattr(-, root, root)
%{__prefix}/bin/python
%{__prefix}/bin/python2.0
%{__prefix}/man/man1/python.1
%doc Misc/README Misc/HYPE Misc/cheatsheet Misc/unicode.txt Misc/Porting
%doc LICENSE Misc/ACKS Misc/BLURB.* Misc/HISTORY Misc/NEWS
%doc index.html modindex.html api dist doc ext inst lib mac ref tut icons

%dir %{__prefix}/include/python2.0
%{__prefix}/include/python2.0/*.h
%dir %{__prefix}/lib/python2.0/
%{__prefix}/lib/python2.0/*.py*
%{__prefix}/lib/python2.0/pdb.doc
%{__prefix}/lib/python2.0/profile.doc
%dir %{__prefix}/lib/python2.0/config
%{__prefix}/lib/python2.0/config/Makefile
%{__prefix}/lib/python2.0/config/Makefile.pre.in
%{__prefix}/lib/python2.0/config/Setup
%{__prefix}/lib/python2.0/config/Setup.config
%{__prefix}/lib/python2.0/config/Setup.local
%{__prefix}/lib/python2.0/config/config.c
%{__prefix}/lib/python2.0/config/config.c.in
%{__prefix}/lib/python2.0/config/install-sh
%{__prefix}/lib/python2.0/config/libpython2.0.a
%{__prefix}/lib/python2.0/config/makesetup
%{__prefix}/lib/python2.0/config/python.o
%dir %{__prefix}/lib/python2.0/curses
%{__prefix}/lib/python2.0/curses/*.py*
%dir %{__prefix}/lib/python2.0/distutils
%{__prefix}/lib/python2.0/distutils/*.py*
%{__prefix}/lib/python2.0/distutils/README
%dir %{__prefix}/lib/python2.0/distutils/command
%{__prefix}/lib/python2.0/distutils/command/*.py*
%{__prefix}/lib/python2.0/distutils/command/command_template
%dir %{__prefix}/lib/python2.0/encodings
%{__prefix}/lib/python2.0/encodings/*.py*
%dir %{__prefix}/lib/python2.0/lib-dynload
%dir %{__prefix}/lib/python2.0/lib-tk
%{__prefix}/lib/python2.0/lib-tk/*.py*
%{__prefix}/lib/python2.0/lib-dynload/_codecsmodule.so
%{__prefix}/lib/python2.0/lib-dynload/_cursesmodule.so
%{__prefix}/lib/python2.0/lib-dynload/_localemodule.so
%{__prefix}/lib/python2.0/lib-dynload/arraymodule.so
%{__prefix}/lib/python2.0/lib-dynload/binascii.so
%{__prefix}/lib/python2.0/lib-dynload/cPickle.so
%{__prefix}/lib/python2.0/lib-dynload/cStringIO.so
%{__prefix}/lib/python2.0/lib-dynload/cmathmodule.so
%{__prefix}/lib/python2.0/lib-dynload/errnomodule.so
%{__prefix}/lib/python2.0/lib-dynload/fcntlmodule.so
%{__prefix}/lib/python2.0/lib-dynload/gdbmmodule.so
%{__prefix}/lib/python2.0/lib-dynload/grpmodule.so
%{__prefix}/lib/python2.0/lib-dynload/linuxaudiodev.so
%{__prefix}/lib/python2.0/lib-dynload/mathmodule.so
%{__prefix}/lib/python2.0/lib-dynload/md5module.so
%{__prefix}/lib/python2.0/lib-dynload/mmapmodule.so
%{__prefix}/lib/python2.0/lib-dynload/newmodule.so
%{__prefix}/lib/python2.0/lib-dynload/operator.so
%{__prefix}/lib/python2.0/lib-dynload/parsermodule.so
%{__prefix}/lib/python2.0/lib-dynload/pwdmodule.so
%{__prefix}/lib/python2.0/lib-dynload/pyexpat.so
%{__prefix}/lib/python2.0/lib-dynload/readline.so
%{__prefix}/lib/python2.0/lib-dynload/resource.so
%{__prefix}/lib/python2.0/lib-dynload/rotormodule.so
%{__prefix}/lib/python2.0/lib-dynload/selectmodule.so
%{__prefix}/lib/python2.0/lib-dynload/shamodule.so
%{__prefix}/lib/python2.0/lib-dynload/_socketmodule.so
%{__prefix}/lib/python2.0/lib-dynload/stropmodule.so
%{__prefix}/lib/python2.0/lib-dynload/structmodule.so
%{__prefix}/lib/python2.0/lib-dynload/syslogmodule.so
%{__prefix}/lib/python2.0/lib-dynload/termios.so
%{__prefix}/lib/python2.0/lib-dynload/timemodule.so
%{__prefix}/lib/python2.0/lib-dynload/ucnhash.so
%{__prefix}/lib/python2.0/lib-dynload/unicodedata.so
%{__prefix}/lib/python2.0/lib-dynload/zlibmodule.so
%dir %{__prefix}/lib/python2.0/lib-old
%{__prefix}/lib/python2.0/lib-old/*.py*
%dir %{__prefix}/lib/python2.0/plat-linux2
%{__prefix}/lib/python2.0/plat-linux2/*.py*
%{__prefix}/lib/python2.0/plat-linux2/regen
%dir %{__prefix}/lib/python2.0/site-packages
%{__prefix}/lib/python2.0/site-packages/README
%dir %{__prefix}/lib/python2.0/test
%{__prefix}/lib/python2.0/test/*.py*
%{__prefix}/lib/python2.0/test/README
%{__prefix}/lib/python2.0/test/audiotest.au
%{__prefix}/lib/python2.0/test/greyrgb.uue
%{__prefix}/lib/python2.0/test/test.xml
%{__prefix}/lib/python2.0/test/testimg.uue
%{__prefix}/lib/python2.0/test/testimgr.uue
%{__prefix}/lib/python2.0/test/testrgb.uue
%dir %{__prefix}/lib/python2.0/test/output
%{__prefix}/lib/python2.0/test/output/test_*
%dir %{__prefix}/lib/python2.0/xml
%{__prefix}/lib/python2.0/xml/*.py*
%dir %{__prefix}/lib/python2.0/xml/dom
%{__prefix}/lib/python2.0/xml/dom/*.py*
%dir %{__prefix}/lib/python2.0/xml/sax
%{__prefix}/lib/python2.0/xml/sax/*.py*



From fdrake at beopen.com  Fri Oct  6 02:14:20 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Thu, 5 Oct 2000 20:14:20 -0400 (EDT)
Subject: [Python-Dev] forwarded message from Gerald Pfeifer
Message-ID: <14813.6492.879919.445014@cj42289-a.reston1.va.home.com>


  I just got this message from the gcc-announce list.  We've seen bug
reports related to GCC 2.96 (which may or may not be the problem).  We
need to be aware that these releases are out there and can be a
problem.
  I've noticed that the version of GCC shipped with Mandrake 7.1 is
"gcc version 2.95.3 19991030 (prerelease)", which doesn't give my much
confidence either.  ;(


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member

-------------- next part --------------
An embedded message was scrubbed...
From: Gerald Pfeifer <pfeifer at dbai.tuwien.ac.at>
Subject: GCC 2.96
Date: Fri, 6 Oct 2000 01:58:11 +0200 (CEST)
Size: 3308
URL: <http://mail.python.org/pipermail/python-dev/attachments/20001005/53f9aeda/attachment.eml>

From thomas at xs4all.net  Fri Oct  6 02:29:11 2000
From: thomas at xs4all.net (Thomas Wouters)
Date: Fri, 6 Oct 2000 02:29:11 +0200
Subject: [Python-Dev] forwarded message from Gerald Pfeifer
In-Reply-To: <14813.6492.879919.445014@cj42289-a.reston1.va.home.com>; from fdrake@beopen.com on Thu, Oct 05, 2000 at 08:14:20PM -0400
References: <14813.6492.879919.445014@cj42289-a.reston1.va.home.com>
Message-ID: <20001006022910.J12812@xs4all.nl>

On Thu, Oct 05, 2000 at 08:14:20PM -0400, Fred L. Drake, Jr. wrote:

>   I just got this message from the gcc-announce list.  We've seen bug
> reports related to GCC 2.96 (which may or may not be the problem).  We
> need to be aware that these releases are out there and can be a
> problem.
>   I've noticed that the version of GCC shipped with Mandrake 7.1 is
> "gcc version 2.95.3 19991030 (prerelease)", which doesn't give my much
> confidence either.  ;(

The 'unstable' branch of Debian currently ships with:
gcc version 2.95.2 20000220 (Debian GNU/Linux)

and it seems to be working fine. I did notice a problem, but it was related
to glibc 2.1.94, not gcc: LONG_BIT was wrongly defined to 64. Tim's
sanity-check, which checks LONG_BIT against (SIZEOF_LONG * 8), would have
caught that one, but I found it on my machine before he checked in that fix
;) For me, that problem was caused by the /usr/include/bits/xopen_lim.h
include file:

/* Number of bits in a word of type ong int'.  */
#if LONG_MAX == 2147483647
# define LONG_BIT       32
#else
/* Safe assumption.  */
# define LONG_BIT       64
#endif

where LONG_MAX was not defined (yet). I fixed it 'manually' for more than
just Python by adding

#ifndef LONG_MAX
#define LONG_MAX 2147483647
#endif

above it. I had to laugh, though, when I saw that assuming longs had 64 bits
is considered 'a safe assumption'. I guess most people use 64 bit machines
nowadays ? :-) 

I'm not complaining about this, though. Woody (Debian's current unstable
tree) is bleeding edge, and I'm fully prepared to live with it. In fact, I
love it! But people testing out glibc 2.1.90+ should keep this in mind. I'm
also wondering where to send my bugreport, but I think I'll read some
documentation before I do that, first ;)

-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!



From fdrake at beopen.com  Fri Oct  6 03:37:40 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Thu, 5 Oct 2000 21:37:40 -0400 (EDT)
Subject: [Python-Dev] forwarded message from Gerald Pfeifer
In-Reply-To: <20001006022910.J12812@xs4all.nl>
References: <14813.6492.879919.445014@cj42289-a.reston1.va.home.com>
	<20001006022910.J12812@xs4all.nl>
Message-ID: <14813.11492.123197.791450@cj42289-a.reston1.va.home.com>

Thomas Wouters writes:
 > The 'unstable' branch of Debian currently ships with:
 > gcc version 2.95.2 20000220 (Debian GNU/Linux)
 > 
 > and it seems to be working fine. I did notice a problem, but it was related

  I understand this to be the latest "stable" version of GCC, and it
appearantly it has been accepted as such for a while now.

 > above it. I had to laugh, though, when I saw that assuming longs had 64 bits
 > is considered 'a safe assumption'. I guess most people use 64 bit machines
 > nowadays ? :-) 

  Hey, my machine is 4294967296 bits!  Forget those ancient 64 bit
machines!  ;-)

 > I'm not complaining about this, though. Woody (Debian's current unstable
 > tree) is bleeding edge, and I'm fully prepared to live with it. In fact, I
 > love it! But people testing out glibc 2.1.90+ should keep this in mind. I'm

  I'm less concerned about people who know they're deliberatly putting
themselves on the bleeding edge than the people that pick up the
latest version of some Linux distribution and find they have a buggy
compiler because the distribution builders weren't as careful as
perhaps they should have been.  Putting together a professional grade
Linux distro is still a very hard thing.
  There's no such thing as enough testing here!


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From MarkH at ActiveState.com  Fri Oct  6 05:52:13 2000
From: MarkH at ActiveState.com (Mark Hammond)
Date: Fri, 6 Oct 2000 14:52:13 +1100
Subject: [Python-Dev] RE: buffer overlow in PC/getpathp.c
In-Reply-To: <ECEPKNMJLHAPFFJHDOJBEEGADLAA.MarkH@ActiveState.com>
Message-ID: <ECEPKNMJLHAPFFJHDOJBIEHDDMAA.MarkH@ActiveState.com>

[Me, responding to Jeremy's request I look for potential buffer exploits on
Windows...]

> I will be happy to look into this.

And was :-)

If anyone has time over the next day or 2, any holes I either missed, or
added(!) in
http://sourceforge.net/patch/?func=detailpatch&patch_id=101801&group_id=547
0 would be appreciated!

Thanks,

Mark.




From thomas.heller at ion-tof.com  Fri Oct  6 09:20:56 2000
From: thomas.heller at ion-tof.com (Thomas Heller)
Date: Fri, 6 Oct 2000 09:20:56 +0200
Subject: [Python-Dev] Proposal -- makefile patches and scripts to generate python RPMs
References: <200010050744.JAA00782@loewis.home.cs.tu-berlin.de><200010051833.NAA14356@cj20424-a.reston1.va.home.com> <14812.64697.601359.920302@bitdiddle.concentric.net>
Message-ID: <003d01c02f65$fb409550$4500a8c0@thomasnotebook>

> I don't actually use a script to generate the RPM.  I wrote a .spec
> file by hand and use it to generate the RPMs using the rpm command.
> I could check in the spec file, which I would end up changing every
> time we do a release -- to update the version number, change the
> Setup.in patch, etc.  I should probably also include the patch file
> along with the .spec file.
> 
> I also wrote a smal distutils setup script for 2.0b2, which I should
> check in somewhere.  Not sure where...
> 
Could you post this script?

Thomas




From loewis at informatik.hu-berlin.de  Thu Oct  5 21:49:26 2000
From: loewis at informatik.hu-berlin.de (Martin von Loewis)
Date: Thu, 5 Oct 2000 21:49:26 +0200 (MET DST)
Subject: [Python-Dev] PEP 4: Deprecation of standard modules
Message-ID: <200010051949.VAA04764@pandora.informatik.hu-berlin.de>

I just finished a first draft of a PEP on deprecating (and eventually
removing) modules from the standard Python library; it is available
from

http://python.sourceforge.net/peps/pep-0004.html

If you have comments or suggestions on the proposed procedures, or the
wording of the text, please send me a message. According to the PEP
procedures (PEP 1), this is the preferred way of progressing this PEP
(rather than discussing it on these lists), at least initially.

Regards,
Martin




From loewis at informatik.hu-berlin.de  Fri Oct  6 14:39:05 2000
From: loewis at informatik.hu-berlin.de (Martin von Loewis)
Date: Fri, 6 Oct 2000 14:39:05 +0200 (MET DST)
Subject: [Python-Dev] htmllib.HTMLescape()
Message-ID: <200010061239.OAA13090@pandora.informatik.hu-berlin.de>

> The difficulty, I assume, lies in figuring out which encodings
> support what characters.

It's not that difficult to write a set of new codecs; with the module
below, I can do

>>> import xmlenc
>>> u'\u0416'.encode('latin-1-xml')
'&#x416;'
>>> unicode('X&#x245;Y','latin-1-xml')
u'X\u0245Y'

The difficulty is that the algorithm is not very efficient if there
are many unsupported characters in a string.

Regards,
Martin

# Module implementing a set of new encodings of the form <enc>-xml
# Copyright Martin v. L&ouml;wis
# It currently supports hex character references only

import codecs

class CodecWrapper:
    def __init__(self,encoder,decoder):
        self.encoder = encoder
        self.decoder = decoder

    def encode(self,input,errors='strict'):
        try:
            return self.encoder(input,"strict")
        except ValueError:
            l = len(input)
            if l==1:
                return "&#x%x;" % ord(input), 1
            s1,l1 = self.encode(input[:l/2])
            s2,l2 = self.encode(input[l/2:])
            return s1+s2,l1+l2

    def decode(self,input,errors='strict'):
        input = str(input) # might be buffer object
        pos = input.find("&#x")
        if pos == -1:
            return self.decoder(input,errors)
        r1,l1 = self.decode(input[:pos],errors)
        end = input.find(";",pos)
        try:
            if end==-1:
                raise ValueError # goto failure code below
            val = int(input[pos+3:end],16)
            r2,l2 = self.decode(input[end+1:],errors)
            return r1+unichr(val)+r2,l1+end-pos+l2
        except ValueError:
            # how to deal with errors in decode?
            r2,l2 = self.decode(input[pos+2:],errors)
            return r1+"&#x"+r2,l1+3+l2

    def mkreader(self):
        r = codecs.StreamReader()
        r.decode = self.decode
        r.encode = self.encode
        return r

    def mkwriter(self):
        r = codecs.StreamWriter()
        r.decode = self.decode
        r.encode = self.encode
        return r

def search_function(encoding):
    if not encoding.endswith("-xml"):
        return None
    enc,dec,reader,writer = codecs.lookup(encoding[:-4])
    c = CodecWrapper(enc,dec)
    return c.encode,c.decode,c.mkreader,c.mkwriter

codecs.register(search_function)



From jeremy at beopen.com  Fri Oct  6 16:54:03 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Fri, 6 Oct 2000 10:54:03 -0400 (EDT)
Subject: [Python-Dev] Proposal -- makefile patches and scripts to generate python RPMs
In-Reply-To: <003d01c02f65$fb409550$4500a8c0@thomasnotebook>
References: <200010050744.JAA00782@loewis.home.cs.tu-berlin.de>
	<200010051833.NAA14356@cj20424-a.reston1.va.home.com>
	<14812.64697.601359.920302@bitdiddle.concentric.net>
	<003d01c02f65$fb409550$4500a8c0@thomasnotebook>
Message-ID: <14813.59275.350667.580400@bitdiddle.concentric.net>

Here is the setup script I used to build the Tk RPMs.  The name and
version part is a mess and I would welcome suggestions on how to fix
it.  The problem is that Tkinter gets built against a particular
version of Python and a particular version of Tcl/Tk.  I want the name
of the RPM to indiciate both versions, but didn't seem an obvious way
to accomplish it.  Thus, I put the Python version number in the name
and the Tcl/Tk version number in the version.  Otherwise, I think this
is pretty straightforward distutils stuff (although the documentation
was out of date last I checked).

I've attached three files.  I wrote setup.py and setup.cfg.  Distutils
created MANIFEST.

Jeremy

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: setup.py
URL: <http://mail.python.org/pipermail/python-dev/attachments/20001006/f815d426/attachment.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: setup.cfg
URL: <http://mail.python.org/pipermail/python-dev/attachments/20001006/f815d426/attachment.asc>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: MANIFEST
URL: <http://mail.python.org/pipermail/python-dev/attachments/20001006/f815d426/attachment-0001.txt>

From jeremy at beopen.com  Fri Oct  6 21:11:43 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Fri, 6 Oct 2000 15:11:43 -0400 (EDT)
Subject: [Python-Dev] linuxaudiodev module
Message-ID: <14814.9199.422989.273484@bitdiddle.concentric.net>

I just fixed a number of major bugs in the undocumented linuxaudiodev
module.  I ended up spending about an hour reading the excellent Open
Sound System (OSS) Programmer's Guide to figure out what the module
was trying to do and why it wasn't working on my Linux box.

After reading the module and the OSS guide, it is clear to me that we
need a complete re-write.  The module itself is just a wrapper around
a bunch of read, write, and ioctl calls.  It could all be implemented
in pure Python.

I propose we develop a Python module for Python 2.1 and call it
osslib.  There is nothing at all that is Linux-specific about the
interface being used.  The OSS guide mentions a plethora of platforms
that it supports.

In the interim, I have fixed some of the most egregious problems.  I
would appreciate it if Linux users could try out the fixes and the new
test case.  On my machine it still sounds awful, but at least the
sound can be heard.

Jeremy



From akuchlin at mems-exchange.org  Fri Oct  6 21:17:39 2000
From: akuchlin at mems-exchange.org (Andrew Kuchling)
Date: Fri, 6 Oct 2000 15:17:39 -0400
Subject: [Python-Dev] linuxaudiodev module
In-Reply-To: <14814.9199.422989.273484@bitdiddle.concentric.net>; from jeremy@beopen.com on Fri, Oct 06, 2000 at 03:11:43PM -0400
References: <14814.9199.422989.273484@bitdiddle.concentric.net>
Message-ID: <20001006151739.A31189@kronos.cnri.reston.va.us>

On Fri, Oct 06, 2000 at 03:11:43PM -0400, Jeremy Hylton wrote:
>After reading the module and the OSS guide, it is clear to me that we
>need a complete re-write.  The module itself is just a wrapper around
>a bunch of read, write, and ioctl calls.  It could all be implemented
>in pure Python.

So, is there any point in releasing linuxaudiodev at all, then, if it
needs a complete rewrite?

--amk




From DavidA at ActiveState.com  Fri Oct  6 21:39:21 2000
From: DavidA at ActiveState.com (David Ascher)
Date: Fri, 6 Oct 2000 12:39:21 -0700 (Pacific Daylight Time)
Subject: [Python-Dev] linuxaudiodev module
In-Reply-To: <14814.9199.422989.273484@bitdiddle.concentric.net>
Message-ID: <Pine.WNT.4.21.0010061238130.844-100000@loom>

> I propose we develop a Python module for Python 2.1 and call it
> osslib.  There is nothing at all that is Linux-specific about the
> interface being used.  The OSS guide mentions a plethora of platforms
> that it supports.

Have you evaluated http://net.indra.com/~tim/ossmodule/

?






From jeremy at beopen.com  Fri Oct  6 21:47:27 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Fri, 6 Oct 2000 15:47:27 -0400 (EDT)
Subject: [Python-Dev] linuxaudiodev module
In-Reply-To: <20001006151739.A31189@kronos.cnri.reston.va.us>
References: <14814.9199.422989.273484@bitdiddle.concentric.net>
	<20001006151739.A31189@kronos.cnri.reston.va.us>
Message-ID: <14814.11343.988335.520786@bitdiddle.concentric.net>

>>>>> "AMK" == Andrew Kuchling <akuchlin at mems-exchange.org> writes:

  AMK> On Fri, Oct 06, 2000 at 03:11:43PM -0400, Jeremy Hylton wrote:
  >> After reading the module and the OSS guide, it is clear to me
  >> that we need a complete re-write.  The module itself is just a
  >> wrapper around a bunch of read, write, and ioctl calls.  It could
  >> all be implemented in pure Python.

  AMK> So, is there any point in releasing linuxaudiodev at all, then,
  AMK> if it needs a complete rewrite?

I would be include to chuck it, except that it also shipped with 1.6.
I would hestitate to deprecate it so far into the release process.

jeremy



From jeremy at beopen.com  Fri Oct  6 21:47:48 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Fri, 6 Oct 2000 15:47:48 -0400 (EDT)
Subject: [Python-Dev] linuxaudiodev module
In-Reply-To: <Pine.WNT.4.21.0010061238130.844-100000@loom>
References: <14814.9199.422989.273484@bitdiddle.concentric.net>
	<Pine.WNT.4.21.0010061238130.844-100000@loom>
Message-ID: <14814.11364.360443.940965@bitdiddle.concentric.net>

I had no idea it existed.

Jeremy



From jeremy at beopen.com  Fri Oct  6 21:54:35 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Fri, 6 Oct 2000 15:54:35 -0400 (EDT)
Subject: [Python-Dev] linuxaudiodev module
In-Reply-To: <Pine.WNT.4.21.0010061238130.844-100000@loom>
References: <14814.9199.422989.273484@bitdiddle.concentric.net>
	<Pine.WNT.4.21.0010061238130.844-100000@loom>
Message-ID: <14814.11771.731237.214646@bitdiddle.concentric.net>

>>>>> "DA" == David Ascher <DavidA at ActiveState.com> writes:

  DA> Have you evaluated http://net.indra.com/~tim/ossmodule/

Okay.  I took a quick look.  It's really old (July 1997).  It looks
like a more reasonable wrapping than linuxaudiodev, although I would
want to review it more carefully against the OSS programmer's guide.

I would prefer a pure Python solution, because the code would be
shorter and easier to read and maintain.  It may be, however, that the
ossmodule is still up-to-date; if so, it may be easier to use it than
to rewrite it.

Jeremy




From ping at lfw.org  Fri Oct  6 23:13:39 2000
From: ping at lfw.org (Ka-Ping Yee)
Date: Fri, 6 Oct 2000 16:13:39 -0500 (CDT)
Subject: [Python-Dev] linuxaudiodev module
In-Reply-To: <14814.9199.422989.273484@bitdiddle.concentric.net>
Message-ID: <Pine.LNX.4.10.10010061609370.9837-100000@server1.lfw.org>

On Fri, 6 Oct 2000, Jeremy Hylton wrote:
> After reading the module and the OSS guide, it is clear to me that we
> need a complete re-write.  The module itself is just a wrapper around
> a bunch of read, write, and ioctl calls.  It could all be implemented
> in pure Python.

True.  I think your osslib is a good idea.  I wanted to take on this
sort of project myself a few weeks ago but never had the time to really
get started.  From playing with the test script, i think all we care
about having in C is audioop (and that's just for ulaw conversion).
I would like to fix audioop so we can expect it to be present as a
standard module; then we can have a module written in Python that
provides uniform sound support for all platforms.

> On my machine it still sounds awful, but at least the
> sound can be heard.

It should not sound awful.  If it sounds too loud and scratchy, then
maybe you need to use audioop to convert from Sun .au (ulaw) to raw
samples first.  This was the case with the Spanish inquisition clip.


-- ?!ng




From jeremy at beopen.com  Sat Oct  7 00:28:57 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Fri, 6 Oct 2000 18:28:57 -0400 (EDT)
Subject: [Python-Dev] linuxaudiodev module
In-Reply-To: <Pine.LNX.4.10.10010061609370.9837-100000@server1.lfw.org>
References: <14814.9199.422989.273484@bitdiddle.concentric.net>
	<Pine.LNX.4.10.10010061609370.9837-100000@server1.lfw.org>
Message-ID: <14814.21033.195290.728159@bitdiddle.concentric.net>

>>>>> "KPY" == Ka-Ping Yee <ping at lfw.org> writes:

  >> On my machine it still sounds awful, but at least the sound can
  >> be heard.

  KPY> It should not sound awful.  If it sounds too loud and scratchy,
  KPY> then maybe you need to use audioop to convert from Sun .au
  KPY> (ulaw) to raw samples first.  This was the case with the
  KPY> Spanish inquisition clip.

I don't think I know how to do that.  I tried using sox to convert
audiotest.au to audiotest.raw and it sounded just as bad on my
machine.  Perhaps I have my machine configured incorrectly, although
CDs and Real Audio sound fine.

Have you tried the new code, BTW?  Does the test work on your machine?

Jeremy



From tim_one at email.msn.com  Sat Oct  7 00:28:53 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Fri, 6 Oct 2000 18:28:53 -0400
Subject: [Python-Dev] test_StringIO broken
Message-ID: <LNBBLJKPBEHFEDALKOLCCEAMHKAA.tim_one@email.msn.com>

test test_StringIO failed -- Writing: "'abcde'", expected: 'abcdefg'
1 test failed: test_StringIO

This on Win98SE, broke sometime late this afternoon (EDT).  Working
elsewhere?





From jeremy at beopen.com  Sat Oct  7 00:59:41 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Fri, 6 Oct 2000 18:59:41 -0400 (EDT)
Subject: [Python-Dev] test_StringIO broken
In-Reply-To: <LNBBLJKPBEHFEDALKOLCCEAMHKAA.tim_one@email.msn.com>
References: <LNBBLJKPBEHFEDALKOLCCEAMHKAA.tim_one@email.msn.com>
Message-ID: <14814.22877.882280.651958@bitdiddle.concentric.net>

The test was changed in a number of ways, but whoever checked it in
didn't actually run the regression test!

Also, the last messsage I see printed is:
Failed to catch ValueError writing to closed StringIO.

This ain't a case of forgetting to generate new output.  This is just
plain wrong.

Jeremy



From thomas at xs4all.net  Sat Oct  7 00:56:08 2000
From: thomas at xs4all.net (Thomas Wouters)
Date: Sat, 7 Oct 2000 00:56:08 +0200
Subject: [Python-Dev] test_StringIO broken
In-Reply-To: <LNBBLJKPBEHFEDALKOLCCEAMHKAA.tim_one@email.msn.com>; from tim_one@email.msn.com on Fri, Oct 06, 2000 at 06:28:53PM -0400
References: <LNBBLJKPBEHFEDALKOLCCEAMHKAA.tim_one@email.msn.com>
Message-ID: <20001007005608.K12812@xs4all.nl>

On Fri, Oct 06, 2000 at 06:28:53PM -0400, Tim Peters wrote:
> test test_StringIO failed -- Writing: "'abcde'", expected: 'abcdefg'
> 1 test failed: test_StringIO

> This on Win98SE, broke sometime late this afternoon (EDT).  Working
> elsewhere?

No. Fails the same way on my Linux box. And the problem is probably that the
test was updated (two tests were uncommented) but the output file wasn't
updated. Jim Fulton did the checkin, so he looks like the right person to
fix it (and manually check that the generated output file is *correct*, of
course ! ;)

-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!



From DavidA at ActiveState.com  Sat Oct  7 01:01:37 2000
From: DavidA at ActiveState.com (David Ascher)
Date: Fri, 6 Oct 2000 16:01:37 -0700 (Pacific Daylight Time)
Subject: [Python-Dev] linuxaudiodev module
In-Reply-To: <14814.11771.731237.214646@bitdiddle.concentric.net>
Message-ID: <Pine.WNT.4.21.0010061600590.844-100000@loom>

> Okay.  I took a quick look.  It's really old (July 1997).  It looks
> like a more reasonable wrapping than linuxaudiodev, although I would
> want to review it more carefully against the OSS programmer's guide.
> 
> I would prefer a pure Python solution, because the code would be
> shorter and easier to read and maintain.  It may be, however, that the
> ossmodule is still up-to-date; if so, it may be easier to use it than
> to rewrite it.

Absolutely.  I just remember some announcement about it.  I suspect that
what I remember is not that old, so it may make sense to do a little more
digging than I did in the archives...

--david




From thomas at xs4all.net  Sat Oct  7 00:58:19 2000
From: thomas at xs4all.net (Thomas Wouters)
Date: Sat, 7 Oct 2000 00:58:19 +0200
Subject: [Python-Dev] test_StringIO broken
In-Reply-To: <14814.22877.882280.651958@bitdiddle.concentric.net>; from jeremy@beopen.com on Fri, Oct 06, 2000 at 06:59:41PM -0400
References: <LNBBLJKPBEHFEDALKOLCCEAMHKAA.tim_one@email.msn.com> <14814.22877.882280.651958@bitdiddle.concentric.net>
Message-ID: <20001007005819.L12812@xs4all.nl>

On Fri, Oct 06, 2000 at 06:59:41PM -0400, Jeremy Hylton wrote:

> Also, the last messsage I see printed is:
> Failed to catch ValueError writing to closed StringIO.

> This ain't a case of forgetting to generate new output.  This is just
> plain wrong.

Hm, are you sure you re-built your modules before doing that ? The output
looks okay on my linux box, in any case. The last message is 'Caught
expected ValueError writing to closed StringIO: I/O operation on closed
file', for me. If you recompiled cStringIO, something odd is going on ;)

-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!



From jeremy at beopen.com  Sat Oct  7 01:06:32 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Fri, 6 Oct 2000 19:06:32 -0400 (EDT)
Subject: [Python-Dev] test_StringIO broken
In-Reply-To: <20001007005819.L12812@xs4all.nl>
References: <LNBBLJKPBEHFEDALKOLCCEAMHKAA.tim_one@email.msn.com>
	<14814.22877.882280.651958@bitdiddle.concentric.net>
	<20001007005819.L12812@xs4all.nl>
Message-ID: <14814.23288.490631.990498@bitdiddle.concentric.net>

>>>>> "TW" == Thomas Wouters <thomas at xs4all.net> writes:

  TW> On Fri, Oct 06, 2000 at 06:59:41PM -0400, Jeremy Hylton wrote:
  >> Also, the last messsage I see printed is: Failed to catch
  >> ValueError writing to closed StringIO.

  >> This ain't a case of forgetting to generate new output.  This is
  >> just plain wrong.

  TW> Hm, are you sure you re-built your modules before doing that ?

This is probably what went wrong for me.

Jeremy



From guido at python.org  Sat Oct  7 15:51:12 2000
From: guido at python.org (Guido van Rossum)
Date: Sat, 07 Oct 2000 08:51:12 -0500
Subject: [Python-Dev] Tcl and Unicode
In-Reply-To: Your message of "Fri, 06 Oct 2000 16:09:03 MST."
             <200010062309.QAA32052@slayer.i.sourceforge.net> 
References: <200010062309.QAA32052@slayer.i.sourceforge.net> 
Message-ID: <200010071351.IAA02962@cj20424-a.reston1.va.home.com>

> Fix for next iteration of SF bug 115690 (Unicode headaches in IDLE).  The
> parsing functions in support of auto-indent weren't expecting Unicode
> strings, but text.get() can now return them (although it remains muddy as
> to exactly when or why that can happen).  Fixed that with a Big Hammer.

I apologize, I should have explained when text.get() returns Unicode:

Any string returned from Tcl/Tk that contains a byte with the 8th bit
set is translated from UTF-8 into Unicode, unless the translation
fails (in which case the original raw 8-bit string is returned as a
fallback).

This *should* be correct because Tcl/Tk always uses UTF-8 internally.
(Even though it is "lenient" when receiving strings -- if a sequence
of characters has no valid Unicode representation, it appears to falls
back to Latin-1; I don't know the details of this algorithm.)

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



From tim_one at email.msn.com  Sat Oct  7 20:43:55 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Sat, 7 Oct 2000 14:43:55 -0400
Subject: [Python-Dev] Tcl and Unicode
In-Reply-To: <200010071351.IAA02962@cj20424-a.reston1.va.home.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCMECEHKAA.tim_one@email.msn.com>

>> Fix for next iteration of SF bug 115690 (Unicode headaches in
>> IDLE). ...

[Guido]
> I apologize, I should have explained when text.get() returns Unicode:
>
> Any string returned from Tcl/Tk that contains a byte with the 8th bit
> set is translated from UTF-8 into Unicode, unless the translation
> fails (in which case the original raw 8-bit string is returned as a
> fallback).

Except that's *why* it was muddy <wink>:  in the specific case that popped
up in the bug, text.get() appeared to return a Unicode string of length 1
containing only a newline.  No high-bit byte appeared to be involved.
However, that was an illusion I didn't unmask until later.  All is clear
now.

> This *should* be correct because Tcl/Tk always uses UTF-8 internally.
> (Even though it is "lenient" when receiving strings -- if a sequence
> of characters has no valid Unicode representation, it appears to falls
> back to Latin-1; I don't know the details of this algorithm.)

Dunno, but wouldn't be surprised if they had a notion of default encoding,
and that it simply appears to be Latin-1 to us because American Windows uses
a superset of Latin-1.  If BeOpen would like to buy me a version of Chinese
Windows, happy to lend it to you <wink>.

as-american-as-they-come-ly y'rs  - tim





From guido at python.org  Sun Oct  8 03:41:11 2000
From: guido at python.org (Guido van Rossum)
Date: Sat, 07 Oct 2000 20:41:11 -0500
Subject: [Python-Dev] linuxaudiodev module
In-Reply-To: Your message of "Fri, 06 Oct 2000 18:28:57 -0400."
             <14814.21033.195290.728159@bitdiddle.concentric.net> 
References: <14814.9199.422989.273484@bitdiddle.concentric.net> <Pine.LNX.4.10.10010061609370.9837-100000@server1.lfw.org>  
            <14814.21033.195290.728159@bitdiddle.concentric.net> 
Message-ID: <200010080141.UAA19858@cj20424-a.reston1.va.home.com>

I think I fixed the linuxaudio test -- see if it sounds reasonable
now!

The crux of the matter seemed to be that the last, optional argument
to setparameters(), meaning "emulate the format if the sound card
doesn't support it", is not supported right.  It suppresses the error
message, and the ioctl to set the format succeeds, but the emulation
doesn't work (at least not on my system, or on Jeremy's).

So I've used a subterfuge: assuming most sound cards support signed
16-bit native-endian format, I convert the data to that format, and
use the appropriate format code: AFMT_S16_LE for little-endian
machines, AFMT_S16_BE for big-endian machines.  I've only tested
little-endian.

I use the new sys.byteorder variable to determine the endianness.

I use the audioop module to do the conversion.  Much simpler than sox!
(Oh feeling of nostalgia...  I wrote several of the file format
handlers for sox, and fixed lots of bugs in it too...  I even started
the audio file formats FAQ, now maintained by Chris Bagwell, who also
took over sox...)

Downside: test_linuxaudiodev will now be skipped if you don't have the
audioop enabled in your Setup file.  But that's fixed easily.

By the way -- the checkin freeze for the release candidate should go
in just about now...

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



From tim_one at email.msn.com  Sun Oct  8 12:32:36 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Sun, 8 Oct 2000 06:32:36 -0400
Subject: [Python-Dev] A standard lexer?
In-Reply-To: <00f201bfe475$d5e00c40$f2a6b5d4@hagrid>
Message-ID: <LNBBLJKPBEHFEDALKOLCAEDGHKAA.tim_one@email.msn.com>

Blast from the past!

[/F]
>         for phrase, action in lexicon:
>             p.append("(?:%s)(?P#%d)" % (phrase, len(p)))

[Tim]
> How about instead enhancing existing (?P<name>pattern) notation, to
> set a new match object attribute to name if & when pattern matches?
> Then arbitrary info associated with a named pattern can be gotten at
> via dicts via the pattern name, & the whole mess should be more
> readable.

[/F
 Sent: Sunday, July 02, 2000 6:35 PM]
> I just added "lastindex" and "lastgroup" attributes to the match object.
>
> "lastindex" is the integer index of the last matched capturing group,
> "lastgroup" the corresponding name (or None, if the group didn't have
> a name).  both attributes are None if no group were matched.

Reviewing this before 2.0 has been on my todo list for 3+ months, and
finally got to it.  Good show!  I converted some of my by-hand scanners to
use lastgroup, and like it a whole lot.  I know you understand why this is
Good, so here's a simple example of an "after" tokenizer for those who don't
(this one happens to tokenize REXX-like PARSE stmts):

import re
_token = re.compile(r"""
        (?P<space> \s+)
    |   (?P<var> [a-zA-Z_]\w*)
    |   (?P<dontcare> \.)
    |   (?P<number> \d+)
    |   (?P<punc> [-+=()])
    |   (?P<string> " [^"\\\n]* (?: \\. [^"\\\n]*)* "
        |           ' [^'\\\n]* (?: \\. [^'\\\n]*)* '
        )
""", re.VERBOSE).match
del re

(T_SPACE,
 T_VAR,
 T_DONTCARE,
 T_NUMBER,
 T_PUNC,
 T_STRING,
 T_EOF,
)           = range(7)

# For debug output.
_enum2name = ["T_SPACE",
              "T_VAR",
              "T_DONTCARE",
              "T_NUMBER",
              "T_PUNC",
              "T_STRING",
              "T_EOF",
             ]

_group2action = {
    "space":    (T_SPACE, None),
    "var":      (T_VAR, None),
    "dontcare": (T_DONTCARE, None),
    "number":   (T_NUMBER, int),
    "punc":     (T_PUNC, None),
    "string":   (T_STRING, eval),
}

def tokenize(s, tokeneater):
    i, n = 0, len(s)
    while i < n:
        m = _token(s, i)
        if not m:
            raise ParseError(s, i)
        group = m.lastgroup
        enum, action = _group2action[group]
        val = m.group(group)
        if action is not None:
            val = action(val)
        tokeneater(enum, val)
        i = m.end()
    tokeneater(T_EOF, None)

The tokenize function here used to be a mass of if/elif stmts trying to
figure out which group had matched.  Now it's all table-driven:  easier to
write, reuse & maintain, and quicker to boot.  +1.

the-aged-may-be-slow-but-they-never-forget<wink>-ly y'rs  - tim





From effbot at telia.com  Sun Oct  8 13:04:50 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Sun, 8 Oct 2000 13:04:50 +0200
Subject: [Python-Dev] Tcl and Unicode
References: <LNBBLJKPBEHFEDALKOLCMECEHKAA.tim_one@email.msn.com>
Message-ID: <016b01c03117$a3cb6a80$766940d5@hagrid>

guido:
> > This *should* be correct because Tcl/Tk always uses UTF-8 internally.
> > (Even though it is "lenient" when receiving strings -- if a sequence
> > of characters has no valid Unicode representation, it appears to falls
> > back to Latin-1; I don't know the details of this algorithm.)

Tcl/Tk uses a 16-bit (UCS-2) unicode string type internally, but
their 8-bit strings use UTF-8.

When converting from external 8-bit strings to unicode, they
convert valid UTF-8 sequences to unicode characters just like
Python, but "a lead-byte not followed by enough trail-bytes
represents itself." (in other words, it's cast from an unsigned
char to an unsigned short).

And the chance that any reasonable Latin-1 string would contain
a UTF-8 lead bytes followed by the right number of UTF-8 trail
bytes is close to zero...

(in case anyone wonders, Python's codec thinks that "close
to zero" isn't good enough, so it raises an exception instead)

tim:
> Dunno, but wouldn't be surprised if they had a notion of default encoding,
> and that it simply appears to be Latin-1 to us because American Windows uses
> a superset of Latin-1.

They have a system encoding, but it's not used here -- it's just
that Latin-1 is a subset of Unicode...

</F>




From thomas at xs4all.net  Sun Oct  8 13:14:33 2000
From: thomas at xs4all.net (Thomas Wouters)
Date: Sun, 8 Oct 2000 13:14:33 +0200
Subject: [Python-Dev] Release candidate
Message-ID: <20001008131433.M12812@xs4all.nl>

Is there any chance we can get the 'release candidate' released on the SF
File Module thingy as well ? Mailman uses this for the betas, for instance,
and I think it would attract that bit more attention to it. I believe the
'release' gets listed on various SF pages that way.

-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!



From barry at scottb.demon.co.uk  Sun Oct  8 16:36:45 2000
From: barry at scottb.demon.co.uk (Barry Scott)
Date: Sun, 8 Oct 2000 15:36:45 +0100
Subject: [Python-Dev] Python 2.0b2 note for Windows developers
In-Reply-To: <LNBBLJKPBEHFEDALKOLCCEILHIAA.tim_one@email.msn.com>
Message-ID: <000401c03135$2ebd4ec0$060210ac@private>

Tim,
	Two requests:

1. Can you ship the .PDB files for the debug images so devo's
   do not need to build the python sources to debug extensions.
   And Yes I know the .ZIP will be huge. If you want a
   compromise only include the .PDB for python20_d.dll.

2. Place the files into libs, pyd etc dirs. I had to extract
   the groups into the right places which is a bit tedious
   and error prone.

		BArry

> -----Original Message-----
> From: python-dev-admin at python.org [mailto:python-dev-admin at python.org]On
> Behalf Of Tim Peters
> Sent: 27 September 2000 23:40
> To: PythonDev; Python list
> Subject: [Python-Dev] Python 2.0b2 note for Windows developers
> 
> 
> Since most Python users on Windows don't have any use for them, I trimmed
> the Python 2.0b2 installer by leaving out the debug-build .lib, .pyd, .exe
> and .dll files.  If you want them, they're available in a separate zip
> archive; read the Windows Users notes at
> 
> http://www.pythonlabs.com/products/python2.0/download_python2.0b2.html
> 
> for info and a download link.  If you don't already know *why* you might
> want them, trust me:  you don't want them <wink>.
> 
> they-don't-even-make-good-paperweights-ly y'rs  - tim
> 
> 
> 
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://www.python.org/mailman/listinfo/python-dev
> 



From ping at lfw.org  Sun Oct  8 20:19:51 2000
From: ping at lfw.org (Ka-Ping Yee)
Date: Sun, 8 Oct 2000 11:19:51 -0700 (PDT)
Subject: [Python-Dev] linuxaudiodev module
In-Reply-To: <14814.21033.195290.728159@bitdiddle.concentric.net>
Message-ID: <Pine.LNX.4.10.10010081109230.454-100000@skuld.kingmanhall.org>

On Fri, 6 Oct 2000, Jeremy Hylton wrote:
> 
> Have you tried the new code, BTW?  Does the test work on your machine?

Works okay (i updated after Guido's last edit).  Sounds fine to me.

But it bugs me that some of the descriptions say "audio" and others say
"format".  This seems arbitrary -- is there a reason?

Excerpt of Modules/linuxaudiodev.c:
    {  8, ??????AFMT_MU_LAW, "Logarithmic mu-law audio" },
    {  8, ??????AFMT_A_LAW,  "Logarithmic A-law audio" },
    {  8,???????AFMT_U8,     "Standard unsigned 8-bit audio" },
    {  8, ??????AFMT_S8,     "Standard signed 8-bit audio" },
    { 16, ??????AFMT_U16_BE, "Big-endian 16-bit unsigned format" },
    { 16, ??????AFMT_U16_LE, "Little-endian 16-bit unsigned format" },
    { 16, ??????AFMT_S16_BE, "Big-endian 16-bit signed format" },
    { 16, ??????AFMT_S16_LE, "Little-endian 16-bit signed format" },

If you don't mind, i'd prefer something like:
    {  8, ??????AFMT_MU_LAW, "logarithmic mu-law 8-bit audio" },
    {  8, ??????AFMT_A_LAW,  "logarithmic A-law 8-bit audio" },
    {  8,???????AFMT_U8,     "linear unsigned 8-bit audio" },
    {  8, ??????AFMT_S8,     "linear signed 8-bit audio" },
    { 16, ??????AFMT_U16_BE, "linear unsigned 16-bit big-endian audio" },
    { 16, ??????AFMT_U16_LE, "linear unsigned 16-bit little-endian audio" },
    { 16, ??????AFMT_S16_BE, "linear signed 16-bit big-endian audio" },
    { 16, ??????AFMT_S16_LE, "linear signed 16-bit little-endian audio" },

The above conforms to:

    <format> <width> "audio"

    where <format> ::= "logarithmic" ("mu-law" | "A-law") |
                       "linear" ("unsigned" | "signed")

          <width> ::= "8-bit" | "16-bit" ("big-endian" | "little-endian")


-- ?!ng

"Simple, yet complex."
    -- Lenore Snell




From tim_one at email.msn.com  Sun Oct  8 21:28:55 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Sun, 8 Oct 2000 15:28:55 -0400
Subject: [Python-Dev] Python 2.0b2 note for Windows developers
In-Reply-To: <000401c03135$2ebd4ec0$060210ac@private>
Message-ID: <LNBBLJKPBEHFEDALKOLCGEEEHKAA.tim_one@email.msn.com>

[Barry]
> 	Two requests:
>
> 1. Can you ship the .PDB files for the debug images so devo's
>    do not need to build the python sources to debug extensions.
>    And Yes I know the .ZIP will be huge. If you want a
>    compromise only include the .PDB for python20_d.dll.

Sure!  Most .pdb files are highly compressible, and the zip size hit isn't
anything to worry about.

> 2. Place the files into libs, pyd etc dirs. I had to extract
>    the groups into the right places which is a bit tedious
>    and error prone.

No.  If you want a directory structure that doesn't match the actual build
directory structure, I can't read your mind, and have no reason to believe
that the specific artificial structure you have in mind is of use to anyone
but you.  Don't be so helpless <wink>:  write a tiny Python script to move
the files where you want them after unpacking.  What I upload will be an
exact image of the build directory structure.  Most feedback I've gotten is
that people want exactly that, because they *want* to compile Python
themselves and just want to avoid jumping thru all the snaky hoops needed to
compile the 3rd-party subprojects (from _tkinter to zlib).

alphabetically y'rs  - tim





From guido at python.org  Sun Oct  8 22:52:54 2000
From: guido at python.org (Guido van Rossum)
Date: Sun, 08 Oct 2000 15:52:54 -0500
Subject: [Python-Dev] linuxaudiodev module
In-Reply-To: Your message of "Sun, 08 Oct 2000 11:19:51 MST."
             <Pine.LNX.4.10.10010081109230.454-100000@skuld.kingmanhall.org> 
References: <Pine.LNX.4.10.10010081109230.454-100000@skuld.kingmanhall.org> 
Message-ID: <200010082052.PAA27119@cj20424-a.reston1.va.home.com>

> But it bugs me that some of the descriptions say "audio" and others say
> "format".  This seems arbitrary -- is there a reason?

Okay, you're right.  (But there are sooooo many other things wrong
with the code still...  E.g. the bogus reference to "ctl". :-( )

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



From paul at prescod.net  Mon Oct  9 08:04:55 2000
From: paul at prescod.net (Paul Prescod)
Date: Sun, 08 Oct 2000 23:04:55 -0700
Subject: [Python-Dev] A standard lexer?
References: <LNBBLJKPBEHFEDALKOLCAEDGHKAA.tim_one@email.msn.com>
Message-ID: <39E16007.5F1DDF9A@prescod.net>

Tim Peters wrote:
> 
> ...
> 
> Reviewing this before 2.0 has been on my todo list for 3+ months, and
> finally got to it.  Good show!  I converted some of my by-hand scanners to
> use lastgroup, and like it a whole lot.  I know you understand why this is
> Good, so here's a simple example of an "after" tokenizer for those who don't
> (this one happens to tokenize REXX-like PARSE stmts):

Is there a standard technique for taking a regexp like this and applying
it to data fed in a little at a time? Other than buffering the data
forever? That's something else I would like in a "standard Python
lexer", if that's the goal.

-- 
 Paul Prescod - Not encumbered by corporate consensus
Simplicity does not precede complexity, but follows it. 
	- http://www.cs.yale.edu/homes/perlis-alan/quotes.html



From guido at beopen.com  Thu Oct  5 15:16:14 2000
From: guido at beopen.com (Guido van Rossum)
Date: Thu, 5 Oct 2000 09:16:14 -0400
Subject: [Python-Dev] htmllib.HTMLescape()
References: <200010042031.WAA17378@pandora.informatik.hu-berlin.de>
Message-ID: <000701c031f4$59507440$7aa41718@reston1.va.home.com>

Note that cgi.escape() does this too.

--Guido

----- Original Message ----- 
From: "Martin von Loewis" <loewis at informatik.hu-berlin.de>
To: <aahz at panix.com>
Cc: <python-dev at python.org>
Sent: Wednesday, October 04, 2000 4:31 PM
Subject: [Python-Dev] htmllib.HTMLescape()


> > Someone just pointed out on c.l.py that we need an HTMLescape()
> > function that takes a string and converts special characters to
> > entities.  I'm not on python-dev, so could you please forward this
> > and find out whether I need to run a PEP?
> 
> Doesn't xml.sax.saxutils.escape do what you want (together with
> htmlentitydefs)? I was going to say that this is quite a small change
> to warrant a PEP - but there are two obvious approaches (working from
> scratch, or working on top of xml.sax.saxutils.escape - perhaps
> modifying and relocating that function), so *some* design probably
> needs to be recorded in a PEP.
> 
> Regards,
> Martin
> 
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://www.python.org/mailman/listinfo/python-dev
> 




From loewis at informatik.hu-berlin.de  Mon Oct  9 16:01:10 2000
From: loewis at informatik.hu-berlin.de (Martin von Loewis)
Date: Mon, 9 Oct 2000 16:01:10 +0200 (MET DST)
Subject: [Python-Dev] htmllib.HTMLescape()
In-Reply-To: <000701c031f4$59507440$7aa41718@reston1.va.home.com>
	(guido@beopen.com)
References: <200010042031.WAA17378@pandora.informatik.hu-berlin.de> <000701c031f4$59507440$7aa41718@reston1.va.home.com>
Message-ID: <200010091401.QAA21515@pandora.informatik.hu-berlin.de>

> Note that cgi.escape() does this too.

Indeed. That justifies a PEP that proposes to concentrate the
functionality in one place, deprecating the other places.

One approach would be to enhance the codec facilites, so that
"string".encode("iso-entities") becomes possible - but that is already
in the middle of discussing the PEP.

Regards,
Martin



From jeremy at beopen.com  Mon Oct  9 16:35:48 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Mon, 9 Oct 2000 10:35:48 -0400 (EDT)
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules zlibmodule.c,2.35,2.36
In-Reply-To: <200010091418.HAA08765@slayer.i.sourceforge.net>
References: <200010091418.HAA08765@slayer.i.sourceforge.net>
Message-ID: <14817.55236.288126.338665@bitdiddle.concentric.net>

Thanks.  I didn't get to it on Friday.

Jeremy



From trentm at ActiveState.com  Tue Oct 10 00:56:00 2000
From: trentm at ActiveState.com (Trent Mick)
Date: Mon, 9 Oct 2000 15:56:00 -0700
Subject: [Python-Dev] test_sre.py fails on Win64 because PyOS_CheckStack *never* fails
In-Reply-To: <000b01c02e4c$2ac63980$766940d5@hagrid>; from effbot@telia.com on Wed, Oct 04, 2000 at 11:43:41PM +0200
References: <20001004141737.A16659@ActiveState.com> <000b01c02e4c$2ac63980$766940d5@hagrid>
Message-ID: <20001009155600.A27929@ActiveState.com>

[Trent notes that PyOS_CheckStack never fails on Win64 hence test_[s]re.py
    fail on the overflow checks]

[Fredrik gives me a simple test C program to test PyOS_CHeckStack
    independently (The test program is included at the bottom of this
    email.)]

SOrry I took so long to reply to this but I spent a little bit of time
playing with PyOS_CheckStack on Win32 and Win64 and I am now just frustrated.
Here is what I found:

- The simple test program shows that PyOS_CheckStack will fire as intended
  on both Win32 and Win64 with either Visual C's default optimization OR no
  optimization.
- The simple test program will *not* fire as intended with the '-O2'
  optimization which Python *does* use for pythonrun.c (where
  PyOS_CheckStack lives). So, likely the '-O2' optimization will
  optimize-away the _alloca() call. Fine. But why then does it *not* get
  optimized away when pythonrun.c is compiled? Does the context around other
  code in the same file affect that optimization?
- When I apply this patch to _sre.c on *Win32* (basically the same test as
  the test file that Fredrik gave me to try) the "callme(0)" call *never*
  returns -- infinite loop. Note that this happens on the Release *and* Debug
  builds so nothing is being optimized away.

***************
*** 560,565 ****
--- 560,569 ----
  }
  #endif

+
+
+ void callme(int i);
+
  LOCAL(int)
  SRE_MATCH(SRE_STATE* state, SRE_CODE* pattern, int level)
  {
***************
*** 578,583 ****
--- 582,588 ----
      TRACE(("|%p|%p|ENTER %d\n", pattern, ptr, level));

  #if defined(USE_STACKCHECK)
+     callme(0);
      if (level % 10 == 0 && PyOS_CheckStack())
          return SRE_ERROR_RECURSION_LIMIT;
  #endif
***************
*** 2337,2340 ****
--- 2342,2357 ----
      Py_InitModule("_" MODULE, _functions);
  }

+ void callme(int i)
+ {
+     char buf[100000];
+     if (PyOS_CheckStack())
+         return;
+     printf("%d\n", i);
+     memset(buf, 0, sizeof buf);
+     callme(i+1);
+ }
+
+
+
  #endif /* !defined(SRE_RECURSIVE) */

- I am not smart enough and/or (you decide :) do not have the inclination to
  figure this out (i.e. start looking at assembly code) just so _sre can use
  stack checking instead of the existing RECURSION_LIMIT framework (albeit
  the limited general usefullness of this) on Win64 so that test_sre.py can
  pass.

  Would it be alright for me to apply:


*** python/dist/src/Include/pythonrun.h       Sat Sep 16 09:31:31 2000
--- python/dist/src/Include/pythonrun.h  Sun Oct  8 10:20:02 2000
***************
*** 88,94 ****
     to a 8k margin. */
  #define PYOS_STACK_MARGIN 2048

! #if defined(WIN32) && defined(_MSC_VER)
  /* Enable stack checking under Microsoft C */
  #define USE_STACKCHECK
  #endif
--- 88,94 ----
     to a 8k margin. */
  #define PYOS_STACK_MARGIN 2048

! #if defined(WIN32) && !defined(MS_WIN64) && defined(_MSC_VER)
  /* Enable stack checking under Microsoft C */
  #define USE_STACKCHECK
  #endif


  to disable stack checking on Win64 until Win64 become more mainstream and
  others can bang away at this? The important thing, I would think, is
  getting the test suite passing for Python 2.0.


------- test file mentioned above --------------------------------
#include <malloc.h>
#include <excpt.h>

int __inline
PyOS_CheckStack()
{
    __try {
        _alloca(100000);
        return 0;
    } __except (EXCEPTION_EXECUTE_HANDLER) {
        /* just ignore all errors */
    }
    return 1;
}

void
callme(int i)
{
    char buf[100000];
    if (PyOS_CheckStack())
        return;
    printf("%d\n", i);
    memset(buf, 0, sizeof buf);
    callme(i+1);
}

int
main()
{
    callme(0);
}
-----------------------------------------------------


-- 
Trent Mick
TrentM at ActiveState.com



From jeremy at beopen.com  Tue Oct 10 02:26:27 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Mon, 9 Oct 2000 20:26:27 -0400 (EDT)
Subject: [Python-Dev] Pre-release copies of the 2.0c1 source tarball
Message-ID: <14818.25139.747635.586267@bitdiddle.concentric.net>

I have placed pre-release copies of the 2.0 release candidate 1 source
tarballs at ftp://python.beopen.com/pub/python/2.0c1/.  We reserve the
right two change these without notice prior to the official release
:-).

Jeremy



From nas at arctrix.com  Mon Oct  9 21:06:08 2000
From: nas at arctrix.com (Neil Schemenauer)
Date: Mon, 9 Oct 2000 12:06:08 -0700
Subject: [Python-Dev] test_import failing
Message-ID: <20001009120608.A13588@glacier.fnational.com>

I assume the CVS sources are basicly the same as 2.0c1.  Anyhow,
test_import is failing on my Debian machine.  The script is
creating "@test.py" and then trying to import it.  "." is not in
sys.path for some reason.

  Neil



From jeremy at beopen.com  Tue Oct 10 04:17:31 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Mon, 9 Oct 2000 22:17:31 -0400 (EDT)
Subject: [Python-Dev] Re: test_import failing
In-Reply-To: <20001009120608.A13588@glacier.fnational.com>
References: <20001009120608.A13588@glacier.fnational.com>
Message-ID: <14818.31803.227516.852814@bitdiddle.concentric.net>

I assume that you are running the test some way other than using 
"make test."  It seems that make test executes python this way --
PYTHONPATH= ./python
-- which causes the current directory to be added to the path.
If you run python without having the current directory on your path
test_import file fail.

Unless you are having a different problem, this isn't important enough
to fix in 2.0c1, although it seems good to fix for 2.0 final.

Jeremy

PS We have left GC turned on by default in 2.0c1 and plan to do the
same for 2.0 final.




From fdrake at beopen.com  Tue Oct 10 04:09:34 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Mon, 9 Oct 2000 22:09:34 -0400 (EDT)
Subject: [Python-Dev] test_import failing
In-Reply-To: <20001009120608.A13588@glacier.fnational.com>
References: <20001009120608.A13588@glacier.fnational.com>
Message-ID: <14818.31326.292172.223405@cj42289-a.reston1.va.home.com>

Neil Schemenauer writes:
 > I assume the CVS sources are basicly the same as 2.0c1.  Anyhow,
 > test_import is failing on my Debian machine.  The script is
 > creating "@test.py" and then trying to import it.  "." is not in
 > sys.path for some reason.

  Jeremy & I finally figured this out.  "make test" runs python with
PYTHONPATH set to '' (an empty string).  This is decidedly different
from running with PYTHONPATH unset (I consider this a bug that should
be fixed in 2.1).
  The empty string is interpreted as the current directory (as
expected), so running "make test" adds the current directory to
sys.path, but running the regression test (test_import or regrtest) as
a script does not.
  We decided not to fix this now, since it's too late to be sure it's
the right change, and adjusting the test case also means a very late
change.  So whoever runs the tests is responsible for making sure the
current directory is on sys.path.  (*Really* bogus!)


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From fdrake at beopen.com  Tue Oct 10 04:20:11 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Mon, 9 Oct 2000 22:20:11 -0400 (EDT)
Subject: [Python-Dev] Re: test_import failing
In-Reply-To: <14818.31803.227516.852814@bitdiddle.concentric.net>
References: <20001009120608.A13588@glacier.fnational.com>
	<14818.31803.227516.852814@bitdiddle.concentric.net>
Message-ID: <14818.31963.385267.336885@cj42289-a.reston1.va.home.com>

Jeremy Hylton writes:
 > Unless you are having a different problem, this isn't important enough
 > to fix in 2.0c1, although it seems good to fix for 2.0 final.

  And it's questionable how many bugs are hiding here as well.  I
count two:

  - test_import.py assumes the current directory is on the path; this
    is just plain fragile, and should explicitly pick the directory
    off of test_support.TESTFN, and add it to sys.path for the
    duration of the test (which does indeed fix this bug)

  - Modules/getpath.c interprets an empty definition of $PYTHONPATH as
    adding '' to sys.path, where I assert it should not add anything
    to sys.path.  Everywhere else I've recall seeing an environment
    variable used as a data source, the test is done like this:

    char *cp = getenv("VARIABLE");
    if (cp != NULL && cp[0] != '\0') {
        ...
    }

    (with some spelling variations).


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From jeremy at beopen.com  Tue Oct 10 08:52:48 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Mon, 9 Oct 2000 23:52:48 -0700 (PDT)
Subject: [Python-Dev] Python 2.0 release candidate 1
Message-ID: <200010100652.XAA74600@python.beopen.com>

Python 2.0c1 is released.  The BeOpen PythonLabs and our cast of
SourceForge volunteers have fixed many bugs since the beta releases
last month.  Please pick up the new release at

    http://www.pythonlabs.com/products/python2.0/

There's a tarball, a Windows installer, RedHat RPMs, online
documentation, and a long list of fixed bugs.

The final release of Python 2.0 will be next week.  We would
appreciate feedback on the release candidate in order to fix any
remaining bugs before the final release.  Confirmation of build and
test success on less common platforms is also helpful.n

All major reported bugs have been fixed in the release candidate.  We
do not plan to make any changes between now and the final release,
except to fix bugs reported in the next week.  We encourage potential
users of Python 2.0 to try the release candidate with their programs
and report any remaining bugs.

To report a new bug, use the SourceForge bug tracker
http://sourceforge.net/bugs/?func=addbug&group_id=5470

Python 2.0 has many new features, including the following:

  - Augmented assignment, e.g. x += 1
  - List comprehensions, e.g. [x**2 for x in range(10)]
  - Extended import statement, e.g. import Module as Name
  - Extended print statement, e.g. print >> file, "Hello"
  - Collection of cyclical garbage

For a fuller discussion of the changes in Python 2.0, please see the
article "What's New in Python 2.0" by Andrew Kuchling and Moshe Zadke:
http://starship.python.net/crew/amk/python/writing/new-python/

-- Jeremy Hylton <http://www.python.org/~jeremy/>




From tismer at appliedbiometrics.com  Tue Oct 10 12:33:36 2000
From: tismer at appliedbiometrics.com (Christian Tismer)
Date: Tue, 10 Oct 2000 13:33:36 +0300
Subject: [Python-Dev] Stackless Python 1.2 + Continuations 0.9
Message-ID: <39E2F080.86ED1DA3@appliedbiometrics.com>

ANNOUNCING:

               Stackless Python 1.2
           A Python Implementation That
             Does Not Use The C Stack

               * plus the real toy *

              Continuation Module 0.9
        Continuations as First Class Objects
            with support for MicroThreads

What is it?
A plugin-replacement for core Python.
It should run any program which runs under Python 1.5.2 .
But it does not need space on the C stack.

For further info, see the new site at 
   
              http://www.stackless.com

You might also want to join the mailing list at

     http://starship.python.net/mailman/listinfo/stackless

Major changes in this release:
Extra reference counting reduces continuation frame creation
Better exception handling avoids cycles.

Next to come:
- A port to Python 2.0 will be the first thing to do.
- Long-term project is a complete redesign and
  rewrite for inclusion with Python 2.1

ciao - Christian Tismer / Mission Impossible 5oftware Team

<P><A HREF="http://www.tismer.com/research/stackless/">Stackless
Python 1.2 + Continuations 0.9</A> - a version of Python 1.5.2 that
does not need space on the C stack, first-class callable
continuation objects for Python, and Microthread-support. 
(10-Oct-2000)
</P>

-- 
http://www.python.org/mailman/listinfo/python-list



From guido at python.org  Tue Oct 10 15:04:39 2000
From: guido at python.org (Guido van Rossum)
Date: Tue, 10 Oct 2000 08:04:39 -0500
Subject: [Python-Dev] test_import failing
In-Reply-To: Your message of "Mon, 09 Oct 2000 22:09:34 -0400."
             <14818.31326.292172.223405@cj42289-a.reston1.va.home.com> 
References: <20001009120608.A13588@glacier.fnational.com>  
            <14818.31326.292172.223405@cj42289-a.reston1.va.home.com> 
Message-ID: <200010101304.IAA13010@cj20424-a.reston1.va.home.com>

> Neil Schemenauer writes:
>  > I assume the CVS sources are basicly the same as 2.0c1.  Anyhow,
>  > test_import is failing on my Debian machine.  The script is
>  > creating "@test.py" and then trying to import it.  "." is not in
>  > sys.path for some reason.
> 
>   Jeremy & I finally figured this out.  "make test" runs python with
> PYTHONPATH set to '' (an empty string).  This is decidedly different
> from running with PYTHONPATH unset (I consider this a bug that should
> be fixed in 2.1).
>   The empty string is interpreted as the current directory (as
> expected), so running "make test" adds the current directory to
> sys.path, but running the regression test (test_import or regrtest) as
> a script does not.
>   We decided not to fix this now, since it's too late to be sure it's
> the right change, and adjusting the test case also means a very late
> change.  So whoever runs the tests is responsible for making sure the
> current directory is on sys.path.  (*Really* bogus!)

Proper fix, which I will check in momentarily: put

    import sys
    sys.path.insert(0, os.curdir)

in front of test_import.py; and add

    del sys.path[0]

to the end.

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



From guido at python.org  Tue Oct 10 15:06:54 2000
From: guido at python.org (Guido van Rossum)
Date: Tue, 10 Oct 2000 08:06:54 -0500
Subject: [Python-Dev] Re: test_import failing
In-Reply-To: Your message of "Mon, 09 Oct 2000 22:20:11 -0400."
             <14818.31963.385267.336885@cj42289-a.reston1.va.home.com> 
References: <20001009120608.A13588@glacier.fnational.com> <14818.31803.227516.852814@bitdiddle.concentric.net>  
            <14818.31963.385267.336885@cj42289-a.reston1.va.home.com> 
Message-ID: <200010101306.IAA13031@cj20424-a.reston1.va.home.com>

>   And it's questionable how many bugs are hiding here as well.  I
> count two:
> 
>   - test_import.py assumes the current directory is on the path; this
>     is just plain fragile, and should explicitly pick the directory
>     off of test_support.TESTFN, and add it to sys.path for the
>     duration of the test (which does indeed fix this bug)

I'll fix this.

>   - Modules/getpath.c interprets an empty definition of $PYTHONPATH as
>     adding '' to sys.path, where I assert it should not add anything
>     to sys.path.  Everywhere else I've recall seeing an environment
>     variable used as a data source, the test is done like this:
> 
>     char *cp = getenv("VARIABLE");
>     if (cp != NULL && cp[0] != '\0') {
>         ...
>     }
> 
>     (with some spelling variations).

Agreed, but please *don't fix this in 2.0!*

Who knows how many other hidden bugs (in 3rd party code) this will
trigger...

OK to fix it after 2.0final is released.

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



From mal at lemburg.com  Tue Oct 10 14:58:09 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Tue, 10 Oct 2000 14:58:09 +0200
Subject: [Python-Dev] LICENSE file in Python 2.0c1
Message-ID: <39E31261.166F1601@lemburg.com>

I've just had a glance at the releas candidate 1. The file LICENSE
has grown somewhat, but not as much as I feared... looking
at the contents I find the following as only reference to the
CNRI license (which holds all the surprises we talked about in
the early beta stages):

"""
CNRI OPEN SOURCE LICENSE AGREEMENT
----------------------------------

Python 1.6 is made available subject to the terms and conditions in
CNRI's License Agreement.  This Agreement together with Python 1.6 may
be located on the Internet using the following unique, persistent
identifier (known as a handle): 1895.22/1012.  This Agreement may also
be obtained from a proxy server on the Internet using the following
URL: http://hdl.handle.net/1895.22/1012.
"""

Such a note is nice and short, but not legally binding and 
confusing since it is not clear whether the "handle" for the
document will always return the same license text or if it
will return a license text at all.

It would be more appropriate to include the original CNRI license
text, IMHO. Or is there some hidden motivation behind using the
handle ?

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From thomas.heller at ion-tof.com  Tue Oct 10 15:06:05 2000
From: thomas.heller at ion-tof.com (Thomas Heller)
Date: Tue, 10 Oct 2000 15:06:05 +0200
Subject: [Python-Dev] distutils and bdist_wininst confusion: clarification
Message-ID: <01be01c032ba$dc889ba0$4500a8c0@thomasnotebook>

There has been some confusion about distutils, especially the
bdist_wininst command.
I hope I can clarify these things with this post.

1. The current Distutils version 1.0, which is also
   included in the Python 2.0 release candidate is perfectly
   usable apart from one bug:
   You should create windows installers (by running
   'setup.py bdist_wininst' or 'setup.py bdist --formats=wininst')
   ONLY with an external zip utility (info-zip would do).
   Using the zipfile module results in corrupted installations
   (all files are created with zero length).
   Details about the cause for this can be found in the patch
   I posted to SF.


2. I submitted a patch to SF
   http://sourceforge.net/patch/?func=detailpatch&patch_id=101844&group_id=5470
   which corrects this bug.
   Normally I would have checked this code in immediately,
   because it is in _my_ code, and that's what my checkin rights
   are for ;-).
   I did not because I did not want to interfere with the release process of
   python 2.0 rc 1.


3. How does bdist_wininst work?
   bdist_wininst creates a self-extracting zipfile from two
   components: a stub program (wininst.exe) plus a zip-file
   containing the code to be distributed. Because I did not
   liked wininst.exe as binary file checked in into CVS,
   the actual bytes of this exe are included base64-encoded
   in the bdist_wininst.py module as string. I'm not sure
   whether this is a wise design or not, but that is a different
   topic.
   The downside of this design is that when the source to 
   wininst.exe changes, it must be recompiled, and bdist_wininst.py
   must be regenerated. The context-diffs for bdist_wininst.py
   are so very large.


4. To understand the patch, you should know the following:
   Distutils is a separate toplevel module in the repository
   on sourceforge. Parts of this repository are symbolically
   linked somewhere into the python tree. Thus, this patch must
   be applied to the distutils _module_ in the repository.

   Distutils directory structure is as follows:

   distutils
     dd
     distutils
       command
     doc
       dist
       inst
     examples
       sample1
       sample2
       sample3
     misc
     test
     text

   Relevant part of python directory structure:

   python
     dist
       src
         Lib
           distutils
             command

   The source code for wininst.exe is in CVS in the distutils/misc
   directory.
   The patch I posted to SF does not include the compiled
   wininst.exe, neither does it include the (regenerated)
   bdist_wininst.py module.

5. If nobody objects, I will check in the changes I made tomorrow, recompile
   the exe, regenerate the bdist_wininst.py, and everything should be
   fine again.
   Greg will then hopefully, when he is back, increase the distutils version
   number to 1.0.1 (or whatever) and this version will then be delivered with
   python 2.0 final.

Sorry for the confusion.

Cheers,

Thomas






From guido at python.org  Tue Oct 10 16:36:57 2000
From: guido at python.org (Guido van Rossum)
Date: Tue, 10 Oct 2000 09:36:57 -0500
Subject: [Python-Dev] LICENSE file in Python 2.0c1
In-Reply-To: Your message of "Tue, 10 Oct 2000 14:58:09 +0200."
             <39E31261.166F1601@lemburg.com> 
References: <39E31261.166F1601@lemburg.com> 
Message-ID: <200010101436.JAA13237@cj20424-a.reston1.va.home.com>

> I've just had a glance at the releas candidate 1. The file LICENSE
> has grown somewhat, but not as much as I feared...

Since when?  It hasn't changed since it was first released, for 2.0b1.

> looking
> at the contents I find the following as only reference to the
> CNRI license (which holds all the surprises we talked about in
> the early beta stages):
> 
> """
> CNRI OPEN SOURCE LICENSE AGREEMENT
> ----------------------------------
> 
> Python 1.6 is made available subject to the terms and conditions in
> CNRI's License Agreement.  This Agreement together with Python 1.6 may
> be located on the Internet using the following unique, persistent
> identifier (known as a handle): 1895.22/1012.  This Agreement may also
> be obtained from a proxy server on the Internet using the following
> URL: http://hdl.handle.net/1895.22/1012.
> """
> 
> Such a note is nice and short, but not legally binding and 
> confusing since it is not clear whether the "handle" for the
> document will always return the same license text or if it
> will return a license text at all.

Why do you say it's not legally binding?  The CNRI license explicitly
allows you to use this exact text instead of including the whole CNRI
license.

> It would be more appropriate to include the original CNRI license
> text, IMHO. Or is there some hidden motivation behind using the
> handle ?

I was just trying to save space.  ActivePython does the same thing as
far as I remember.

BTW, I haven't heard from CNRI in two weeks, but the last thing I
heard from them was that their lawyers had talked to Stallman's lawyer
and that they were optimistic about a successful resolution.

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



From guido at python.org  Tue Oct 10 16:41:50 2000
From: guido at python.org (Guido van Rossum)
Date: Tue, 10 Oct 2000 09:41:50 -0500
Subject: [Python-Dev] distutils and bdist_wininst confusion: clarification
In-Reply-To: Your message of "Tue, 10 Oct 2000 15:06:05 +0200."
             <01be01c032ba$dc889ba0$4500a8c0@thomasnotebook> 
References: <01be01c032ba$dc889ba0$4500a8c0@thomasnotebook> 
Message-ID: <200010101441.JAA13276@cj20424-a.reston1.va.home.com>

Thomas, thanks for the explanation.  I agree that you can check in the
changes yourself as you proposed.

There's one issue I still don't understand (not having the time to
read the full distutils docs): how does a typical Windows developer
decide whether to use an external zip utility or the zipfile module?

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



From thomas.heller at ion-tof.com  Tue Oct 10 15:58:32 2000
From: thomas.heller at ion-tof.com (Thomas Heller)
Date: Tue, 10 Oct 2000 15:58:32 +0200
Subject: [Python-Dev] distutils and bdist_wininst confusion: clarification
References: <01be01c032ba$dc889ba0$4500a8c0@thomasnotebook>  <200010101441.JAA13276@cj20424-a.reston1.va.home.com>
Message-ID: <020001c032c2$3060fa40$4500a8c0@thomasnotebook>

> Thomas, thanks for the explanation.  I agree that you can check in the
> changes yourself as you proposed.
> 
> There's one issue I still don't understand (not having the time to
> read the full distutils docs): how does a typical Windows developer
> decide whether to use an external zip utility or the zipfile module?
I'm afraid it is not documented.

Distutils first tries to spawn an external zip program,
then tries the zipfile module, if nothing is found,
a warning is issued.

So, the windows developer currently _must_ install zip.exe
somewhere in the path. (As often, the default is wrong,
because a zip utility is not included in windows).

Thomas




From mal at lemburg.com  Tue Oct 10 16:03:14 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Tue, 10 Oct 2000 16:03:14 +0200
Subject: [Python-Dev] LICENSE file in Python 2.0c1
References: <39E31261.166F1601@lemburg.com> <200010101436.JAA13237@cj20424-a.reston1.va.home.com>
Message-ID: <39E321A2.2BD99E35@lemburg.com>

Guido van Rossum wrote:
> 
> > I've just had a glance at the releas candidate 1. The file LICENSE
> > has grown somewhat, but not as much as I feared...
> 
> Since when?  It hasn't changed since it was first released, for 2.0b1.

Since the old 1.5.2 LICENSE file.
 
> > looking
> > at the contents I find the following as only reference to the
> > CNRI license (which holds all the surprises we talked about in
> > the early beta stages):
> >
> > """
> > CNRI OPEN SOURCE LICENSE AGREEMENT
> > ----------------------------------
> >
> > Python 1.6 is made available subject to the terms and conditions in
> > CNRI's License Agreement.  This Agreement together with Python 1.6 may
> > be located on the Internet using the following unique, persistent
> > identifier (known as a handle): 1895.22/1012.  This Agreement may also
> > be obtained from a proxy server on the Internet using the following
> > URL: http://hdl.handle.net/1895.22/1012.
> > """
> >
> > Such a note is nice and short, but not legally binding and
> > confusing since it is not clear whether the "handle" for the
> > document will always return the same license text or if it
> > will return a license text at all.
> 
> Why do you say it's not legally binding?  The CNRI license explicitly
> allows you to use this exact text instead of including the whole CNRI
> license.

Sure, but not including the verbatim text will produce an
unpleasent feeling of not being sure about the completeness
of the license text.

<nitpicker-suite>

In a law suit the above construct would
certainly not hold, since URLs only describe the location of
information and don't hold any information about the validity
or origin of it. The situation would be a little better if CNRI
had provided a PGP signature or fingerprint of the license,
since this is (in some countries) a legally accepted way of
determining those two criteria.

Just a side note: the URL given for the license results in a 
redirect to a different URL -
http://www.handle.net/python_licenses/python1.6_9-5-00.html
(note the date !): this doesn't really give the impression of
persistent unchangeable information.

</nitpicker-suite>

Not that there's much to fear about... but why add any extra areas
of uncertainty ?

> > It would be more appropriate to include the original CNRI license
> > text, IMHO. Or is there some hidden motivation behind using the
> > handle ?
> 
> I was just trying to save space.  ActivePython does the same thing as
> far as I remember.

Space?... the download is 3.9 Megs ;-)
 
> BTW, I haven't heard from CNRI in two weeks, but the last thing I
> heard from them was that their lawyers had talked to Stallman's lawyer
> and that they were optimistic about a successful resolution.

Great ! This would be really good news indeed :-)

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From just at letterror.com  Tue Oct 10 17:47:00 2000
From: just at letterror.com (Just van Rossum)
Date: Tue, 10 Oct 2000 16:47:00 +0100
Subject: [Python-Dev] Re: [Stackless] Stackless Python 1.2 + Continuations 0.9
In-Reply-To: <39E2F080.86ED1DA3@appliedbiometrics.com>
Message-ID: <l03102806b608e84fd7de@[193.78.237.153]>

In response to the new release of Stackless Python (see
http://www.stackless.com/), here's a new stackless binary for MacPython
1.5.2:

  http://starship.python.net/~just/MacStacklessPython.sit.hqx

(The archive contains a replacement for the PythonCore shared library)

Just





From guido at python.org  Tue Oct 10 17:50:07 2000
From: guido at python.org (Guido van Rossum)
Date: Tue, 10 Oct 2000 10:50:07 -0500
Subject: [Python-Dev] LICENSE file in Python 2.0c1
In-Reply-To: Your message of "Tue, 10 Oct 2000 16:03:14 +0200."
             <39E321A2.2BD99E35@lemburg.com> 
References: <39E31261.166F1601@lemburg.com> <200010101436.JAA13237@cj20424-a.reston1.va.home.com>  
            <39E321A2.2BD99E35@lemburg.com> 
Message-ID: <200010101550.KAA18130@cj20424-a.reston1.va.home.com>

> > > Such a note is nice and short, but not legally binding and
> > > confusing since it is not clear whether the "handle" for the
> > > document will always return the same license text or if it
> > > will return a license text at all.
> > 
> > Why do you say it's not legally binding?  The CNRI license explicitly
> > allows you to use this exact text instead of including the whole CNRI
> > license.
> 
> Sure, but not including the verbatim text will produce an
> unpleasent feeling of not being sure about the completeness
> of the license text.
> 
> <nitpicker-suite>
> 
> In a law suit the above construct would
> certainly not hold, since URLs only describe the location of
> information and don't hold any information about the validity
> or origin of it. The situation would be a little better if CNRI
> had provided a PGP signature or fingerprint of the license,
> since this is (in some countries) a legally accepted way of
> determining those two criteria.
> 
> Just a side note: the URL given for the license results in a 
> redirect to a different URL -
> http://www.handle.net/python_licenses/python1.6_9-5-00.html
> (note the date !): this doesn't really give the impression of
> persistent unchangeable information.
> 
> </nitpicker-suite>

Funny...  I agree that's not very confidence-inspiring.  CNRI always
advertises handles as better than URLs for long-term persistent
documents, but it's clear that they didn't think of this!  Or maybe
(warning: fake conspiracy theory ahead :-) they intend to change the
license terms after the fact...

> Not that there's much to fear about... but why add any extra areas
> of uncertainty ?

Agreed.  I'll add the full text back in.

> > I was just trying to save space.  ActivePython does the same thing as
> > far as I remember.
> 
> Space?... the download is 3.9 Megs ;-)

I meant less text for the reader to wade through.  But you've
convinced me already.

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



From bjorn at roguewave.com  Tue Oct 10 20:35:15 2000
From: bjorn at roguewave.com (Bjorn Pettersen)
Date: Tue, 10 Oct 2000 12:35:15 -0600
Subject: [Python-Dev] Re: Python 2.0 release candidate 1
References: <200010100652.XAA74600@python.beopen.com>
Message-ID: <39E36163.33291FAB@roguewave.com>

Are there any instructions on how to build this for Win64/itanium
anywhere?

-- bjorn

Jeremy Hylton wrote:
> 
> Python 2.0c1 is released.  The BeOpen PythonLabs and our cast of
> SourceForge volunteers have fixed many bugs since the beta releases
> last month.  Please pick up the new release at
> 
>     http://www.pythonlabs.com/products/python2.0/
> 
> There's a tarball, a Windows installer, RedHat RPMs, online
> documentation, and a long list of fixed bugs.
> 
> The final release of Python 2.0 will be next week.  We would
> appreciate feedback on the release candidate in order to fix any
> remaining bugs before the final release.  Confirmation of build and
> test success on less common platforms is also helpful.n
> 
> All major reported bugs have been fixed in the release candidate.  We
> do not plan to make any changes between now and the final release,
> except to fix bugs reported in the next week.  We encourage potential
> users of Python 2.0 to try the release candidate with their programs
> and report any remaining bugs.
> 
> To report a new bug, use the SourceForge bug tracker
> http://sourceforge.net/bugs/?func=addbug&group_id=5470
> 
> Python 2.0 has many new features, including the following:
> 
>   - Augmented assignment, e.g. x += 1
>   - List comprehensions, e.g. [x**2 for x in range(10)]
>   - Extended import statement, e.g. import Module as Name
>   - Extended print statement, e.g. print >> file, "Hello"
>   - Collection of cyclical garbage
> 
> For a fuller discussion of the changes in Python 2.0, please see the
> article "What's New in Python 2.0" by Andrew Kuchling and Moshe Zadke:
> http://starship.python.net/crew/amk/python/writing/new-python/
> 
> -- Jeremy Hylton <http://www.python.org/~jeremy/>
> 
> --
> http://www.python.org/mailman/listinfo/python-list



From trentm at ActiveState.com  Tue Oct 10 21:51:55 2000
From: trentm at ActiveState.com (Trent Mick)
Date: Tue, 10 Oct 2000 12:51:55 -0700
Subject: Building for Win64 (was: Re: [Python-Dev] Re: Python 2.0 release candidate 1)
In-Reply-To: <39E36163.33291FAB@roguewave.com>; from bjorn@roguewave.com on Tue, Oct 10, 2000 at 12:35:15PM -0600
References: <200010100652.XAA74600@python.beopen.com> <39E36163.33291FAB@roguewave.com>
Message-ID: <20001010125155.B3221@ActiveState.com>

On Tue, Oct 10, 2000 at 12:35:15PM -0600, Bjorn Pettersen wrote:
> Are there any instructions on how to build this for Win64/itanium
> anywhere?
> 

Um... not really.  I did/am doing the Win64 port but I have not really given
the information required to build it, which, I agree, kind of sucks. I have
not done so because:

  - the Python build system on Windows uses DevStudio project files
  - AFAIK there is no DevStudio yet for Win64 (if there were, building Python
    would be trivial, just setup a new configuration in DevStudio)
  - I am currently using a cross-compiler for Win64 provided by Intel (as
    part of a contract that ActiveState has to port Python to Win64 and other
    OSes for the IA-64 platform). I don't know if there is a publicly
    available compiler for Win64 (I haven't looked).
  - My method for building for Win64 involves:
    (1) exporting Win32 build makefile from the Python *.dsp files from
        within DevStudio.
    (2) running a hack script of my own to convert those to makefile to ones
        that will build for Win64 (these makefiles are extremely specific to
        my system, i.e. it is a hack)
    (3) run those makefiles

I *could* checkin this hack script of mine and provide some documentation in
Python's standard readme, if the other python-dev'ers would be ammenable to
this. [Note: my files would be isolated to one directory, say PCbuild/win64.]
As I said, I have not done this because I expected to just wait until
DevStudio for Win64 came on the scene and then the build system for it would
fit in smoothly to the current .dsp's.

I would rather not become a separate provider of the Win64 build scripts
because I don't want to support them outside of Python's mechanisms (i.e.
through SourceForge).  In other words, I'll check them into the Python core
if others think that that is okay, otherwise  I am afraid the answer is
"please wait until DevStudio for Win64 comes along".

Trent

-- 
Trent Mick
TrentM at ActiveState.com



From bjorn at roguewave.com  Tue Oct 10 22:24:00 2000
From: bjorn at roguewave.com (Bjorn Pettersen)
Date: Tue, 10 Oct 2000 14:24:00 -0600
Subject: Building for Win64 (was: Re: [Python-Dev] Re: Python 2.0 release 
 candidate 1)
References: <200010100652.XAA74600@python.beopen.com> <39E36163.33291FAB@roguewave.com> <20001010125155.B3221@ActiveState.com>
Message-ID: <39E37AE0.C7380FFD@roguewave.com>

To answer some of your questions:

- there is no win64 devstudio (and I haven't found a way of getting the
current devstudio to use the new compiler)
- Intel does have a native compiler for win64 (don't use it, see below).
- If you look in ia64xdevsdk\bin\win64 there is a cl.exe which is the
Microsoft compiler. It works MUCH better. It's also binary compatible
with the Intel ecl compiler, and they didn't have any problems with us
switching.

My main interest is in having a python version that runs on the itanium
box with socket support (they included socket support in sdk2 didn't
they?) I.e. no need to provide a build mechanism for my needs if you can
refer me to an executable ;-)

-- bjorn

Trent Mick wrote:
> 
> On Tue, Oct 10, 2000 at 12:35:15PM -0600, Bjorn Pettersen wrote:
> > Are there any instructions on how to build this for Win64/itanium
> > anywhere?
> >
> 
> Um... not really.  I did/am doing the Win64 port but I have not really given
> the information required to build it, which, I agree, kind of sucks. I have
> not done so because:
> 
>   - the Python build system on Windows uses DevStudio project files
>   - AFAIK there is no DevStudio yet for Win64 (if there were, building Python
>     would be trivial, just setup a new configuration in DevStudio)
>   - I am currently using a cross-compiler for Win64 provided by Intel (as
>     part of a contract that ActiveState has to port Python to Win64 and other
>     OSes for the IA-64 platform). I don't know if there is a publicly
>     available compiler for Win64 (I haven't looked).
>   - My method for building for Win64 involves:
>     (1) exporting Win32 build makefile from the Python *.dsp files from
>         within DevStudio.
>     (2) running a hack script of my own to convert those to makefile to ones
>         that will build for Win64 (these makefiles are extremely specific to
>         my system, i.e. it is a hack)
>     (3) run those makefiles
> 
> I *could* checkin this hack script of mine and provide some documentation in
> Python's standard readme, if the other python-dev'ers would be ammenable to
> this. [Note: my files would be isolated to one directory, say PCbuild/win64.]
> As I said, I have not done this because I expected to just wait until
> DevStudio for Win64 came on the scene and then the build system for it would
> fit in smoothly to the current .dsp's.
> 
> I would rather not become a separate provider of the Win64 build scripts
> because I don't want to support them outside of Python's mechanisms (i.e.
> through SourceForge).  In other words, I'll check them into the Python core
> if others think that that is okay, otherwise  I am afraid the answer is
> "please wait until DevStudio for Win64 comes along".
> 
> Trent
> 
> --
> Trent Mick
> TrentM at ActiveState.com



From trentm at ActiveState.com  Tue Oct 10 22:20:42 2000
From: trentm at ActiveState.com (Trent Mick)
Date: Tue, 10 Oct 2000 13:20:42 -0700
Subject: [Python-Dev] Monterey (64-bit AIX) screws up the poll() implementation, I think
Message-ID: <20001010132042.B22561@ActiveState.com>

test_poll.py currently fails on Monterey (64-bit AIX) because of a difference
in the system poll() function as compared to Linux.

On Linux (and as required by the Signle Unix Specification:
http://www.opengroup.org/onlinepubs/007908799/xsh/poll.html) if you "poll()"
a bogus file descriptor you get a POLLNVAL return value in the 'revents'
field of the structure sent to poll(). This is tested like so in
test_poll.py:

    # returns NVAL for invalid file descriptor
    FD = 42
    try:
        os.close(FD)
    except OSError:
        pass
    p = select.poll()
    p.register(FD)
    r = p.poll()
    assert r[0] == (FD, select.POLLNVAL)

Monterey decided to return -1 instead. [Aside: However, 'revents's type is
"short" so the Python interface to poll() (using PyInt_FromLong) actually
interprets that as -32768 instead.]

Questions:
1. Can anybody offer an opinion if this is Python's or Monterey's problem?

2. Can anybody tell me where I can browse the POSIX spec to see if this
   breaks POSIX compliance as well?

3. Could someone (Vladimir?) run this test program on a normal AIX box and
   tell me what the output is (does the return value == POLLNVAL?)?

----------------------------------------------------------------------
#include <stdio.h>
#include <poll.h>

#define NFDS 1

int main(void)
{
    struct pollfd ufds[NFDS];
    int pollResult;

    printf("hello\n");

    /* poll for any event on a bogus file descriptor */
    ufds[0].fd = 42;
    ufds[0].events = POLLIN | POLLPRI | POLLOUT;
    pollResult = poll(ufds, NFDS, -1);

    if (pollResult != 1) {
        printf("*** poll result was %d, I expected 1.\n", pollResult);
    }

    printf("ufds[0].revents = %hd\n", ufds[0].revents);
    printf("POLLNVAL = %ld\n", POLLNVAL);

    return 0;
}
----------------------------------------------------------------------


Thanks,
Trent

-- 
Trent Mick
TrentM at ActiveState.com



From trentm at ActiveState.com  Tue Oct 10 22:30:03 2000
From: trentm at ActiveState.com (Trent Mick)
Date: Tue, 10 Oct 2000 13:30:03 -0700
Subject: Building for Win64 (was: Re: [Python-Dev] Re: Python 2.0 release candidate 1)
In-Reply-To: <39E37AE0.C7380FFD@roguewave.com>; from bjorn@roguewave.com on Tue, Oct 10, 2000 at 02:24:00PM -0600
References: <200010100652.XAA74600@python.beopen.com> <39E36163.33291FAB@roguewave.com> <20001010125155.B3221@ActiveState.com> <39E37AE0.C7380FFD@roguewave.com>
Message-ID: <20001010133003.C22561@ActiveState.com>

On Tue, Oct 10, 2000 at 02:24:00PM -0600, Bjorn Pettersen wrote:
> - If you look in ia64xdevsdk\bin\win64 there is a cl.exe which is the
> Microsoft compiler. It works MUCH better. It's also binary compatible
> with the Intel ecl compiler, and they didn't have any problems with us
> switching.

Yes, I knew that that was there. I remember either some earlier problem with
it or some recommnedation to use the ecl.exe one. Anyway, ecl has worked for
me well enough, I just haven't tried the one in Win64/.

 
> My main interest is in having a python version that runs on the itanium
> box with socket support (they included socket support in sdk2 didn't
> they?) I.e. no need to provide a build mechanism for my needs if you can
> refer me to an executable ;-)

Well, Python's test_socket runs on my Win64 box so yes, socket support is
there. As far as referring you to an exe, I would rather not go down that
distribution road in preference to checking in my build scripts.

Trent


-- 
Trent Mick
TrentM at ActiveState.com



From mal at lemburg.com  Tue Oct 10 22:37:30 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Tue, 10 Oct 2000 22:37:30 +0200
Subject: [Python-Dev] -Wall output for the Python 2.0c1
Message-ID: <39E37E0A.90176759@lemburg.com>

FYI, Here's what gcc -Wall gives on Linux:

ceval.c: In function `eval_code2':
ceval.c:345: warning: `v' might be used uninitialized in this function
ceval.c:346: warning: `w' might be used uninitialized in this function
ceval.c:347: warning: `u' might be used uninitialized in this function
ceval.c:348: warning: `t' might be used uninitialized in this function
errors.c: In function `PyErr_Format':
errors.c:409: warning: value computed is not used
errors.c:415: warning: value computed is not used

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From mal at lemburg.com  Tue Oct 10 22:45:00 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Tue, 10 Oct 2000 22:45:00 +0200
Subject: [Python-Dev] What will happen to cycle GC in the 2.0 final ?
Message-ID: <39E37FCC.9925555A@lemburg.com>

It was mentioned early in the beta phase that cycle GC would be
enabled only during the beta cycle and disabled in the final.

Is this still true ?

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From tim_one at email.msn.com  Tue Oct 10 22:47:06 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Tue, 10 Oct 2000 16:47:06 -0400
Subject: [Python-Dev] Monterey (64-bit AIX) screws up the poll() implementation, I think
In-Reply-To: <20001010132042.B22561@ActiveState.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCAEKLHKAA.tim_one@email.msn.com>

[Trent Mick]
> test_poll.py currently fails on Monterey (64-bit AIX) because of
> a difference in the system poll() function as compared to Linux.
>
> On Linux (and as required by the Signle Unix Specification:
> http://www.opengroup.org/onlinepubs/007908799/xsh/poll.html) if
> you "poll()" a bogus file descriptor you get a POLLNVAL return value in
> the 'revents' field of the structure sent to poll().
> ...
> Monterey decided to return -1 instead. [Aside: However, 'revents's type is
> "short" so the Python interface to poll() (using PyInt_FromLong) actually
> interprets that as -32768 instead.]
>
> Questions:
> 1. Can anybody offer an opinion if this is Python's or Monterey's
>    problem?

Both.  "Another day, another incompatible flavor of Unix(tm)."  In the early
days, Guido actually hoped he could get away without a massive hack like
autoconf <wink>.

> 2. Can anybody tell me where I can browse the POSIX spec to see if this
>    breaks POSIX compliance as well?

Nowhere:  ISO/ANSI stds are generally never available online.  They get the
bulk of their money from selling standards.

    http://webstore.ansi.org/

is a good place to buy.  There are about 20 POSIX-related stds documents;
the C API spec is US$245.00.  You may get a cheaper answer on comp.unix.aix,
of course.

may-be-worth-more-than-$245-to-weed-out-the-wrong-answers-though-ly y'rs
    - tim





From tim_one at email.msn.com  Tue Oct 10 22:58:54 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Tue, 10 Oct 2000 16:58:54 -0400
Subject: [Python-Dev] What will happen to cycle GC in the 2.0 final ?
In-Reply-To: <39E37FCC.9925555A@lemburg.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCAEKNHKAA.tim_one@email.msn.com>

[M.-A. Lemburg]
> It was mentioned early in the beta phase that cycle GC would be
> enabled only during the beta cycle and disabled in the final.
>
> Is this still true ?

No, and it probably never was <wink>:  the intent of enabling gc during the
betas was to determine *whether* to enable it for the final release.  The
beta experience with gc was very good:  a few subtle problems were
uncovered, and Neil fixed them quickly.  It should probably get a ton of
performance testing that never happened, but then so should have all of
2.0 -- no particular reason to pick on gc alone for that.

full-cycle-ahead-ly y'rs  - tim





From fdrake at beopen.com  Tue Oct 10 23:13:47 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Tue, 10 Oct 2000 17:13:47 -0400 (EDT)
Subject: [Python-Dev] -Wall output for the Python 2.0c1
In-Reply-To: <39E37E0A.90176759@lemburg.com>
References: <39E37E0A.90176759@lemburg.com>
Message-ID: <14819.34443.951260.635718@cj42289-a.reston1.va.home.com>

M.-A. Lemburg writes:
 > ceval.c: In function `eval_code2':
 > ceval.c:345: warning: `v' might be used uninitialized in this function
 > ceval.c:346: warning: `w' might be used uninitialized in this function
 > ceval.c:347: warning: `u' might be used uninitialized in this function
 > ceval.c:348: warning: `t' might be used uninitialized in this function

  These would be a real tedium to fix, and I'm not convinced the loss
of clarity is worth it.  From looking at the code in the DUP_TOPX
code, I'm led to think that the compiler just isn't smart enough (it
should figure out that oparg won't change before the second case
statement, and figure it out more carefully.  I'll bet *that* would
remove these warnings and still right in all cases.

 > errors.c: In function `PyErr_Format':
 > errors.c:409: warning: value computed is not used
 > errors.c:415: warning: value computed is not used

  Fixed.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From guido at python.org  Wed Oct 11 01:16:42 2000
From: guido at python.org (Guido van Rossum)
Date: Tue, 10 Oct 2000 18:16:42 -0500
Subject: [Python-Dev] pythonlabs.com website down -- 2.0c1 still available!
Message-ID: <200010102316.SAA20071@cj20424-a.reston1.va.home.com>

We're experiencing a serious problem with the pythonlabs.com website.
Unfortunately the site is down with no estimated time for when it will
be back up.  Our bestest brains are working on the problem!

In the mean time, the Python 2.0c1 source tree can be downloaded from
this address:

    http://www.beopen.com/products/python2.0/BeOpen-Python-2.0c1.tar.gz

The Windows installer is here:

    http://www.beopen.com/products/python2.0/BeOpen-Python-2.0c1.exe

And the 2.0c1 documentation is still here (on-line browseable and
downloadable):

    http://www.python.org/doc/2.0c1/

If the outage lasts for more than a day, we'll find another place to
hold the full distribution.

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



From tim_one at email.msn.com  Wed Oct 11 00:47:19 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Tue, 10 Oct 2000 18:47:19 -0400
Subject: [Python-Dev] -Wall output for the Python 2.0c1
In-Reply-To: <14819.34443.951260.635718@cj42289-a.reston1.va.home.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCMELAHKAA.tim_one@email.msn.com>

[MAL]
> ceval.c: In function `eval_code2':
> ceval.c:345: warning: `v' might be used uninitialized in this function
> ceval.c:346: warning: `w' might be used uninitialized in this function
> ceval.c:347: warning: `u' might be used uninitialized in this function
> ceval.c:348: warning: `t' might be used uninitialized in this function

[Fred]
>   These would be a real tedium to fix, and I'm not convinced the loss
> of clarity is worth it.

I'll take this one.  It looks easy to fix, and to my eye doing *everything*
needed for oparg == 5 in a single block (ditto for 4, 3, 2, 1 in their own
blocks) would be much clearer than the current distributed trickiness
(faster, too -- the code now is branching more than computing).

> From looking at the code in the DUP_TOPX code, I'm led to think that
> the compiler just isn't smart enough (it should figure out that oparg
> won't change before the second case statement, and figure it out more
> carefully.  I'll bet *that* would remove these warnings and still right
> in all cases.

I agree, except that it wasn't trivial for *me* to decide the compiler was
being stupid.  Code that's obviously correct is better than code that's not
obviously wrong.

>> errors.c: In function `PyErr_Format':
>> errors.c:409: warning: value computed is not used
>> errors.c:415: warning: value computed is not used

Thanks!

>   Fixed.

Thanks!





From thomas at xs4all.net  Wed Oct 11 00:49:37 2000
From: thomas at xs4all.net (Thomas Wouters)
Date: Wed, 11 Oct 2000 00:49:37 +0200
Subject: [Python-Dev] -Wall output for the Python 2.0c1
In-Reply-To: <14819.34443.951260.635718@cj42289-a.reston1.va.home.com>; from fdrake@beopen.com on Tue, Oct 10, 2000 at 05:13:47PM -0400
References: <39E37E0A.90176759@lemburg.com> <14819.34443.951260.635718@cj42289-a.reston1.va.home.com>
Message-ID: <20001011004937.Q12812@xs4all.nl>

On Tue, Oct 10, 2000 at 05:13:47PM -0400, Fred L. Drake, Jr. wrote:

> M.-A. Lemburg writes:
>  > ceval.c: In function `eval_code2':
>  > ceval.c:345: warning: `v' might be used uninitialized in this function
>  > ceval.c:346: warning: `w' might be used uninitialized in this function
>  > ceval.c:347: warning: `u' might be used uninitialized in this function
>  > ceval.c:348: warning: `t' might be used uninitialized in this function

>   These would be a real tedium to fix, and I'm not convinced the loss
> of clarity is worth it.  From looking at the code in the DUP_TOPX
> code, I'm led to think that the compiler just isn't smart enough (it
> should figure out that oparg won't change before the second case
> statement, and figure it out more carefully.  I'll bet *that* would
> remove these warnings and still right in all cases.

Well, I'm certain I compiled my code (which included DUP_TOPX) with -Wall
sometime before, and I didn't get those warnings then. Probably depends on
the version of gcc. As a colleague of mine would say, "insert clue" (into
gcc, that is ;)

-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!



From guido at python.org  Wed Oct 11 01:57:38 2000
From: guido at python.org (Guido van Rossum)
Date: Tue, 10 Oct 2000 18:57:38 -0500
Subject: [Python-Dev] Re: pythonlabs.com website down -- 2.0c1 still available!
In-Reply-To: Your message of "Tue, 10 Oct 2000 18:16:42 EST."
             <200010102316.SAA20071@cj20424-a.reston1.va.home.com> 
References: <200010102316.SAA20071@cj20424-a.reston1.va.home.com> 
Message-ID: <200010102357.SAA20163@cj20424-a.reston1.va.home.com>

I wrote:
> We're experiencing a serious problem with the pythonlabs.com website.
> Unfortunately the site is down with no estimated time for when it will
> be back up.  Our bestest brains are working on the problem!

With the help of Digital Creations' bestest brain, Jim Fulton, the
site is back up in record time.  We'll try not to break it again, Jim!
And thanks to Digital Creations for helping us out on such a short
notice.

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



From fdrake at beopen.com  Wed Oct 11 02:57:11 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Tue, 10 Oct 2000 20:57:11 -0400 (EDT)
Subject: [Python-Dev] -Wall output for the Python 2.0c1
In-Reply-To: <20001011004937.Q12812@xs4all.nl>
References: <39E37E0A.90176759@lemburg.com>
	<14819.34443.951260.635718@cj42289-a.reston1.va.home.com>
	<20001011004937.Q12812@xs4all.nl>
Message-ID: <14819.47847.268859.42306@cj42289-a.reston1.va.home.com>

Thomas Wouters writes:
 > Well, I'm certain I compiled my code (which included DUP_TOPX) with -Wall
 > sometime before, and I didn't get those warnings then. Probably depends on
 > the version of gcc. As a colleague of mine would say, "insert clue" (into
 > gcc, that is ;)

  This is very reasonable.  I don't think we'll give you too many
demerits for this.  ;)


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From tim_one at email.msn.com  Wed Oct 11 06:40:41 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Wed, 11 Oct 2000 00:40:41 -0400
Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison)
In-Reply-To: <slrn8u73ug.8jj.hzhu@rock.localdomain>
Message-ID: <LNBBLJKPBEHFEDALKOLCKELGHKAA.tim_one@email.msn.com>

We need a glibc expert!  Anyone qualify?

[Huaiyu Zhu]
> ...
> This is very likely to be a 2.0 bug.

Or a 1.5.2 bug.  I have to keep saying this stuff is a platform-dependent
crap shoot, because it is (I too prefer that Python underflow silently by
default, though).

> Just to make sure, I have used freshly downloaded source code of
> both 1.5.2 and 2.0b2, then

> ./configure
> make
> ./python
>
> from math import *
> exp(-746)
>
> I got 0.0 from 1.5.2 but OverflowError: math range error from 2.0b2.
>
> The file mathmodule.c has quite some differences between the two versions,
> mostly related to the ANSIfication.  I'm not sure where the problem is.

It's not in mathmodule.c.

> I haven't tried the 2.0c1 yet, as the site is not available.  Can
> other Unix users confirm this behavior?

I went over to Guido's and forced him to try it.  He sees the same behavior:
after building 1.5.2 and some flavor of 2.0 w/ the same gcc and libraries,
1.5.2 Python silently returns 0 and (some flavor of) 2.0 raises
OverflowError.

But there is no code in Python that accounts for the difference.  Running it
under the debugger, the platform exp leaves errno at 0 under 1.5.2 but sets
errno to ERANGE (34) under 2.0.  Since the platform exp was the only
conceivable cause for this difference, it's not surprising that the debugger
confirmed that the platform exp is in fact the cause.

So the remaining question is why the same exp from the same library has
different errno behavior depending on which version of Python it's called
from.  *That* one we couldn't answer, after a fruitless time digging thru
the Byzantine glibc source code trying to reverse engineer it.  Their exp
*can* display different error behavior at runtime depending on several
obscure things, but they're too obscure to relate back clearly to anything
Python is doing.

The 2.0 behavior (set errno to ERANGE on exp underflow) appears to be what
the glibc exp author believes POSIX mandates, and is one of their exp's
possible runtime behaviors, and your own little C program (which you posted
earlier) suggests that's the default behavior under gcc + glibc.  So
presumably 1.5.2 config was such as to inhibit the default behavior.
However, nobody changed this on purpose, so it smells like an unintended
side effect of some other (currently unknown) config change.

I don't know what to do next.  I can't pursue it myself, and you've seen
from the lack of replies to your posts that I'm the only who'll even listen
to you <wink>.  Guido suggests that one big change in 2.0 is that we're
including a lot more std headers than we used to.  It could well be that one
of those #defines some God-forsaken preprocessor symbol one of whose five
meanings (documented or not) is "use POSIX-conformant libm error reporting",
but which someone #include'd in 2.0 to make (who knows?) sockets work right
on some other flavor of Unix.  Don't know.  Unix config is a mess, and so is
glibc.  Best hope now is for someone intimately familiar with glibc
internals to jump in and own this.

staring-at-the-python-source-remains-pointless-for-this-one-ly y'rs  - tim





From huaiyu_zhu at yahoo.com  Wed Oct 11 10:12:37 2000
From: huaiyu_zhu at yahoo.com (Huaiyu Zhu)
Date: Wed, 11 Oct 2000 01:12:37 -0700 (PDT)
Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich
 comparison)
In-Reply-To: <LNBBLJKPBEHFEDALKOLCKELGHKAA.tim_one@email.msn.com>
Message-ID: <Pine.LNX.4.10.10010110044370.25593-100000@rock.localdomain>

[Tim Peters]

> We need a glibc expert!  Anyone qualify?

If there is none here, maybe someone cares to ask in some gcc or gnu news
groups?

> The 2.0 behavior (set errno to ERANGE on exp underflow) appears to be what
> the glibc exp author believes POSIX mandates, and is one of their exp's
> possible runtime behaviors, and your own little C program (which you posted
> earlier) suggests that's the default behavior under gcc + glibc.  So
> presumably 1.5.2 config was such as to inhibit the default behavior.
> However, nobody changed this on purpose, so it smells like an unintended
> side effect of some other (currently unknown) config change.

So can we set a flag to explicitly discount ERANGE?  There are only 19 lines
in the source code that contain ERANGE, and 8 lines containing math_error.
All the latter are in Modules/{c,}mathmodule.c.  Could we just add an ifdef
IEEE754 on these 8 lines?  This would go a long way to aleviate this problem
before we find a perfect solution, if there is one.

> I don't know what to do next.  I can't pursue it myself, and you've seen
> from the lack of replies to your posts that I'm the only who'll even listen
> to you <wink>.  Guido suggests that one big change in 2.0 is that we're
> including a lot more std headers than we used to.  It could well be that one
> of those #defines some God-forsaken preprocessor symbol one of whose five
> meanings (documented or not) is "use POSIX-conformant libm error reporting",
> but which someone #include'd in 2.0 to make (who knows?) sockets work right
> on some other flavor of Unix.  Don't know.  Unix config is a mess, and so is
> glibc.  Best hope now is for someone intimately familiar with glibc
> internals to jump in and own this.

I'm not interested in where this comes from - the only thing that matters is
that it worked in 1.5.2 and breaks in 2.0.  Whether the 1.5.2 behavior was
intended or not, it's not a bug.  The 2.0 behavior is a bug.  If Posix
conflicts with IEEE floating point arithmetic, then confirming to Posix in
this regard is a bug.

I would suggest the next thing to do is to introduce an IEEE754 flag and let
those who do not like it to voice their opinions.  Since this is the same
behavior as 1.5.2 I doubt any running code would be broken by this.

Huaiyu




From thomas at xs4all.net  Wed Oct 11 10:26:14 2000
From: thomas at xs4all.net (Thomas Wouters)
Date: Wed, 11 Oct 2000 10:26:14 +0200
Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison)
In-Reply-To: <LNBBLJKPBEHFEDALKOLCKELGHKAA.tim_one@email.msn.com>; from tim_one@email.msn.com on Wed, Oct 11, 2000 at 12:40:41AM -0400
References: <slrn8u73ug.8jj.hzhu@rock.localdomain> <LNBBLJKPBEHFEDALKOLCKELGHKAA.tim_one@email.msn.com>
Message-ID: <20001011102614.R12812@xs4all.nl>

On Wed, Oct 11, 2000 at 12:40:41AM -0400, Tim Peters wrote:
> We need a glibc expert!  Anyone qualify?

No, at least not me ;)

> So the remaining question is why the same exp from the same library has
> different errno behavior depending on which version of Python it's called
> from.  *That* one we couldn't answer, after a fruitless time digging thru
> the Byzantine glibc source code trying to reverse engineer it.  Their exp
> *can* display different error behavior at runtime depending on several
> obscure things, but they're too obscure to relate back clearly to anything
> Python is doing.

Well, I've seen & heard about compilers doing slightly different things
depending on ANSI or K&R style C, so perhaps the presence of ANSI C
definitions triggered this. I sincerely doubt it, though, but you never
know, and it's fairly easy to test.

> I don't know what to do next.  I can't pursue it myself, and you've seen
> from the lack of replies to your posts that I'm the only who'll even listen
> to you <wink>.  Guido suggests that one big change in 2.0 is that we're
> including a lot more std headers than we used to.  It could well be that one
> of those #defines some God-forsaken preprocessor symbol one of whose five
> meanings (documented or not) is "use POSIX-conformant libm error reporting",
> but which someone #include'd in 2.0 to make (who knows?) sockets work right
> on some other flavor of Unix.  Don't know.  Unix config is a mess, and so is
> glibc.  Best hope now is for someone intimately familiar with glibc
> internals to jump in and own this.

Actually, there was some activity to define the right combination of
_GNU_SOURCE, _POSIX_SOURCE, _XOPEN_SOURCE, _BSD_SOURCE, et al, but I'm not
sure what the end result was. If any #define changes the behaviour of glibc,
these would definately be it ! A simple test might be to compile 1.5.2 with
the config.h from 2.0, and manually add whatever _*_SOURCE defines aren't in
1.5.2. (They reside in Python.h and config.h, currently.) I'll see if I can
reproduce it on the glibc almost-2.2 (that is, glibc-2.1.94) systems here,
and do some of the above tests.

Computers-suck-ly y'rs,
-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!



From thomas at xs4all.net  Wed Oct 11 10:31:49 2000
From: thomas at xs4all.net (Thomas Wouters)
Date: Wed, 11 Oct 2000 10:31:49 +0200
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Python ceval.c,2.207,2.208
In-Reply-To: <200010110704.AAA12861@slayer.i.sourceforge.net>; from tim_one@users.sourceforge.net on Wed, Oct 11, 2000 at 12:04:52AM -0700
References: <200010110704.AAA12861@slayer.i.sourceforge.net>
Message-ID: <20001011103148.S12812@xs4all.nl>

On Wed, Oct 11, 2000 at 12:04:52AM -0700, Tim Peters wrote:

>   			default:
>   				fprintf(stderr, "Invalid argument to DUP_TOPX: %d!\n", oparg);

Hm, this fprintf is stray debugging code, added because I wasn't sure that a
SystemError wouldn't crash the interpreter, given that the stack is utterly
fu*d up at this point and we don't know what the compiler thinks is the
stack size or block size here. (The snippet doesn't show it, but it also
raises a SystemError.) Is it okay if I remove/comment this fprintf() before
2.0 final ?

(At least it didn't say "awoogah, stray debugging code detected, this
machine will self-destruct in 10 seconds" :-)

Another-day-another-demerit<wink>-ly y'rs,
-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!



From tim_one at email.msn.com  Wed Oct 11 11:52:59 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Wed, 11 Oct 2000 05:52:59 -0400
Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison)
In-Reply-To: <Pine.LNX.4.10.10010110044370.25593-100000@rock.localdomain>
Message-ID: <LNBBLJKPBEHFEDALKOLCOELMHKAA.tim_one@email.msn.com>

[Huaiyu Zhu]
> ...
> So can we set a flag to explicitly discount ERANGE?  There are
> only 19 lines in the source code that contain ERANGE, and 8 lines
> containing math_error.
> All the latter are in Modules/{c,}mathmodule.c.  Could we just
> add an ifdef IEEE754 on these 8 lines?  This would go a long way to
> aleviate this problem before we find a perfect solution, if there
> is one.

That would stop the exception on exp() underflow, which is what you're
concerned about.  It would also stop exceptions on exp() overflow, and on
underflow and overflow for all other math functions too.  I doubt Guido will
ever let Python ignore overflow by default, #ifdef'ed or not.  A semantic
change that jarring certainly won't happen for 2.0 (which is just a week
away).

> ...
> I'm not interested in where this comes from - the only thing that
> matters is that it worked in 1.5.2 and breaks in 2.0.

The behavior of underflowing exp() is hardly the only thing that matters,
although it's becoming clear it may be the only thing you care about <0.9
wink>.  I would like to change that too for 2.0, but give a thought to the
other consequences.  If some change to the Python config screwed up
exp(-1000) for you, what else is going wrong?  You're not going to get an
answer to that until we know exactly "where this comes from".

> Whether the 1.5.2 behavior was> intended or not, it's not a bug.  The
> 2.0 behavior is a bug.  If Posix conflicts with IEEE floating point
> arithmetic, then confirming to Posix in this regard is a bug.

POSIX doesn't conflict w/ 754 here, as 754 is silent on the matter of errno,
as is POSIX on 754 issues.  It was Python's decision (not POSIX's) to raise
an exception when errno gets set.  Python wasn't designed to support 754,
and makes no claim to support any part of it, so conformance to 754 may be
presented as a feature request, but trying to beat Python over the head with
it won't work:  there's no bug here, in the strong sense that no documented
(or even intended!) behavior has changed.  What happened is that one
platform accident got changed to a different platform accident.  You
certainly get sympathy for that, but not enough to buy radical last-minute
changes.

> I would suggest the next thing to do is to introduce an IEEE754
> flag and let those who do not like it to voice their opinions.

Nothing like that will happen without a PEP first.  I would like to see
*serious* 754 support myself, but that depends too on many platform experts
contributing real work (if everyone ran WinTel, I could do it myself
<wink>).

> Since this is the same behavior as 1.5.2 I doubt any running code would be
> broken by this.

Ignoring ERANGE entirely is not at all the same behavior as 1.5.2, and
current code certainly relies on detecting overflows in math functions.  It
would also break code on platforms that were setting errno to ERANGE all
along on underflow (as POSIX appears to require, and ANSI C doesn't appear
to forbid; I don't know of such a platform for sure offhand, but to judge
from their manpages, HPUX looks like one).

In no case can you expect to see overflow ignored in 2.0.

I want to know where this comes from, so we have *some* handle on what other
surprises may be lurking.

If no progress is made on determining the true cause over the next few days,
I'll hack mathmodule.c to ignore ERANGE in the specific case the result
returned is a zero (which would "fix" your exp underflow problem without
stopping overflow detection).  Since this will break code on any platform
where errno was set to ERANGE on underflow in 1.5.2, I'll need to have a
long discussion w/ Guido first.  I *believe* that much is actually sellable
for 2.0, because it moves Python in a direction I know he likes regardless
of whether he ever becomes a 754 True Believer.

like-herding-cats-indeed-ly y'rs  - tim





From tim_one at email.msn.com  Wed Oct 11 12:02:05 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Wed, 11 Oct 2000 06:02:05 -0400
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Python ceval.c,2.207,2.208
In-Reply-To: <20001011103148.S12812@xs4all.nl>
Message-ID: <LNBBLJKPBEHFEDALKOLCMELNHKAA.tim_one@email.msn.com>

> >   			default:
> >   				fprintf(stderr, "Invalid argument
> to DUP_TOPX: %d!\n", oparg);

[Thomas Wouters]
> Hm, this fprintf is stray debugging code, added because I wasn't
> sure that a SystemError wouldn't crash the interpreter, given that the
> stack is utterly fu*d up at this point and we don't know what the
> compiler thinks is the stack size or block size here. (The snippet
> doesn't show it, but it also raises a SystemError.) Is it okay if I
> remove/comment this fprintf() before 2.0 final ?

Suggest replacing it with:

    assert(!"Invalid argument to DUP_TOPX");

Then there's no cost in release mode, but we have a useful check in debug
mode.  ("assert(!string)" is a handy C debugging idiom more people should
know about!  It's semantically the same as assert(0) (i.e. will fail if ever
reached), but unlike using a comment, using a string gets a useful msg
displayed if it ever does fail).

> (At least it didn't say "awoogah, stray debugging code detected, this
> machine will self-destruct in 10 seconds" :-)

Beats "Unto the root this day a brother is born" <wink -- a famous "can't
happen" msg that, of course, got displayed, many years ago in a different
project -- except the original was in Latin!>.

> Another-day-another-demerit<wink>-ly y'rs,

That's a funny thing about working on Python:  collect 5 demerits and you
can exchange them for 1 brownie point!  If you're not leaving crap behind,
you're not eating enough Python code.

continuous-recoding-is-as-effective-as-it-is-rare-ly y'rs  - tim





From guido at python.org  Wed Oct 11 16:39:06 2000
From: guido at python.org (Guido van Rossum)
Date: Wed, 11 Oct 2000 09:39:06 -0500
Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison)
In-Reply-To: Your message of "Wed, 11 Oct 2000 05:52:59 -0400."
             <LNBBLJKPBEHFEDALKOLCOELMHKAA.tim_one@email.msn.com> 
References: <LNBBLJKPBEHFEDALKOLCOELMHKAA.tim_one@email.msn.com> 
Message-ID: <200010111439.JAA02783@cj20424-a.reston1.va.home.com>

Incidentally, math.exp(800) returns inf in 1.5, and raises
OverflowError in 2.0.  So at least it's consistent.

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



From moshez at math.huji.ac.il  Wed Oct 11 14:38:21 2000
From: moshez at math.huji.ac.il (Moshe Zadka)
Date: Wed, 11 Oct 2000 15:38:21 +0300 (IDT)
Subject: [Python-Dev] OS Dependant Bugs
Message-ID: <Pine.GSO.4.10.10010111534170.7162-100000@sundial>

Many of the sourceforge bugs are platform dependant. Unfortunately, it is
impossible, from the main bugs page, to see which are platform dependant,
and which platform the occur on.

I suggest that, until SF supports it properly, each bug report we enter
will have an optional [Platform] in front, if it seems to be platform
dependant. 

Any opinions? Anyone thinks submitting an SF request to add this field
is foolish?

--
Moshe Zadka <moshez at math.huji.ac.il>
There is no IGLU cabal.
http://advogato.org/person/moshez




From guido at python.org  Wed Oct 11 16:41:47 2000
From: guido at python.org (Guido van Rossum)
Date: Wed, 11 Oct 2000 09:41:47 -0500
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Python ceval.c,2.207,2.208
In-Reply-To: Your message of "Wed, 11 Oct 2000 06:02:05 -0400."
             <LNBBLJKPBEHFEDALKOLCMELNHKAA.tim_one@email.msn.com> 
References: <LNBBLJKPBEHFEDALKOLCMELNHKAA.tim_one@email.msn.com> 
Message-ID: <200010111441.JAA02813@cj20424-a.reston1.va.home.com>

> Suggest replacing it with:
> 
>     assert(!"Invalid argument to DUP_TOPX");

Actually, I would recommend

	Py_FatalError("Invalid argument to DUP_TOPX")

It's not quite the same since it also triggers in release mode.  If,
as Thomas says, this should never happen and can only be caused by
garbled bytecode, a fatal error is proper rather than a SystemError.

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



From moshez at math.huji.ac.il  Wed Oct 11 14:41:27 2000
From: moshez at math.huji.ac.il (Moshe Zadka)
Date: Wed, 11 Oct 2000 15:41:27 +0300 (IDT)
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Python
 ceval.c,2.207,2.208
In-Reply-To: <200010111441.JAA02813@cj20424-a.reston1.va.home.com>
Message-ID: <Pine.GSO.4.10.10010111539440.7162-100000@sundial>

On Wed, 11 Oct 2000, Guido van Rossum wrote:

> 	Py_FatalError("Invalid argument to DUP_TOPX")
> 
> It's not quite the same since it also triggers in release mode.  If,
> as Thomas says, this should never happen and can only be caused by
> garbled bytecode, a fatal error is proper rather than a SystemError.

Can't user Python code, fiddling around with bytecode, produce garbled
bytecode? In that case, it seems  even better to raise an exception.

Unless I misunderstand the discussion completely.

jumping-to-discussions-in-the-middle-ly y'rs, Z.

--
Moshe Zadka <moshez at math.huji.ac.il>
There is no IGLU cabal.
http://advogato.org/person/moshez




From fdrake at beopen.com  Wed Oct 11 15:42:57 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Wed, 11 Oct 2000 09:42:57 -0400 (EDT)
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Python ceval.c,2.207,2.208
In-Reply-To: <200010110704.AAA12861@slayer.i.sourceforge.net>
References: <200010110704.AAA12861@slayer.i.sourceforge.net>
Message-ID: <14820.28257.836222.958973@cj42289-a.reston1.va.home.com>

Tim Peters writes:
 > Update of /cvsroot/python/python/dist/src/Python
 > Attempt to fix bogus gcc -Wall warnings reported by Marc-Andre Lemburg,
 > by making the DUP_TOPX code utterly straightforward.  This also gets rid
 > of all normal-case internal DUP_TOPX if/branches, and allows replacing one
 > POP() with TOP() in each case, so is a good idea regardless.

Tim,
  There's still one left:

gcc -Wall -O2 -Wstrict-prototypes -I../../Python/../Include -I.. -DHAVE_CONFIG_H   -c -o ceval.o ../../Python/ceval.c
../../Python/ceval.c: In function `eval_code2':
../../Python/ceval.c:346: warning: `w' might be used uninitialized in
this function

  Cruising through this code, it looks like the problem might be in
the PRINT_NEWLINE case:

		case PRINT_NEWLINE:
			if (stream == NULL || stream == Py_None) {
				w = PySys_GetObject("stdout");
				if (w == NULL)
					PyErr_SetString(PyExc_RuntimeError,
							"lost sys.stdout");
			}
			if (w != NULL) {
	/* If PRINT_NEWLINE is the opcode, w might not be initialized
         * here (I think), since I don't see it initialize before the
         * switch.  Since we can't initialize it to NULL with the case
         * (doing so would break the PRINT_NEWLINE_TO case), it would
         * have to be initialized before the main loop is entered.
         */
				err = PyFile_WriteString("\n", w);
				if (err == 0)
					PyFile_SoftSpace(w, 0);
			}
			Py_XDECREF(stream);
			stream = NULL;
			break;

  Ok.... yep, initializing that seems to work.
  I'll check in the fix for this one after I've run the regression test.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From guido at python.org  Wed Oct 11 16:54:14 2000
From: guido at python.org (Guido van Rossum)
Date: Wed, 11 Oct 2000 09:54:14 -0500
Subject: [Python-Dev] OS Dependant Bugs
In-Reply-To: Your message of "Wed, 11 Oct 2000 15:38:21 +0300."
             <Pine.GSO.4.10.10010111534170.7162-100000@sundial> 
References: <Pine.GSO.4.10.10010111534170.7162-100000@sundial> 
Message-ID: <200010111454.JAA03006@cj20424-a.reston1.va.home.com>

> Many of the sourceforge bugs are platform dependant. Unfortunately, it is
> impossible, from the main bugs page, to see which are platform dependant,
> and which platform the occur on.
> 
> I suggest that, until SF supports it properly, each bug report we enter
> will have an optional [Platform] in front, if it seems to be platform
> dependant. 
> 
> Any opinions? Anyone thinks submitting an SF request to add this field
> is foolish?

I think it's sufficient (actually better) if the platform name is
mentioned in the summary.  Note that you can edit the summary of
existing bug reports.

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




From guido at python.org  Wed Oct 11 16:54:54 2000
From: guido at python.org (Guido van Rossum)
Date: Wed, 11 Oct 2000 09:54:54 -0500
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Python ceval.c,2.207,2.208
In-Reply-To: Your message of "Wed, 11 Oct 2000 15:41:27 +0300."
             <Pine.GSO.4.10.10010111539440.7162-100000@sundial> 
References: <Pine.GSO.4.10.10010111539440.7162-100000@sundial> 
Message-ID: <200010111454.JAA03020@cj20424-a.reston1.va.home.com>

> Can't user Python code, fiddling around with bytecode, produce garbled
> bytecode? In that case, it seems  even better to raise an exception.

Yes, they can produce garbled bytecode, and if that is detected, it's
not safe to proceed.  So a fatal error is the right thing.

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



From moshez at math.huji.ac.il  Wed Oct 11 14:56:17 2000
From: moshez at math.huji.ac.il (Moshe Zadka)
Date: Wed, 11 Oct 2000 15:56:17 +0300 (IDT)
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Python
 ceval.c,2.207,2.208
In-Reply-To: <200010111454.JAA03020@cj20424-a.reston1.va.home.com>
Message-ID: <Pine.GSO.4.10.10010111555020.7162-100000@sundial>

On Wed, 11 Oct 2000, Guido van Rossum wrote:

> > Can't user Python code, fiddling around with bytecode, produce garbled
> > bytecode? In that case, it seems  even better to raise an exception.
> 
> Yes, they can produce garbled bytecode, and if that is detected, it's
> not safe to proceed.  So a fatal error is the right thing.

The problem with letting Python code cause fatal errors is that it makes
restricted execution much more difficult. Well, something to think about
for 2.1...

--
Moshe Zadka <moshez at math.huji.ac.il>
There is no IGLU cabal.
http://advogato.org/person/moshez




From akuchlin at mems-exchange.org  Wed Oct 11 15:56:50 2000
From: akuchlin at mems-exchange.org (Andrew Kuchling)
Date: Wed, 11 Oct 2000 09:56:50 -0400
Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison)
In-Reply-To: <20001011102614.R12812@xs4all.nl>; from thomas@xs4all.net on Wed, Oct 11, 2000 at 10:26:14AM +0200
References: <slrn8u73ug.8jj.hzhu@rock.localdomain> <LNBBLJKPBEHFEDALKOLCKELGHKAA.tim_one@email.msn.com> <20001011102614.R12812@xs4all.nl>
Message-ID: <20001011095650.A17931@kronos.cnri.reston.va.us>

On Wed, Oct 11, 2000 at 10:26:14AM +0200, Thomas Wouters wrote:
>Actually, there was some activity to define the right combination of
>_GNU_SOURCE, _POSIX_SOURCE, _XOPEN_SOURCE, _BSD_SOURCE, et al, but I'm not
>sure what the end result was. If any #define changes the behaviour of glibc,
>these would definately be it ! A simple test might be to compile 1.5.2 with

That seems the likely cause.  Another faint possibility might be
threading, since 2.0 automatically uses threads but 1.5.2 needs to
have them enabled. (Perhaps Tim remembered this and supplied
--with-thread to the 1.5.2 configure script.)

--amk




From guido at python.org  Wed Oct 11 17:03:00 2000
From: guido at python.org (Guido van Rossum)
Date: Wed, 11 Oct 2000 10:03:00 -0500
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Python ceval.c,2.207,2.208
In-Reply-To: Your message of "Wed, 11 Oct 2000 15:56:17 +0300."
             <Pine.GSO.4.10.10010111555020.7162-100000@sundial> 
References: <Pine.GSO.4.10.10010111555020.7162-100000@sundial> 
Message-ID: <200010111503.KAA03123@cj20424-a.reston1.va.home.com>

> > > Can't user Python code, fiddling around with bytecode, produce garbled
> > > bytecode? In that case, it seems  even better to raise an exception.
> > 
> > Yes, they can produce garbled bytecode, and if that is detected, it's
> > not safe to proceed.  So a fatal error is the right thing.
> 
> The problem with letting Python code cause fatal errors is that it makes
> restricted execution much more difficult. Well, something to think about
> for 2.1...

Huh?  In restricted execution you shouldn't be allowed to mess with
bytecode!

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



From guido at python.org  Wed Oct 11 17:25:32 2000
From: guido at python.org (Guido van Rossum)
Date: Wed, 11 Oct 2000 10:25:32 -0500
Subject: [Python-Dev] Re: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison)
In-Reply-To: Your message of "Wed, 11 Oct 2000 09:56:50 -0400."
             <20001011095650.A17931@kronos.cnri.reston.va.us> 
References: <slrn8u73ug.8jj.hzhu@rock.localdomain> <LNBBLJKPBEHFEDALKOLCKELGHKAA.tim_one@email.msn.com> <20001011102614.R12812@xs4all.nl>  
            <20001011095650.A17931@kronos.cnri.reston.va.us> 
Message-ID: <200010111525.KAA03324@cj20424-a.reston1.va.home.com>

Bingo!

1.5.2 links with -lieee while 2.0 doesn't.  Removing -lieee from the
1.5.2 link line makes is raise OverflowError too.  Adding it to the
2.0 link line makes it return 0.0 for exp(-1000) and inf for
exp(1000).

Next question: what changed in the configure script, and why?

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



From thomas at xs4all.net  Wed Oct 11 16:24:37 2000
From: thomas at xs4all.net (Thomas Wouters)
Date: Wed, 11 Oct 2000 16:24:37 +0200
Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison)
In-Reply-To: <20001011102614.R12812@xs4all.nl>; from thomas@xs4all.net on Wed, Oct 11, 2000 at 10:26:14AM +0200
References: <slrn8u73ug.8jj.hzhu@rock.localdomain> <LNBBLJKPBEHFEDALKOLCKELGHKAA.tim_one@email.msn.com> <20001011102614.R12812@xs4all.nl>
Message-ID: <20001011162436.T12812@xs4all.nl>

On Wed, Oct 11, 2000 at 10:26:14AM +0200, Thomas Wouters wrote:

[ Py2.0 mathmodule behaves differently when doing math.exp(-1000) and such ]

> Actually, there was some activity to define the right combination of
> _GNU_SOURCE, _POSIX_SOURCE, _XOPEN_SOURCE, _BSD_SOURCE, et al, but I'm not
> sure what the end result was. If any #define changes the behaviour of glibc,
> these would definately be it ! A simple test might be to compile 1.5.2 with
> the config.h from 2.0, and manually add whatever _*_SOURCE defines aren't in
> 1.5.2. (They reside in Python.h and config.h, currently.) I'll see if I can
> reproduce it on the glibc almost-2.2 (that is, glibc-2.1.94) systems here,
> and do some of the above tests.

Well, that was no success. I do see the difference between 1.5.2 and 2.0,
but *damned* if I can figure out where it comes from. It doesn't seem to be
any of the properly placed defines, and it doesn't seem to be the changes in
mathmodule itself. Not autoconf, either. What I did:

old tree (stock Python 1.5.2): math.exp(-1000) returns 0.0
new tree (current CVS): math.exp(-1000) raises OverflowError

(No difference between threads enabled and disabled.)

Use new config.h in old tree: math.exp(-1000) returned 0.0

Add _GNU_SOURCE and _XOPEN_SOURCE definitions (respectively 1 and 500, just
like new Python.h does) to Python.h in old tree: math.exp(-1000) returns 0.0

Copy mathmodule.c and mymath.h from old tree to new tree: math.exp(-1000)
raises OverflowError

Copy new mathmodule.c to old tree (adding an 'include math.h' because the
old Python.h isn't doing that): math.exp(-1000) returns 0.0

Copy config.h and Python.h from new tree to old one (removing the include of
unicodestring.h and codecs.h, and including mymalloc.h rather than pymem.h
to make it compile): math.exp(-1000) returns 0.0

So, as far as I can tell, it's not related to any code in mathmodule.c
itself, nor any defines in config.h or Python.h. mymath.h isn't used either,
as far as I can tell it only contains stuff for broken math stuff on obscure
platforms. Sounds like time for that glibc expert right about now ;-P

-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!



From akuchlin at mems-exchange.org  Wed Oct 11 16:32:23 2000
From: akuchlin at mems-exchange.org (Andrew Kuchling)
Date: Wed, 11 Oct 2000 10:32:23 -0400
Subject: [Python-Dev] Re: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison)
In-Reply-To: <200010111525.KAA03324@cj20424-a.reston1.va.home.com>; from guido@python.org on Wed, Oct 11, 2000 at 10:25:32AM -0500
References: <slrn8u73ug.8jj.hzhu@rock.localdomain> <LNBBLJKPBEHFEDALKOLCKELGHKAA.tim_one@email.msn.com> <20001011102614.R12812@xs4all.nl> <20001011095650.A17931@kronos.cnri.reston.va.us> <200010111525.KAA03324@cj20424-a.reston1.va.home.com>
Message-ID: <20001011103223.C17931@kronos.cnri.reston.va.us>

On Wed, Oct 11, 2000 at 10:25:32AM -0500, Guido van Rossum wrote:
>1.5.2 links with -lieee while 2.0 doesn't.  
>Next question: what changed in the configure script, and why?

The patch from revisions 1.138 to 1.139 of configure.in is:

853c1139,1142
< AC_CHECK_LIB(ieee, __fpu_control)
---
> AC_CHECK_FUNC(__fpu_control,
>   [],
>   [AC_CHECK_LIB(ieee, __fpu_control)
> ])

The check-in comment is "Only link with -lieee when it's necessary".
If it only checks for -lieee when the __fpu_control function is
defined, perhaps the function disappeared in glibc 2.1.

--amk



From thomas at xs4all.net  Wed Oct 11 16:32:45 2000
From: thomas at xs4all.net (Thomas Wouters)
Date: Wed, 11 Oct 2000 16:32:45 +0200
Subject: [Python-Dev] Re: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison)
In-Reply-To: <200010111525.KAA03324@cj20424-a.reston1.va.home.com>; from guido@python.org on Wed, Oct 11, 2000 at 10:25:32AM -0500
References: <slrn8u73ug.8jj.hzhu@rock.localdomain> <LNBBLJKPBEHFEDALKOLCKELGHKAA.tim_one@email.msn.com> <20001011102614.R12812@xs4all.nl> <20001011095650.A17931@kronos.cnri.reston.va.us> <200010111525.KAA03324@cj20424-a.reston1.va.home.com>
Message-ID: <20001011163244.U12812@xs4all.nl>

On Wed, Oct 11, 2000 at 10:25:32AM -0500, Guido van Rossum wrote:

> 1.5.2 links with -lieee while 2.0 doesn't.  Removing -lieee from the
> 1.5.2 link line makes is raise OverflowError too.  Adding it to the
> 2.0 link line makes it return 0.0 for exp(-1000) and inf for
> exp(1000).

Ack, that's the one thing I didn't check: link libraries ;-P

> Next question: what changed in the configure script, and why?

Well, that's easy. 

Old configure.in:

# Linux requires this for correct f.p. operations
AC_CHECK_LIB(ieee, __fpu_control)

New configure.in:

# Linux requires this for correct f.p. operations
AC_CHECK_FUNC(__fpu_control,
  [],
  [AC_CHECK_LIB(ieee, __fpu_control)
])

I remember the patch that did this, on SF. It was titled "don't link with
-lieee if it isn't necessary" or something. Not sure what it would break,
but mayhaps declaring -lieee necessary on glibc systems is the right fix ?

(For the non-autoconf readers among us: the first snippet writes a test
program to see if the function '__fpu_control' exists when linking with
-lieee in addition to $LIBS, and if so, adds -lieee to $LIBS. The second
snippet writes a test program to see if the function '__fpu_control' exists
with the current collection of $LIBS. If it doesn't, it tries it again with
-lieee, and adds -lieee to $LIBS if it finds it then.)

Pesonally, I think the patch should just be reversed... The comment above
the check certainly could be read as 'Linux requires -lieee for correct f.p.
operations', and perhaps that's how it was meant.

-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!



From skip at mojam.com  Wed Oct 11 18:31:48 2000
From: skip at mojam.com (Skip Montanaro)
Date: Wed, 11 Oct 2000 11:31:48 -0500 (CDT)
Subject: [Python-Dev] -Wall output for the Python 2.0c1
In-Reply-To: <LNBBLJKPBEHFEDALKOLCMELAHKAA.tim_one@email.msn.com>
References: <14819.34443.951260.635718@cj42289-a.reston1.va.home.com>
	<LNBBLJKPBEHFEDALKOLCMELAHKAA.tim_one@email.msn.com>
Message-ID: <14820.38388.827883.710489@beluga.mojam.com>

    Tim> I'll take this one.  It looks easy to fix ...

Seems to me like a patch that ought to wait until after 2.0final.  It's
definitely not a show-stopping bug...

Skip



From thomas at xs4all.net  Wed Oct 11 20:04:31 2000
From: thomas at xs4all.net (Thomas Wouters)
Date: Wed, 11 Oct 2000 20:04:31 +0200
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Python ceval.c,2.207,2.208
In-Reply-To: <200010111503.KAA03123@cj20424-a.reston1.va.home.com>; from guido@python.org on Wed, Oct 11, 2000 at 10:03:00AM -0500
References: <Pine.GSO.4.10.10010111555020.7162-100000@sundial> <200010111503.KAA03123@cj20424-a.reston1.va.home.com>
Message-ID: <20001011200431.V12812@xs4all.nl>

On Wed, Oct 11, 2000 at 10:03:00AM -0500, Guido van Rossum wrote:

> > > > Can't user Python code, fiddling around with bytecode, produce garbled
> > > > bytecode? In that case, it seems  even better to raise an exception.

> > > Yes, they can produce garbled bytecode, and if that is detected, it's
> > > not safe to proceed.  So a fatal error is the right thing.

> > The problem with letting Python code cause fatal errors is that it makes
> > restricted execution much more difficult. Well, something to think about
> > for 2.1...

> Huh?  In restricted execution you shouldn't be allowed to mess with
> bytecode!

Well, I can see what Moshe means. You get a code object passed in, say, an
untrusted pickle or some such. You want to execute it, but you don't want it
to ruin your life. Causing the entire program to quit could be considered
'ruining'. On the other hand, if you can hand-tweak bytecode streams in that
degree, you can f** up a lot more. On the one foot, though, most of the
calls to Py_FatalError (as far as I can see) deal with initialization
failures, or structures to which tweaked bytecode would not have access. On
the other foot, it's probably possible to tweak bytecode to *get* access to
those structures, or at least structures that don't like being dereferenced
or DECREF'd. And there's probably more to consider, but I haven't got any
public appendages left, and there might be children listening ;)

All in all, Guido's probably right... If something like this happens, you
don't want to continue. If the argument to DUP_TOPX is something other than
what compile.c generates (between 1 and 5, inclusive, that is) something
strange is going on internally. Better to quit now than delete
c:\command.com by 'accident'. If people can do this to code being run in
restricted environments, they can probably do worse things, too!

Now I just need an OK from Jeremy, as the maitre d', and I'll check it in.

-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!



From guido at python.org  Wed Oct 11 23:19:28 2000
From: guido at python.org (Guido van Rossum)
Date: Wed, 11 Oct 2000 16:19:28 -0500
Subject: [Python-Dev] Re: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison)
In-Reply-To: Your message of "Wed, 11 Oct 2000 16:32:45 +0200."
             <20001011163244.U12812@xs4all.nl> 
References: <slrn8u73ug.8jj.hzhu@rock.localdomain> <LNBBLJKPBEHFEDALKOLCKELGHKAA.tim_one@email.msn.com> <20001011102614.R12812@xs4all.nl> <20001011095650.A17931@kronos.cnri.reston.va.us> <200010111525.KAA03324@cj20424-a.reston1.va.home.com>  
            <20001011163244.U12812@xs4all.nl> 
Message-ID: <200010112119.QAA03651@cj20424-a.reston1.va.home.com>

Thanks for digging deeper into this.

> Pesonally, I think the patch should just be reversed... The comment above
> the check certainly could be read as 'Linux requires -lieee for correct f.p.
> operations', and perhaps that's how it was meant.

No, the configure patch is right.  Tim will check in a change that
treats ERANGE with a return value of 0.0 as underflow (returning 0.0,
not raising OverflowError).

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



From tim_one at email.msn.com  Wed Oct 11 23:02:16 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Wed, 11 Oct 2000 17:02:16 -0400
Subject: [Python-Dev] -Wall output for the Python 2.0c1
In-Reply-To: <14820.38388.827883.710489@beluga.mojam.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCAENEHKAA.tim_one@email.msn.com>

[Tim]
> I'll take this one [wngs putatively due to DUP_TOPX].  It looks easy
> to fix ...

[Skip Montanaro]
> Seems to me like a patch that ought to wait until after 2.0final.  It's
> definitely not a show-stopping bug...

Would have been a more interesting argument had you posted this before the
patch was checked in <wink>.

But wngs are non-negotiable with me anyway.  This example turned out to be a
good one for showing why:  the bogus wngs covered up a legitimate
"uninitialized vrbl" complaint (see Fred's later discovery and following
checkin).  I've simply got zero tolerance for wngs or for failures in the
std test suite.  My view is warped by prior experience, though:  the last 6
years, I worked on projects where the compilers were fiddled to treat
warnings as fatal errors.  So while this may have looked like a harmless
batch of wngs to you, as far as I was concerned Python couldn't even be
compiled anymore <0.7 wink>.

extremism-in-defense-of-simple-best-practice-may-or-may-not-be-
    vice-but-it's-sure-effective-over-the-long-term-ly y'rs  - tim





From skip at mojam.com  Wed Oct 11 23:07:42 2000
From: skip at mojam.com (Skip Montanaro)
Date: Wed, 11 Oct 2000 16:07:42 -0500 (CDT)
Subject: [Python-Dev] -Wall output for the Python 2.0c1
In-Reply-To: <LNBBLJKPBEHFEDALKOLCAENEHKAA.tim_one@email.msn.com>
References: <14820.38388.827883.710489@beluga.mojam.com>
	<LNBBLJKPBEHFEDALKOLCAENEHKAA.tim_one@email.msn.com>
Message-ID: <14820.54942.114086.773609@beluga.mojam.com>

    Tim> [Tim]
    >> I'll take this one [wngs putatively due to DUP_TOPX].  It looks easy
    >> to fix ...

    Tim> [Skip Montanaro]
    >> Seems to me like a patch that ought to wait until after 2.0final.
    >> It's definitely not a show-stopping bug...

    Tim> Would have been a more interesting argument had you posted this
    Tim> before the patch was checked in <wink>.

Agreed, but I posted as soon as I saw it.  Can't help it if I can't keep up
with all the flurry of activity.

    Tim> So while this may have looked like a harmless batch of wngs to you,
    Tim> as far as I was concerned Python couldn't even be compiled anymore
    Tim> <0.7 wink>.

I accept your explanation. ;-)

S



From jack at oratrix.nl  Wed Oct 11 23:10:36 2000
From: jack at oratrix.nl (Jack Jansen)
Date: Wed, 11 Oct 2000 23:10:36 +0200
Subject: [Python-Dev] test_StringIO failing on the Mac
Message-ID: <20001011211041.96D2BE266F@oratrix.oratrix.nl>

I have one remaining problem (at least, as far as I'm aware:-) with
2.0c1 on the Mac: test_StringIO fails.

The reason is that the test_StringIO output file was generated on
Unix, and hence it uses the unix form of string.letters (a-zA-Z),
whereas the Mac version of string.letters has far more values.

As this isn't what the test is about in the first place, shall I fix
the test?
--
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/ ++++



From tim_one at email.msn.com  Wed Oct 11 23:14:17 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Wed, 11 Oct 2000 17:14:17 -0400
Subject: [Python-Dev] test_StringIO failing on the Mac
In-Reply-To: <20001011211041.96D2BE266F@oratrix.oratrix.nl>
Message-ID: <LNBBLJKPBEHFEDALKOLCIENFHKAA.tim_one@email.msn.com>

[Jack Jansen]
> I have one remaining problem (at least, as far as I'm aware:-) with
> 2.0c1 on the Mac: test_StringIO fails.
> 
> The reason is that the test_StringIO output file was generated on
> Unix, and hence it uses the unix form of string.letters (a-zA-Z),
> whereas the Mac version of string.letters has far more values.
> 
> As this isn't what the test is about in the first place, shall I fix
> the test?

+1 from me on making the test portable.





From jeremy at beopen.com  Thu Oct 12 01:06:56 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Wed, 11 Oct 2000 19:06:56 -0400 (EDT)
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Python ceval.c,2.207,2.208
In-Reply-To: <20001011200431.V12812@xs4all.nl>
References: <Pine.GSO.4.10.10010111555020.7162-100000@sundial>
	<200010111503.KAA03123@cj20424-a.reston1.va.home.com>
	<20001011200431.V12812@xs4all.nl>
Message-ID: <14820.62096.15085.749912@bitdiddle.concentric.net>

>>>>> "TW" == Thomas Wouters <thomas at xs4all.net> writes:

  [Moshe:]
  >> > The problem with letting Python code cause fatal errors is that
  >> > it makes restricted execution much more difficult. Well,
  >> > something to think about for 2.1...

  [Guido:]
  >> Huh?  In restricted execution you shouldn't be allowed to mess
  >> with bytecode!

  TW> Well, I can see what Moshe means. You get a code object passed
  TW> in, say, an untrusted pickle or some such. You want to execute
  TW> it, but you don't want it to ruin your life. Causing the entire
  TW> program to quit could be considered 'ruining'. On the other
  TW> hand, if you can hand-tweak bytecode streams in that degree, you
  TW> can f** up a lot more.

Damn straight!  If you're using restricted execution mode and
accepting bytecode objects that weren't produced by a trusted Python
compiler, you're nuts.  I am not aware of any effort made to protect
the Python VM from attack via malicious bytecode.

  TW> Now I just need an OK from Jeremy, as the maitre d', and I'll
  TW> check it in.

Your table is ready.  A checkin message will be accepted as gratuity. 

Jeremy



From jeremy at beopen.com  Thu Oct 12 01:12:15 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Wed, 11 Oct 2000 19:12:15 -0400 (EDT)
Subject: [Python-Dev] Re: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison)
In-Reply-To: <200010112119.QAA03651@cj20424-a.reston1.va.home.com>
References: <slrn8u73ug.8jj.hzhu@rock.localdomain>
	<LNBBLJKPBEHFEDALKOLCKELGHKAA.tim_one@email.msn.com>
	<20001011102614.R12812@xs4all.nl>
	<20001011095650.A17931@kronos.cnri.reston.va.us>
	<200010111525.KAA03324@cj20424-a.reston1.va.home.com>
	<20001011163244.U12812@xs4all.nl>
	<200010112119.QAA03651@cj20424-a.reston1.va.home.com>
Message-ID: <14820.62415.873159.533077@bitdiddle.concentric.net>

I checked in the patch that removed the -lieee link in some cases.  I
don't remember the details off the top of my head, but I can go
digging in the SF patch logs if it's important.  As I recall, someone
reported problems on a platform (HPUX?) where link with ieee caused
problems.  I didn't have access to the platform in question.  So I
applied the patch on a Linux box and ran the regression test; it
reported no errors, so I assumed the patch fixed some other platform
and did mine no harm.

At the moment, I would assume that the patch still helps some other
platform but might not be right on Linux.  On the other hand, it
sounds like Tim has a patch that will cause Linux to do the right
thing.

It's hard to say much about what should or should not happen since
neither the language reference nor the regression tests specifies much
about what should happen with fp.

Jeremy




From thomas at xs4all.net  Thu Oct 12 01:15:21 2000
From: thomas at xs4all.net (Thomas Wouters)
Date: Thu, 12 Oct 2000 01:15:21 +0200
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules dlmodule.c,2.14,2.15
In-Reply-To: <200010112144.OAA20776@slayer.i.sourceforge.net>; from fdrake@users.sourceforge.net on Wed, Oct 11, 2000 at 02:44:05PM -0700
References: <200010112144.OAA20776@slayer.i.sourceforge.net>
Message-ID: <20001012011521.X12812@xs4all.nl>

On Wed, Oct 11, 2000 at 02:44:05PM -0700, Fred L. Drake wrote:
> Update of /cvsroot/python/python/dist/src/Modules
> In directory slayer.i.sourceforge.net:/tmp/cvs-serv20717
> 
> Modified Files:
> 	dlmodule.c 
> Log Message:
> 
> Remove one more gcc -Wall warning.

To note, if gcc didn't inherit at least *some* of C's original philosophy of
'the programmer always knows what [s]he is doing', gcc would yell bloody
murder at this code. The 'func' function pointer is used to point to symbols
loaded from arbitrary shared objects, and the dlmodule has no way of knowing
howmany arguments the function expects, or even if it isn't more than 10
(which would result in the function grabbing garbage off the stack, on most
architectures, I think.) While on the ANSIfication spree, I ran screaming
and hid under my bed after reading this code ;)

Is anyone using the dlmodule anymore ? Is it really useful ? Is this
*really* how loading and calling arbitrary shared objects should be done ? :P

>   {
>   	PyObject *name;
> ! 	long (*func)(long, long, long, long, long,
> !                      long, long, long, long, long);
>   	long alist[10];
>   	long res;

Idle-and-post-2.0-talk-ly y'rs,
-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!



From huaiyu_zhu at yahoo.com  Thu Oct 12 01:33:08 2000
From: huaiyu_zhu at yahoo.com (Huaiyu Zhu)
Date: Wed, 11 Oct 2000 16:33:08 -0700 (PDT)
Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich
 comparison)
In-Reply-To: <LNBBLJKPBEHFEDALKOLCOELMHKAA.tim_one@email.msn.com>
Message-ID: <Pine.LNX.4.10.10010111510270.3131-100000@rocket.knowledgetrack.com>

On the issue of whether Python should ignore over/underflow on IEEE-enabled
platforms: 

[Tim Peters]
> That would stop the exception on exp() underflow, which is what you're
> concerned about.  It would also stop exceptions on exp() overflow, and on
> underflow and overflow for all other math functions too.  I doubt Guido will
> ever let Python ignore overflow by default, #ifdef'ed or not.  A semantic
> change that jarring certainly won't happen for 2.0 (which is just a week
> away).

It can be argued that on IEEE enabled systems the proper thing to do for
overflow is simply return Inf.  Raising exception is WRONG.  See below.

[Guido van Rossum]
> Incidentally, math.exp(800) returns inf in 1.5, and raises
> OverflowError in 2.0.  So at least it's consistent.

That is not consistent at all.  Suppose I'm plotting the curve f(x) where
x include some singular points of f.  In the first case the plot works with
some portion of the curve clipped.  In the second case it bombs.  

[Tim Peters] 
> Nothing like that will happen without a PEP first.  I would like to see
> *serious* 754 support myself, but that depends too on many platform experts
> contributing real work (if everyone ran WinTel, I could do it myself
> <wink>).

[Guido van Rossum]
> Bingo!
> 
> 1.5.2 links with -lieee while 2.0 doesn't.  Removing -lieee from the
> 1.5.2 link line makes is raise OverflowError too.  Adding it to the
> 2.0 link line makes it return 0.0 for exp(-1000) and inf for
> exp(1000).

If using ieee is as simple as setting such a flag, there is no reason at all
not to use it.  Here are some more examples:

Suppose you have done hours of computation on a problem.  Just as you are
about to get the result, you get an exception.  Why?  Because the residual
error is too close to zero.

Suppose you want to plot the curve of Gausian distribution.  Oops, it fails.
Because beyond a certain region the value is near zero.

With these kinds of problems, vectorized numerical calculation becomes
nearly impossible.  How do you work in such an environment?  You have to
wrap every calculation in a try/except structure, and whenever there is an
exception, you have to revert to elementwise operations.  In practice this
simply means Python would not be suitable for numerical work at all.

What about the other way round?  No problem.  It is easy to write functions
like isNaN, isInf, etc.  With these one can raise exceptions in any place
one want.  It is even possible to raise exceptions if a matrix is singular
to a certain precision, etc.

The key point to observe here is that most numerical work involve more than
one element.  Some of them may be out of mahcine bounds but the whole thing
could still be quite meaningful.  Vice versa it is also quite possible that
all elements are within bounds while the whole thing is meaningless.  The
language should never take over or subvert decisions based on numerical
analysis.

[Tim Peters] 
> Ignoring ERANGE entirely is not at all the same behavior as 1.5.2, and
> current code certainly relies on detecting overflows in math functions. 

As Guido observed ERANGE is not generated with ieee, even for overflow.  So
it is the same behavior as 1.5.2.  Besides, no correct numerical code should
depend on exceptions like this unless the machine is incapable of handling
Inf and NaN.

Even in the cases where you do want to detect overflow, it is still wrong to
use exceptions.  Here's an example: x*log(x) approaches 0 as x approaches 0.
If x==0 then log(x)==-Inf but 0*-Inf==NaN, not what one would want.  But
exception is the wrong tool to hangle this, because if x is an array, some
of its element may be zero but other's may not.  The right way to do it is
something like

def entropy(probability):
  p = max(probability, 1e-323)
  return p*log(p)

[Tim Peters]
> In no case can you expect to see overflow ignored in 2.0.

You are proposing a dramatic change from the behavior of 1.5.2.  This looks
like to me to need a PEP and a big debate.  It would break a LOT of
numerical computations.

[Thomas Wouters]
> I remember the patch that did this, on SF. It was titled "don't link with
> -lieee if it isn't necessary" or something. Not sure what it would break,
> but mayhaps declaring -lieee necessary on glibc systems is the right fix ?
>
> (For the non-autoconf readers among us: the first snippet writes a test
> program to see if the function '__fpu_control' exists when linking with
> -lieee in addition to $LIBS, and if so, adds -lieee to $LIBS. The second
> snippet writes a test program to see if the function '__fpu_control'
> exists with the current collection of $LIBS. If it doesn't, it tries it
> again with -lieee,
>
> Pesonally, I think the patch should just be reversed... The comment above
> the check certainly could be read as 'Linux requires -lieee for correct
> f.p. operations', and perhaps that's how it was meant.

The patch as described seems to be based on flawed thinking.  The numbers
Inf and NaN are always necessary.  The -lieee could only be unnecessary if
the behavior is the same as IEEE.  Obviously it isn't.  So I second Thomas's
suggestion. 

[Tim Peters]
> If no progress is made on determining the true cause over the next few days,
> I'll hack mathmodule.c to ignore ERANGE in the specific case the result
> returned is a zero (which would "fix" your exp underflow problem without
> stopping overflow detection).  Since this will break code on any platform
> where errno was set to ERANGE on underflow in 1.5.2, I'll need to have a
> long discussion w/ Guido first.  I *believe* that much is actually sellable
> for 2.0, because it moves Python in a direction I know he likes regardless
> of whether he ever becomes a 754 True Believer.

[Guido van Rossum]
> No, the configure patch is right.  Tim will check in a change that
> treats ERANGE with a return value of 0.0 as underflow (returning 0.0,
> not raising OverflowError).

What is the reason to do this?  It looks like intetionally subverting ieee
even when it is available.  I thought Tim meant that only logistical
problems prevent using ieee.

If you do choose this route, please please please ignore ERANGE entirely,
whether return value is zero or not.

The only possible way that ERANGE could be useful at all is if it could be
set independently for each element of an array, and if it behave as a
warning instead of an exception, ie.  the calculation would continue if it
is not caught.  Well, then, Inf and NaN serve this purpose perfectly.

It is very reasonable to set errno in glibc for this; it is completely
unreasonable to raise an exception in Python, because exceptions cannot be
set to individual elements and they cannot be ignored.


Huaiyu
-- 
Huaiyu Zhu                       hzhu at users.sourceforge.net
Matrix for Python Project        http://MatPy.sourceforge.net 





From pauldubois at home.com  Thu Oct 12 02:04:51 2000
From: pauldubois at home.com (Paul F. Dubois)
Date: Wed, 11 Oct 2000 17:04:51 -0700
Subject: [Python-Dev] RE: [Numpy-discussion] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison)
In-Reply-To: <Pine.LNX.4.10.10010111510270.3131-100000@rocket.knowledgetrack.com>
Message-ID: <ADEOIFHFONCLEEPKCACCGEFHCBAA.pauldubois@home.com>

I don't have time to follow in detail this thread about changed behavior
between versions. These observations are based on working with hundreds of
code authors. I offer them as is.

a. Nobody runs a serious numeric calculation without setting
underflow-to-zero, in the hardware. You can't even afford the cost of
software checks. Unfortunately there is no portable way to do that that I
know of.

b. Some people use Inf but most people want the code to STOP so they can
find out where the INFS started. Otherwise, two hours later you have big
arrays of Infs and no idea how it happened. Likewise sqrt(-1.) needs to
stop, not put a zero and keep going.









From guido at python.org  Thu Oct 12 03:45:30 2000
From: guido at python.org (Guido van Rossum)
Date: Wed, 11 Oct 2000 20:45:30 -0500
Subject: [Python-Dev] RE: [Numpy-discussion] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison)
In-Reply-To: Your message of "Wed, 11 Oct 2000 17:04:51 MST."
             <ADEOIFHFONCLEEPKCACCGEFHCBAA.pauldubois@home.com> 
References: <ADEOIFHFONCLEEPKCACCGEFHCBAA.pauldubois@home.com> 
Message-ID: <200010120145.UAA02030@cj20424-a.reston1.va.home.com>

> I don't have time to follow in detail this thread about changed behavior
> between versions. These observations are based on working with hundreds of
> code authors. I offer them as is.
> 
> a. Nobody runs a serious numeric calculation without setting
> underflow-to-zero, in the hardware. You can't even afford the cost of
> software checks. Unfortunately there is no portable way to do that that I
> know of.
> 
> b. Some people use Inf but most people want the code to STOP so they can
> find out where the INFS started. Otherwise, two hours later you have big
> arrays of Infs and no idea how it happened. Likewise sqrt(-1.) needs to
> stop, not put a zero and keep going.

Thanks, Paul!  This behavior has always been what I wanted Python to
do (even though it's not always what Python did, depending on the
platform) and also what Tim's proposed patch will implement for the
specific case of math.exp() (and other math functions that may
underflow or overflow), on most reasonable platforms.

There are still lots of places where the platform gives Python no
choice of creating NaN and Inf, and because there's no
platform-independent way to test for these, they are hard to avoid in
some cases; but eventually, Tim will find a way to root them out.  And
for people like Huaiyu, who want to see Inf, there will (eventually)
be a way to select this as a run-time option; and ditto for whoever
might want underflow to raise an exception.

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



From huaiyu_zhu at yahoo.com  Thu Oct 12 04:22:54 2000
From: huaiyu_zhu at yahoo.com (Huaiyu Zhu)
Date: Wed, 11 Oct 2000 19:22:54 -0700 (PDT)
Subject: [Python-Dev] RE: [Numpy-discussion] RE: Possible bug (was Re:
 numpy, overflow, inf, ieee, and rich comparison)
In-Reply-To: <200010120145.UAA02030@cj20424-a.reston1.va.home.com>
Message-ID: <Pine.LNX.4.10.10010111833510.3385-100000@rocket.knowledgetrack.com>

[Paul Dubois]
> > 
> > a. Nobody runs a serious numeric calculation without setting
> > underflow-to-zero, in the hardware. You can't even afford the cost of
> > software checks. Unfortunately there is no portable way to do that that I
> > know of.

Amen.

> > 
> > b. Some people use Inf but most people want the code to STOP so they can
> > find out where the INFS started. Otherwise, two hours later you have big
> > arrays of Infs and no idea how it happened. Likewise sqrt(-1.) needs to
> > stop, not put a zero and keep going.

$ /usr/bin/python
Python 1.5.2 (#1, Sep 17 1999, 20:15:36)  [GCC egcs-2.91.66 19990314/Linux
(egcs- on linux-i386
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> from math import *
>>> exp(777)
inf
>>> exp(-777)
0.0
>>> sqrt(-1)
Traceback (innermost last):
  File "<stdin>", line 1, in ?
OverflowError: math range error

This was sane behavior.  Are we saying that Python 2.0 has invented
something better than IEEE 754?

[Guido van Rossum]

> Thanks, Paul!  This behavior has always been what I wanted Python to
> do (even though it's not always what Python did, depending on the
> platform) and also what Tim's proposed patch will implement for the
> specific case of math.exp() (and other math functions that may
> underflow or overflow), on most reasonable platforms.

Guido, with due respect to your decisions on Python issues, I simply have to
fight this one.  It is one thing to accomodate for naive users, but it is
another to dumb down every one else.

Case 1.  Someone writes a flawed numerical routine.  Two hours later he
finds his array filled with Inf and NaN.

Case 2.  Someone writes a perfect numerical routine.  Two hours later he
gets an exception, because the error is near zero.

Solution for case 1.  Use better algorithm.  Use better error control.
Raise exceptions when error is too large.  These are proper solutions.  
They are easy and efficient to implement.  They are needed anyway - If
something's wrong, you want to raise exceptions far earlier than Inf,
certainly before you get arrays filled with elements like 1e300.

Solution for case 2.  Almost impossible.  The division between under- and
over-flow is artificial.  What about 1/x or similar functions?  The only way
to work on such a platform is to abandon vectorized computation.

> There are still lots of places where the platform gives Python no
> choice of creating NaN and Inf, and because there's no
> platform-independent way to test for these, they are hard to avoid in
> some cases; but eventually, Tim will find a way to root them out.  And
> for people like Huaiyu, who want to see Inf, there will (eventually)
> be a way to select this as a run-time option; and ditto for whoever
> might want underflow to raise an exception.

I can understand that exceptions are the only available choices if IEEE is
not available.  But is there a compelling reason that Python should behave
"better" than IEEE when it's in fact available?

If the reason is to protect naive users, I can think of several responses:

1. For people doing one-off interactive work, returning Inf is in fact more
   informative. 

2. For users iterative numerical computations, they need to be educated
   about error control.  Otherwise they won't get corrent results anyway.

3. For really serious work, we could provide good numerical modules so that
   they don't need to write themselves.  To make this happen fast the fewer
   debacles like this one the better.

Case in point: Someone asked for regession modules two weeks ago.  I was
trying to convert my old matlab programs, which only took a few hours.  But
I wasted a week of (spare) time fighting for some mysterious "overflow".
Turns out that a Guassian is near zero when it's far from center, and Python
does not like it.

In practice, Inf may be generated more often as a proper value than by
mistake.

This is not an issue about whether someone "prefers" Inf or exception.  It
is about whether there is a choice to do proper computation.  Returning Inf
does not prevent someone to raise exception.  Raising exception
automatically prevents perfect algorithms to work properly.

As Kevin has volunteered to help with IEEE implementation and made a plan,
is there a strong reason to drop IEEE for Linux in 2.0?  If there is
insufficient time to carry out his plan, wouldn't it be prudent to keep
things as they were in 1.5.2?

Huaiyu




From tim_one at email.msn.com  Thu Oct 12 04:44:20 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Wed, 11 Oct 2000 22:44:20 -0400
Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison)
In-Reply-To: <Pine.LNX.4.10.10010111510270.3131-100000@rocket.knowledgetrack.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCKENNHKAA.tim_one@email.msn.com>

[Huaiyu Zhu]
> On the issue of whether Python should ignore over/underflow on
> IEEE-enabled platforms:
>
> It can be argued that on IEEE enabled systems the proper thing to do for
> overflow is simply return Inf.  Raising exception is WRONG.  See below.

Python was not designed with IEEE-754 in mind, and *anything* that happens
wrt Infs, NaNs, and all other 754 features in Python is purely an accident
that can and does vary wildly across platforms.  And, as you've discovered
in this case, can vary wildly also across even a single library, depending
on config options.  We cannot consider this to be a bug since Python has had
no *intended* behavior whatsoever wrt 754 gimmicks.  We can and do consider
gripes about these accidents to be feature requests.

[Guido]
> Incidentally, math.exp(800) returns inf in 1.5, and raises
> OverflowError in 2.0.  So at least it's consistent.

[Huaiyu]
> That is not consistent at all.

Please read with an assumption of good faith.  Guido was pointing out that--
all in the specific case of gcc+glibc on Linux (these don't hold on other
platforms) --exp(800) returning Inf in 1.5 and OverflowError in 2.0 is
consistent *with* that exp(-800) returns 0 in 1.5 and raises an exception in
2.0.  He's right; indeed, he is in part agreeing with you.

[Guido
> 1.5.2 links with -lieee while 2.0 doesn't.  Removing -lieee from the
> 1.5.2 link line makes is raise OverflowError too.  Adding it to the
> 2.0 link line makes it return 0.0 for exp(-1000) and inf for
> exp(1000).

[Huaiyu]
> If using ieee is as simple as setting such a flag, there is no
> reason at all not to use it.

The patch to stop setting -lieee was contributed by a Python user who
claimed it fixed bugs on *their* platform.  That's "the reason".  We don't
want to screw them either.

> Here are some more examples:
> ...

I understand that 754 semantics can be invaluable.  So does Guido.  There's
no argument about that.  But Python doesn't yet support them, and wishing it
did doesn't make it so.  If linking with -lieee happens to give you the
semantics you want on your platform today, you're welcome to build with that
switch.  It appears to be a bad choice for *most* Python users, though (more
below), so we don't want to do it in the std 2.0 distro.

> ...
> In practice this simply means Python would not be suitable for numerical
> work at all.

Your biggest obstacle in getting Python support for 754 will in fact be
opposition from number-crunchers.  I've been slinging fp for 21 years, 15 of
those writing compilers and math libraries for "supercomputer" vendors.  754
is a Very Good Thing, but is Evil in subset form (see Kahan's (justified!)
vilification of Java on this point); ironically, 754 is hardest to sell to
those who could benefit from it the most.

> What about the other way round?  No problem.  It is easy to write
> functions like isNaN, isInf, etc.

It's easy for a platform expert to write such functions for their specific
platform of expertise, but it's impossible to write them in a portable way
before C99 is implemented (C99 requires that library suppliers provide them,
rendering the question moot).

> ...
> The language should never take over or subvert decisions based on
> numerical analysis.

Which is why a subset of 754 is evil.  754 requires that the user be able to
*choose* whether or not, e.g., overflow signals an exception.  Your crusade
to insist that it never raise an exception is as least as bad (I think it's
much worse) as Python's most common accidental behavior (where overflow from
libm usually raises an exception).  One size does not fit all.

[Tim]
> Ignoring ERANGE entirely is not at all the same behavior as 1.5.2, and
> current code certainly relies on detecting overflows in math functions.

[Huaiyu]
> As Guido observed ERANGE is not generated with ieee, even for
> overflow.  So it is the same behavior as 1.5.2.

You've got a bit of a case of tunnel vision here, Huaiyu.  Yes, in the
specific case of gcc+glibc+Linux, ignoring ERANGE returned from exp() is
what 1.5.2 acted like.  But you have not proposed to ignore it merely from
ERANGE returned from exp() in the specific case of gcc+glibc+Linux.  This
code runs on many dozens of platforms, and, e.g., as I suggested before, it
looks like HPUX has always set errno on both overflow and underflow.  MS
Windows sets it on overflow but not underflow.  Etc.  We have to worry about
the effects on all platforms.

> Besides, no correct numerical code should depend on exceptions like
> this unless the machine is incapable of handling Inf and NaN.

Nonsense.  754 provides the option to raise an exception on overflow, or
not, at the user's discretion, precisely because exceptions are sometimes
more appropriate than Infs of NaNs.  Kahan himself isn't happy with Infs and
NaNs because they're too often too gross a clue (see his writings on
"presubstitution" for a more useful approach).

[Tim]
> In no case can you expect to see overflow ignored in 2.0.

[Huaiyu]
> You are proposing a dramatic change from the behavior of 1.5.2.
> This looks like to me to need a PEP and a big debate.  It would break
> a LOT of numerical computations.

I personally doubt that, but realize it may be true.  That's why he have
beta releases.  So far yours is the only feedback we've heard (thanks!), and
as a result we're going to change 2.0 to stop griping about underflow, and
do so in a way that will actually work across all platforms.  We're probably
going to break some HPUX programs as a result; but they were relying on
accidents too.

[Guido]
> No, the configure patch is right.  Tim will check in a change that
> treats ERANGE with a return value of 0.0 as underflow (returning 0.0,
> not raising OverflowError).

[Huaiyu]
> What is the reason to do this?  It looks like intetionally subverting
> ieee even when it is available.  I thought Tim meant that only logistical
> problems prevent using ieee.

Python does not support 754 today.  Period.  I would like it to, but not in
any half-assed, still platform-dependent, still random crap-shoot, still
random subset of 754 features, still rigidly inflexible, way.  When it does
support it, Guido & I will argue that it should enable (what 754 calls) the
overflow, divide-by-0 and invalid operation exceptions by default, and
disable the underflow and inexact exceptions by default.  This ensures that,
under the default, an infinity or NaN can never be created from
non-exceptional inputs without triggering an exception. Not only is that
best for newbies, you'll find it's the *only* scheme for a default that can
be sold to working number-crunchers (been there, done that, at Kendall
Square Research).  It also matches Guido's original, pre-754, *intent* for
how Python numerics should work by default (it is, e.g., no accident that
Python has always had an OverflowError exception but never an UnderflowError
one).

And that corresponds to the change Guido says <wink> I'm going to make in
mathmodule.c:  suppress complaints about underflow, but let complaints about
overflow go through.  This is not a solution, it's a step on a path towards
a solution.  The next step (which will not happen for 2.0!) is to provide an
explicit way to, from Python, disable overflow checking, and that's simply
part of providing the control and inquiry functions mandated by 754.  Then
code that would rather deal with Infs than exceptions can, at its explicit
discretion.

> If you do choose this route, please please please ignore ERANGE entirely,
> whether return value is zero or not.

It should be clear that isn't going to happen.  I realize that triggering
overflow is going to piss you off, but you have to realize that not
triggering overflow is going to piss more people off, and *especially* your
fellow number-crunchers.  Short of serious 754 support, picking "a winner"
is the best we can do for now.  You have the -lieee flag on your platform du
jour if you can't bear it.

[Paul Dubois]
> I don't have time to follow in detail this thread about changed behavior
> between versions.

What makes you think we do <0.5 wink>?

> These observations are based on working with hundreds of code authors. I
> offer them as is.

FWIW, they exactly match my observations from 15 years on the HW vendor
side.

> a. Nobody runs a serious numeric calculation without setting underflow-to-
> zero, in the hardware. You can't even afford the cost of software checks.
> Unfortunately there is no portable way to do that that I know of.

C allows libm implementations a lot of discretion in whether to set errno to
ERANGE in case of underflow.  The change we're going to make is to ignore
ERANGE in case of underflow, ensuring that math.* functions will *stop*
raising underflow exceptions on all platforms (they'll return a zero
instead; whether +0 or -0 will remain a platform-dependent crap shoot for
now).  Nothing here addresses underflow exceptions that may be raised by fp
hardware, though; this has solely to do with the platform libm's treatment
of errno.

So in this respect, we're removing Python's current unpredictability, and in
the way you favor.

> b. Some people use Inf but most people want the code to STOP so they can
> find out where the INFS started. Otherwise, two hours later you have big
> arrays of Infs and no idea how it happened.

Apparently Python on libc+glibc+Linux never raised OverflowError from math.*
functions in 1.5.2 (although it did on most other platforms I know about).
A patch checked in to fix some other complaint on some other Unixish
platform had the side-effect of making Python on libc+glibc+Linux start
raising OverflowError from math.* functions in 2.0, but in both overflow and
underflow cases.  We intend to (as above) suppress the underflow exceptions,
but let the overflow cases continue to raise OverflowError.  Huaiyu's
original complaint was about the underflow cases, but (as such things often
do) expanded beyond that when it became clear he would get what he asked for
<wink>.

Again we're removing Python's current unpredictability, and again in the way
you favor -- although this one is still at the mercy of whether the platform
libm sets errno correctly on overflow (but it seems that most do these
days).

> Likewise sqrt(-1.) needs to stop, not put a zero and keep going.

Nobody has proposed changing anything about libm domain (as opposed to
range) errors (although Huaiyu probably should if he's serious about his
flavor of 754 subsetism -- I have no idea what gcc+glibc+Linux did here on
1.5.2, but it *should* have silently returned a NaN (not a zero) without
setting errno if it was *self*-consistent -- anyone care to check that
under -lieee?:

    import math
    math.sqrt(-1)

NaN or ValueError?  2.0 should raise ValueError regardless of what 1.5.2 did
here.).

just-another-day-of-universal-python-harmony-ly y'rs  - tim





From sdm7g at virginia.edu  Thu Oct 12 05:23:32 2000
From: sdm7g at virginia.edu (Steven D. Majewski)
Date: Wed, 11 Oct 2000 23:23:32 -0400 (EDT)
Subject: [Python-Dev] RE: [Numpy-discussion] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison)
In-Reply-To: <Pine.LNX.4.10.10010111833510.3385-100000@rocket.knowledgetrack.com>
Message-ID: <Pine.A32.3.90.1001011225636.4671B-100000@elvis.med.Virginia.EDU>


First: I haven't followed this thread from the beginning -- only the
last ten or so posts. 

Second: One reason I didn't follow it from the start is that I'm not
doing any heavy numerical stuff in Python. I've been using Lisp for
that, and use Python more for string/symbolic or GUI hacking. 

But, if I was going to do the sort of numerical stuff I now do in 
Lisp in Python, I would agree with Huaiya Zhu. I do a lot of 
vectorized operations on what are often independent samples. 
If some of the numbers overflow or underflow, that just represents
an outlier or bad sample. I don't want it to blow off the whole
pipeline of operations on the other data points in the vector -- 
they are independent of the bad points. 

 In my case, it's not that these are lengthy calculations. It's
that they are interactive and tied to immediate graphical 
representations. If there are strange zero's or infinities in
the result, there is (or should be) a way to backtrack and 
investigate. ( That's why people want interactive and graphical
regression analysis and modeling tools! ) 

 The idea that your calculation should blow up and you should 
check it and resubmit your job sounds just so ancient-20th-century-
Fortran-JCL-and-punched-cards-technology! 
 

---|  Steven D. Majewski   (804-982-0831)  <sdm7g at Virginia.EDU>  |---
---|  Department of Molecular Physiology and Biological Physics  |---
---|  University of Virginia             Health Sciences Center  |---
---|  P.O. Box 10011            Charlottesville, VA  22906-0011  |---
		"All operating systems want to be unix, 
		 All programming languages want to be lisp." 




From tim_one at email.msn.com  Thu Oct 12 06:18:19 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Thu, 12 Oct 2000 00:18:19 -0400
Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison)
In-Reply-To: <20001011234038.A2322@better.net>
Message-ID: <LNBBLJKPBEHFEDALKOLCKEOFHKAA.tim_one@email.msn.com>

[William Park]
> On Wed, Oct 11, 2000 at 10:44:20PM -0400, Tim Peters wrote:
> > > Likewise sqrt(-1.) needs to stop, not put a zero and keep going.

I didn't write that.  Paul Dubois did.

> Hmm... I don't like this.  It should stop or return complex.

Paul said it should stop.  You said it should stop (or return complex).  So
what is it that you don't like <wink/frown>?  754 mandates that sqrt(x) for
x<0 return a NaN and keep going (by default) -- which even Huaiyu apparently
doesn't like.

[actually Tim]
> I have no idea what gcc+glibc+Linux  did here on 1.5.2, but it *should*
> have silently returned a NaN (not a zero) without setting errno if it
> was *self*-consistent -- anyone care to check that under -lieee?:
>
>      import math
>      math.sqrt(-1)
>
> NaN or ValueError?  2.0 should raise ValueError regardless of
> what 1.5.2 did here.).

[back to William]
> It returns 'OverflowError: math range error' in 1.5.2,

Ah, that's hilarious <wink>!  It's tempting to believe that glibc is
violating the IEEE std despite the -lieee flag in this case, but I don't
believe that's true:  it's almost certainly the case that glibc is actually
returning a NaN, *not* setting errno at all, and this other check in
Python's mathmodule.c:

#define CHECK(x) if (errno != 0) ; \
	else if (-HUGE_VAL <= (x) && (x) <= HUGE_VAL) ; \
	else errno = ERANGE

is setting errno to ERANGE purely due to an accident of the way gcc happens
to compile code for comparing NaN to Inf and -Inf.

> and 'ValueError: math domain error' in 2.0.

Which is the correct exception, so is another reason for Python to
avoid -lieee in 2.0.

will-be-easier-to-make-it-work-right-by-design-than-to-keep-doping-out-
    what-happens-by-accident-now-ly y'rs  - tim





From tim_one at email.msn.com  Thu Oct 12 08:16:23 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Thu, 12 Oct 2000 02:16:23 -0400
Subject: [Python-Dev] RE: [Numpy-discussion] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison)
In-Reply-To: <Pine.LNX.4.10.10010111833510.3385-100000@rocket.knowledgetrack.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCEEOHHKAA.tim_one@email.msn.com>

[Huaiyu Zhu]
> ...
> $ /usr/bin/python
> Python 1.5.2 (#1, Sep 17 1999, 20:15:36)  [GCC egcs-2.91.66 19990314/Linux
> (egcs- on linux-i386
> Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
> >>> from math import *
> >>> exp(777)
> inf
> >>> exp(-777)
> 0.0
> >>> sqrt(-1)
> Traceback (innermost last):
>   File "<stdin>", line 1, in ?
> OverflowError: math range error
>
> This was sane behavior.  Are we saying that Python 2.0 has invented
> something better than IEEE 754?

754 allows users to choose the behaviors they want.  Any *fixed* policy is
not 754.  So long as we have to fix a single policy, yes, I believe Guido (&
know I) would say that raising OverflowError on exp(777), and silently
returning 0 on exp(-777), and raising ValueError on sqrt(-1) (*not*
OverflowError, as shown above), is indeed better than the 754 default
behaviors.  And 2.0 will do all three of those (& I just checked in the code
to make that happen).

About the sqrt example above, that's neither 754 behavior nor sane behavior:
default 754 behavior on sqrt(-1) is to return a NaN and keep on going.  I'm
pretty sure that's what glibc linked w/ -lieee actually does, too (if it
doesn't, glibc -lieee is violating 754).  That 1.5.2 raised an OverflowError
instead is insane, and appears purely due to an accident of how gcc compiles
code to compare Infs to NaNs (Python's mathmodule.c's CHECK() macro was
fooled by this into setting errno to ERANGE itself).  Python should raise a
ValueError there instead (corresponding to libm setting errno to EDOM --
this is a domain error, not a range error) -- which it does now under CVS
Python.

754-doesn't-work-unless-you've-got-all-of-it-ly y'rs  - tim





From thomas at xs4all.net  Thu Oct 12 10:11:57 2000
From: thomas at xs4all.net (Thomas Wouters)
Date: Thu, 12 Oct 2000 10:11:57 +0200
Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison)
In-Reply-To: <LNBBLJKPBEHFEDALKOLCKENNHKAA.tim_one@email.msn.com>; from tim_one@email.msn.com on Wed, Oct 11, 2000 at 10:44:20PM -0400
References: <Pine.LNX.4.10.10010111510270.3131-100000@rocket.knowledgetrack.com> <LNBBLJKPBEHFEDALKOLCKENNHKAA.tim_one@email.msn.com>
Message-ID: <20001012101157.Y12812@xs4all.nl>

On Wed, Oct 11, 2000 at 10:44:20PM -0400, Tim Peters wrote:

> > Likewise sqrt(-1.) needs to stop, not put a zero and keep going.

> Nobody has proposed changing anything about libm domain (as opposed to
> range) errors (although Huaiyu probably should if he's serious about his
> flavor of 754 subsetism -- I have no idea what gcc+glibc+Linux did here on
> 1.5.2, but it *should* have silently returned a NaN (not a zero) without
> setting errno if it was *self*-consistent -- anyone care to check that
> under -lieee?:

>     import math
>     math.sqrt(-1)

>>> import math
>>> math.sqrt(-1)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
OverflowError: math range error

The same under both 1.5.2 and 2.0c1 with -lieee. Without -lieee, both do:

>>> import math
>>> math.sqrt(-1)
Traceback (innermost last):
  File "<stdin>", line 1, in ?
ValueError: math domain error

Consistency-conschmistency-ly y'rs,

-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!



From jeremy at beopen.com  Thu Oct 12 17:58:10 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Thu, 12 Oct 2000 11:58:10 -0400 (EDT)
Subject: [Python-Dev] (no subject)
Message-ID: <14821.57234.444047.511672@bitdiddle.concentric.net>

Cc xml-sig at python.org
Subject: test_minidom non-failure failure?
X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid
Reply-To: jeremy at beopen.com
Comments: Hyperbole mail buttons accepted, v04.18.

SSBqdXN0IHJhbiAnbWFrZSB0ZXN0JyBhZ2FpbnN0IGEgY2xlYW4gY29weSBvZiB0aGUgQ1ZT
IHRyZWUgYW5kIGdvdCBhbg0KZW5vcm1vdXMgYW1vdW50IG9mIGdhcmJhZ2Ugb3V0cHV0IGZy
b20gdGVzdF9taW5pZG9tLCBhbHRob3VnaCBpdCB3YXMNCm5vdCByZXBvcnRlZCBhcyBhIHRl
c3QgdGhlIGZhaWxlZCBvciB3YXMgc2tpcHBlZC4NCg0KVGhlIG91dHB1dCBmcm9tIHRlc3Rf
bWluaWRvbSBzdGFydGVkIHRoaXMgd2F5Og0KDQp0ZXN0X21pbmlkb20NCmdhcmJhZ2U6IFt7
J25vZGVWYWx1ZSc6IHUnT2Jzb2xldGUgYnV0IGltcGxlbWVudGVkLi4uJywgJ25leHRTaWJs
aW5nJzogPERPTSBUZXh0IG5vZGUgIlwwMTIiPiwgJ2NoaWxkTm9kZXMnOiBOb25lLCAnYXR0
cmlidXRlcyc6IE5vbmUsICdwYXJlbnROb2RlJzogTm9uZSwgJ2RhdGEnOiB1J09ic29sZXRl
IGJ1dCBpbXBsZW1lbnRlZC4uLicsICdwcmV2aW91c1NpYmxpbmcnOiBOb25lfSwgPERPTSBU
ZXh0IG5vZGUgIk9ic29sZXRlIGIuLi4iPiwgeydub2RlVmFsdWUnOiB1J1wwMTInLCAnbmV4
dFNpYmxpbmcnOiBOb25lLCAnY2hpbGROb2Rlcyc6IE5vbmUsICdhdHRyaWJ1dGVzJzogTm9u
ZSwgJ3BhcmVudE5vZGUnOiBOb25lLCAnZGF0YSc6IHUnXDAxMicsICdwcmV2aW91c1NpYmxp
bmcnOiA8RE9NIFRleHQgbm9kZSAiT2Jzb2xldGUgYi4uLiI+fSwgPERPTSBUZXh0IG5vZGUg
IlwwMTIiPiwgeydub2RlVmFsdWUnOiB1J09ic29sZXRlIGJ1dCBpbXBsZW1lbnRlZC4uLics
ICduZXh0U2libGluZyc6IDxET00gVGV4dCBub2RlICJcMDEyIj4sICdjaGlsZE5vZGVzJzog
Tm9uZSwgJ2F0dHJpYnV0ZXMnOiBOb25lLCAncGFyZW50Tm9kZSc6IE5vbmUsICdkYXRhJzog
dSdPYnNvbGV0ZSBidXQgaW1wbGVtZW50ZWQuLi4nLCAncHJldmlvdXNTaWJsaW5nJzogTm9u
ZX0sIDxET00gVGV4dCBub2RlICJPYnNvbGV0ZSBiLi4uIj4sIHsnbm9kZVZhbHVlJzogdSdc
MDEyJywgJ25leHRTaWJsaW5nJzogTm9uZSwgJ2NoaWxkTm9kZXMnOiBOb25lLCAnYXR0cmli
dXRlcyc6IE5vbmUsICdwYXJlbnROb2RlJzogTm9uZSwgJ2RhdGEnOiB1J1wwMTInLCAncHJl
dmlvdXNTaWJsaW5nJzogPERPTSBUZXh0IG5vZGUgIk9ic29sZXRlIGIuLi4iPn0sIDxET00g
VGV4dCBub2RlICJcMDEyIj4sIHsnbm9kZVZhbHVlJzogdSdPYnNvbGV0ZSBidXQgaW1wbGVt
ZW50ZWQuLi4nLCAnbmV4dFNpYmxpbmcnOiA8RE9NIFRleHQgbm9kZSAiXDAxMiI+LCAnY2hp
bGROb2Rlcyc6IE5vbmUsICdhdHRyaWJ1dGVzJzogTm9uZSwgJ3BhcmVudE5vZGUnOiBOb25l
LCAnZGF0YSc6IHUnT2Jzb2xldGUgYnV0IGltcGxlbWVudGVkLi4uJywgJ3ByZXZpb3VzU2li
bGluZyc6IE5vbmV9LCA8RE9NIFRleHQgbm9kZSAiT2Jzb2xldGUgYi4uLiI+LCB7J25vZGVW
YWx1ZSc6IHUnXDAxMicsICduZXh0U2libGluZyc6IE5vbmUsICdjaGlsZE5vZGVzJzogTm9u
ZSwgJ2F0dHJpYnV0ZXMnOiBOb25lLCAncGFyZW50Tm9kZSc6IE5vbmUsICdkYXRhJzogdSdc
MDEyJywgJ3ByZXZpb3VzU2libGluZyc6IDxET00gVGV4dCBub2RlICJPYnNvbGV0ZSBiLi4u
Ij59LCA8RE9NIFRleHQgbm9kZSAiXDAxMiI+LCB7J25vZGVWYWx1ZSc6ICd0ZXh0JywgJ25l
eHRTaWJsaW5nJzogPERPTSBFbGVtZW50OiBzdWJlbG0gYXQgMTM3ODYzMzg4PiwgJ2NoaWxk
Tm9kZXMnOiBOb25lLCAnYXR0cmlidXRlcyc6IE5vbmUsICdwYXJlbnROb2RlJzogTm9uZSwg
J2RhdGEnOiAndGV4dCcsICdwcmV2aW91c1NpYmxpbmcnOiBOb25lfSwgPERPTSBUZXh0IG5v
ZGUgInRleHQiPiwgeydfYXR0cnMnOiB7fSwgJ3ByZXZpb3VzU2libGluZyc6IDxET00gVGV4
dCBub2RlICJ0ZXh0Ij4sICdjaGlsZE5vZGVzJzogTm9uZSwgJ2xvY2FsTmFtZSc6ICdzdWJl
bG0nLCAndGFnTmFtZSc6ICdzdWJlbG0nLCAnX2F0dHJzTlMnOiB7fSwgJ3ByZWZpeCc6ICcn
LCAnbmFtZXNwYWNlVVJJJzogJycsICdub2RlVmFsdWUnOiBOb25lLCAnbmV4dFNpYmxpbmcn
OiA8RE9NIFRleHQgbm9kZSAidGV4dCI+LCAncGFyZW50Tm9kZSc6IE5vbmUsICdub2RlTmFt
ZSc6ICdzdWJlbG0nfSwgPERPTSBFbGVtZW50OiBzdWJlbG0gYXQgMTM3ODYzMzg4Piwge30s
IHt9LCB7J25vZGVWYWx1ZSc6ICd0ZXh0JywgJ25leHRTaWJsaW5nJzogTm9uZSwgJ2NoaWxk
Tm9kZXMnOiBOb25lLCAnYXR0cmlidXRlcyc6IE5vbmUsICdwYXJlbnROb2RlJzogTm9uZSwg
J2RhdGEnOiAndGV4dCcsICdwcmV2aW91c1NpYmxpbmcnOiA8RE9NIEVsZW1lbnQ6IHN1YmVs
bSBhdCAxMzc4NjMzODg+fSwgPERPTSBUZXh0IG5vZGUgInRleHQiPiwgeydub2RlVmFsdWUn
OiB1J09ic29sZXRlIGJ1dCANCg0KSXQgY29udGludWVkIG9uIGluIHRoZSBzYW1lIGZhc2hp
b24gZm9yIGFib3V0IGEgdGhvdXNhbmQgbGluZXMuICBBZnRlcg0KcHJpbnRpbmcgYWxsIHRo
aXMgZ2FyYmFnZSwgaXQgY29udGludWVkIG9uIHRvIHRlc3RfbW1hcC4NCg0KVGhlIGZpbmFs
IHRlc3QgcmVwb3J0IHdhczoNCg0KOTUgdGVzdHMgT0suDQoxMyB0ZXN0cyBza2lwcGVkOiB0
ZXN0X2FsIHRlc3RfY2QgdGVzdF9jbCB0ZXN0X2RibSB0ZXN0X2RsIHRlc3RfZ2wNCnRlc3Rf
aW1nZmlsZSB0ZXN0X2xhcmdlZmlsZSB0ZXN0X25pcyB0ZXN0X3N1bmF1ZGlvZGV2IHRlc3Rf
dGltaW5nDQp0ZXN0X3dpbnJlZyB0ZXN0X3dpbnNvdW5kDQoNCkFueSBpZGVhcyBhYm91dCB3
aGF0IHdlbnQgd3Jvbmc/DQoNCkplcmVteQ==



From jeremy at beopen.com  Thu Oct 12 18:11:53 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Thu, 12 Oct 2000 12:11:53 -0400 (EDT)
Subject: [Python-Dev] test_minidom non-failure failure? (take 2)
Message-ID: <14821.58057.358947.271778@bitdiddle.concentric.net>

Sorry about the previous message; a mail munger somewhere between my
display and python.org choked on a very long line...

I am getting an occasional, hard-to-reproduce error in test_minidom.
When I run the test, it displays about a thousand lines of garbage,
but the test suite does not report test_minidom as failed or skipped.

The output I see during the test run is this:

test_minidom
garbage: [{'nodeValue': u'Obsolete but implemented...', 'nextSibling':
<DOM Text node "\012">, 'childNodes': None, 'attributes': None,
'parentNode': None, 'data': u'Obsolete but implemented...',
'previousSibling': None}, <DOM Text node "Obsolete b...">,
{'nodeValue': u'\012', 'nextSibling': None, 'childNodes': None, 'a 
[... many hundreds of lines omitted]

At the end of the test, I get a pretty normal result:
95 tests OK.
13 tests skipped: test_al test_cd test_cl test_dbm test_dl test_gl
test_imgfile test_largefile test_nis test_sunaudiodev test_timing
test_winreg test_winsound 

So two questions:

Why is test_minidom producing all this output?  And why is it only
happening intermittently?

Why does regrtest.py think that test_minidom is working correctly when
it produces all this output?

Jeremy




From nas at arctrix.com  Thu Oct 12 11:31:34 2000
From: nas at arctrix.com (Neil Schemenauer)
Date: Thu, 12 Oct 2000 02:31:34 -0700
Subject: [Python-Dev] test_minidom non-failure failure? (take 2)
In-Reply-To: <14821.58057.358947.271778@bitdiddle.concentric.net>; from jeremy@beopen.com on Thu, Oct 12, 2000 at 12:11:53PM -0400
References: <14821.58057.358947.271778@bitdiddle.concentric.net>
Message-ID: <20001012023134.A18254@glacier.fnational.com>

On Thu, Oct 12, 2000 at 12:11:53PM -0400, Jeremy Hylton wrote:
> I am getting an occasional, hard-to-reproduce error in test_minidom.
> When I run the test, it displays about a thousand lines of garbage,
> but the test suite does not report test_minidom as failed or skipped.
> 
> The output I see during the test run is this:
> 
> test_minidom
> garbage: [{'nodeValue': u'Obsolete but implemented...', 'nextSibling':

This is most likely the garbage collector.  regrtest.py contains
the following code:

        if findleaks:
            gc.collect()
            if gc.garbage:
                print "garbage:", repr(gc.garbage)
                found_garbage.extend(gc.garbage)
                del gc.garbage[:]

findleaks is true if the -l option is specified (TESTOPS in the
makefile includes it).  Something is producing cyclic garbage.

  Neil



From guido at python.org  Thu Oct 12 19:39:40 2000
From: guido at python.org (Guido van Rossum)
Date: Thu, 12 Oct 2000 12:39:40 -0500
Subject: [Python-Dev] test_minidom non-failure failure? (take 2)
In-Reply-To: Your message of "Thu, 12 Oct 2000 02:31:34 MST."
             <20001012023134.A18254@glacier.fnational.com> 
References: <14821.58057.358947.271778@bitdiddle.concentric.net>  
            <20001012023134.A18254@glacier.fnational.com> 
Message-ID: <200010121739.MAA07968@cj20424-a.reston1.va.home.com>

> On Thu, Oct 12, 2000 at 12:11:53PM -0400, Jeremy Hylton wrote:
> > I am getting an occasional, hard-to-reproduce error in test_minidom.
> > When I run the test, it displays about a thousand lines of garbage,
> > but the test suite does not report test_minidom as failed or skipped.
> > 
> > The output I see during the test run is this:
> > 
> > test_minidom
> > garbage: [{'nodeValue': u'Obsolete but implemented...', 'nextSibling':

[Neil]
> This is most likely the garbage collector.  regrtest.py contains
> the following code:
> 
>         if findleaks:
>             gc.collect()
>             if gc.garbage:
>                 print "garbage:", repr(gc.garbage)
>                 found_garbage.extend(gc.garbage)
>                 del gc.garbage[:]
> 
> findleaks is true if the -l option is specified (TESTOPS in the
> makefile includes it).  Something is producing cyclic garbage.

Of course something is producing cyclic garbage!

The DOM tree is full of parent and child links.

Does this output mean that the GC works correctly?  Or does it mean
that there is a reason why this garbage cannot be disposed of?

In the latter case, could that be because there are __del__ methods?

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



From fdrake at beopen.com  Thu Oct 12 18:55:19 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Thu, 12 Oct 2000 12:55:19 -0400 (EDT)
Subject: [Python-Dev] test_minidom non-failure failure? (take 2)
In-Reply-To: <20001012023134.A18254@glacier.fnational.com>
References: <14821.58057.358947.271778@bitdiddle.concentric.net>
	<20001012023134.A18254@glacier.fnational.com>
Message-ID: <14821.60663.213246.179325@cj42289-a.reston1.va.home.com>

Neil Schemenauer writes:
 > This is most likely the garbage collector.  regrtest.py contains
 > the following code:
...
 > findleaks is true if the -l option is specified (TESTOPS in the
 > makefile includes it).  Something is producing cyclic garbage.

  This is definately the problem.
  Lars, Paul:  This looks like a problem in the unlink() method of the
DOM.  Could you please check that the unlink() method is updated to
handle the latest version of the other changes?
  Thanks!


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From fdrake at beopen.com  Thu Oct 12 18:59:33 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Thu, 12 Oct 2000 12:59:33 -0400 (EDT)
Subject: [Python-Dev] test_minidom non-failure failure? (take 2)
In-Reply-To: <14821.58057.358947.271778@bitdiddle.concentric.net>
References: <14821.58057.358947.271778@bitdiddle.concentric.net>
Message-ID: <14821.60917.429141.652655@cj42289-a.reston1.va.home.com>

Jeremy Hylton writes:
 > Why is test_minidom producing all this output?  And why is it only
 > happening intermittently?

  It isn't.  See Neil's excellent explanation.

 > Why does regrtest.py think that test_minidom is working correctly when
 > it produces all this output?

  The test is passing just fine, and is complete before the test for
garbage is performed.  The unlink() method on DOM objects is the
culprit; it is updating the Node.allnodes dictionary correctly, but
not the Node instances.  I've already asked Paul & Lars to fix this;
it should work just fine with or without GC once they've seen the
report.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From nas at arctrix.com  Thu Oct 12 12:24:48 2000
From: nas at arctrix.com (Neil Schemenauer)
Date: Thu, 12 Oct 2000 03:24:48 -0700
Subject: [Python-Dev] test_minidom non-failure failure? (take 2)
In-Reply-To: <200010121739.MAA07968@cj20424-a.reston1.va.home.com>; from guido@python.org on Thu, Oct 12, 2000 at 12:39:40PM -0500
References: <14821.58057.358947.271778@bitdiddle.concentric.net> <20001012023134.A18254@glacier.fnational.com> <200010121739.MAA07968@cj20424-a.reston1.va.home.com>
Message-ID: <20001012032448.A18407@glacier.fnational.com>

On Thu, Oct 12, 2000 at 12:39:40PM -0500, Guido van Rossum wrote:
> Of course something is producing cyclic garbage!
> 
> The DOM tree is full of parent and child links.
> 
> Does this output mean that the GC works correctly?  Or does it
> mean that there is a reason why this garbage cannot be disposed
> of?  In the latter case, could that be because there are
> __del__ methods?

The -l option tries to find any cyclic garbage produced by the
tests.  I don't think that that option should be enabled default.
The output means that the GC is working and is finding stuff that
would not be freed by reference counting alone.  

I can't tell if the GC would free this garbage.  The -l option
sets the DEBUG_SAVEALL option which causes all garbage found to
end up in gc.garbage, not just garbage the can't be cleaned up.

I don't have pyexpat installed here so I can't test it.  If you
want to find out if test_minidom is creating garbage the
collector can't free you should comment out the:

    gc.set_debug(gc.DEBUG_SAVEALL)

line in regrtest.py and run:

    regrtest.py -l test_minidom

If that does what I think it does and you still get the "garbage: "
line then the test is creating evil things.  :)

  Neil



From hinsen at dirac.cnrs-orleans.fr  Thu Oct 12 19:24:18 2000
From: hinsen at dirac.cnrs-orleans.fr (hinsen at dirac.cnrs-orleans.fr)
Date: Thu, 12 Oct 2000 19:24:18 +0200
Subject: [Python-Dev] RE: [Numpy-discussion] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison)
In-Reply-To: <Pine.A32.3.90.1001011225636.4671B-100000@elvis.med.Virginia.EDU>
	(sdm7g@virginia.edu)
References: <Pine.A32.3.90.1001011225636.4671B-100000@elvis.med.Virginia.EDU>
Message-ID: <200010121724.TAA15487@chinon.cnrs-orleans.fr>

>  The idea that your calculation should blow up and you should 
> check it and resubmit your job sounds just so ancient-20th-century-
> Fortran-JCL-and-punched-cards-technology! 

Long-running jobs are still with us, even there's neither Fortran nor
JCL in them. And for these applications, stopping is better than going
on with nonsense values. On the other hand, as you point out, exceptions
for math errors are a bit of a pain for interactive work.

So how about making this a run-time option? I'd choose exceptions by
default and Infs and Nans by specifying a command-line option, but
there are certainly others who would prefer it the other way round.
What matters most to me is that the choice is possible somehow.

Konrad.
-- 
-------------------------------------------------------------------------------
Konrad Hinsen                            | E-Mail: hinsen at cnrs-orleans.fr
Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24
Rue Charles Sadron                       | Fax:  +33-2.38.63.15.17
45071 Orleans Cedex 2                    | Deutsch/Esperanto/English/
France                                   | Nederlands/Francais
-------------------------------------------------------------------------------



From sdm7g at virginia.edu  Thu Oct 12 20:25:44 2000
From: sdm7g at virginia.edu (Steven D. Majewski)
Date: Thu, 12 Oct 2000 14:25:44 -0400 (EDT)
Subject: [Python-Dev] RE: [Numpy-discussion] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison)
In-Reply-To: <200010121724.TAA15487@chinon.cnrs-orleans.fr>
Message-ID: <Pine.A32.3.90.1001012140201.14856A-100000@elvis.med.Virginia.EDU>


On Thu, 12 Oct 2000 hinsen at dirac.cnrs-orleans.fr wrote:

> >  The idea that your calculation should blow up and you should 
> > check it and resubmit your job sounds just so ancient-20th-century-
> > Fortran-JCL-and-punched-cards-technology! 
> 
> Long-running jobs are still with us, even there's neither Fortran nor
> JCL in them. And for these applications, stopping is better than going
> on with nonsense values. On the other hand, as you point out, exceptions
> for math errors are a bit of a pain for interactive work.
> 
> So how about making this a run-time option? I'd choose exceptions by
> default and Infs and Nans by specifying a command-line option, but
> there are certainly others who would prefer it the other way round.
> What matters most to me is that the choice is possible somehow.
> 

I agree entirely! 
Maybe I was being a bit too glib, but I didn't mean to imply that
wanting it to halt or throw an exception on errors is wrongheaded.

I just wanted to make sure the counter-case to what Paul was saying
also got heard: Yes-- underflows  or infinities  where they aren't 
expected are usually a sign that something is very wrong somewhere.
But in the case where the vector holds independent observations or
data points, then usually what it means is that there's something
wrong with *that* data point -- miscallibrated or mislabeled -- but
no reason not to complete the calculations for all of the other
points. 

Scaling or doing projections for interactive graphics is another
case where bad points are often better than throwing an exception.
( And it's a pain to have to remember to lambda wrap all the function
calls with some sort of guard when you'ld be happy to get NaNs. ) 

I also mostly agree with Tim, except that I'm not sure that bad or
incomplete ieee support is always better than none at all.

---|  Steven D. Majewski   (804-982-0831)  <sdm7g at Virginia.EDU>  |---
---|  Department of Molecular Physiology and Biological Physics  |---
---|  University of Virginia             Health Sciences Center  |---
---|  P.O. Box 10011            Charlottesville, VA  22906-0011  |---
		"All operating systems want to be unix, 
		 All programming languages want to be lisp." 




From thomas at xs4all.net  Thu Oct 12 21:14:37 2000
From: thomas at xs4all.net (Thomas Wouters)
Date: Thu, 12 Oct 2000 21:14:37 +0200
Subject: [Python-Dev] Re: getopt() prototype [was: checkin-message of something or other]
In-Reply-To: <200010121711.KAA00584@slayer.i.sourceforge.net>; from fdrake@users.sourceforge.net on Thu, Oct 12, 2000 at 10:11:41AM -0700
References: <200010121711.KAA00584@slayer.i.sourceforge.net>
Message-ID: <20001012211436.Z12812@xs4all.nl>

On Thu, Oct 12, 2000 at 10:11:41AM -0700, Fred L. Drake wrote:

[ use -Wall and -Wstrict-prototypes by default, if the compiler is gcc ]

> There is one known warning at this time, caught by the -Wstrict-prototypes
> option.  In Modules/main.c, the declaration of getopt() without parameters
> gets a complaint (rightly) that it is not a proper prototype.  The lack of
> a complete prototype information should be corrected when the right
> portability conditions have been identified.

I already looked at this before, and the problem is that the prototype for
getopt is not portable (because of quirks in the ANSI C standard regarding
'compatible' pointer types.) Some systems define it as 'const char **' (or
'char const **'), some perhaps as 'char **', and some as 'char * const *'.
'const char **' and 'char const **' are the same, but 'char * const *' is
something else, and so is 'char **'. 'char * const *' and 'char **' are
equivalent types, meaning that conforming compilers should be able to
intermix them without problems, but 'const char **' is a different type, and
ANSI C either demands or strongly suggests a warning.

(Why exactly it's a different type is mostly a choice of language, though
I'm sure there are people who would defend the choice. What it means it that
you can't mix two layers of indirection with qualifiers like 'const' or
'volatile', without paying close attention to assignment and prototypes :P)

As a result, no matter what prototype we think up, we're always screwing
either the one type of platform or the other. And not with a warning; the
conflicting prototype would generate an error, nto a warning. The only
solution I can think of is adding the proper prototype to the pyport.h
header file, inside a proper #ifdef. For generated code it doesn't really
matter which of the prototypes is used, but if the system headers do
provide a prototype, and it doesn't match in indirect-constness, compilation
will fail. 

(In other words, even on the platforms that are missing it, close attention
should be paid to the manual pages, trying to guess what the prototype is
going to look like if that particular system would ever grow a prototype in
a system header. From what I read in the getopt(3) manpage on my linux box
the prototype mixup comes from a POSIX.2 flaw, but I'm not sure.)

Does anyone have a system where the prototype to getopt() is not defined in
header files ? My Solaris 2.x testbox has that problem, but the box in
question is one huge mess, and I doubt it has anything to do with Solaris in
particular. I only use it to reproduce reported bugs, not report any myself
;P

-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!



From jeremy at beopen.com  Thu Oct 12 22:10:50 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Thu, 12 Oct 2000 16:10:50 -0400 (EDT)
Subject: [Python-Dev] test_minidom non-failure failure? (take 2)
In-Reply-To: <20001012032448.A18407@glacier.fnational.com>
References: <14821.58057.358947.271778@bitdiddle.concentric.net>
	<20001012023134.A18254@glacier.fnational.com>
	<200010121739.MAA07968@cj20424-a.reston1.va.home.com>
	<20001012032448.A18407@glacier.fnational.com>
Message-ID: <14822.6858.920988.167252@bitdiddle.concentric.net>

>>>>> "NS" == Neil Schemenauer <nas at arctrix.com> writes:

  NS> The -l option tries to find any cyclic garbage produced by the
  NS> tests.  I don't think that that option should be enabled
  NS> default.  The output means that the GC is working and is finding
  NS> stuff that would not be freed by reference counting alone.

  NS> I can't tell if the GC would free this garbage.  The -l option
  NS> sets the DEBUG_SAVEALL option which causes all garbage found to
  NS> end up in gc.garbage, not just garbage the can't be cleaned up.

  NS> I don't have pyexpat installed here so I can't test it.  If you
  NS> want to find out if test_minidom is creating garbage the
  NS> collector can't free you should comment out the:

  NS>     gc.set_debug(gc.DEBUG_SAVEALL)

  NS> line in regrtest.py and run:

  NS>     regrtest.py -l test_minidom

  NS> If that does what I think it does and you still get the
  NS> "garbage: " line then the test is creating evil things.  :)

The test is not creating evil things.  I commented out the
DEBUG_SAVEALL line and got no error report.

The question, then, is what to do about the -l option.  I assume we
should remove the -l option from the Makefile, so that "make test"
doesn't turn on DEBUG_SAVEALL.  Or do we need to change regrtest in
some way so that it still reports on tests that create evil things?

Jeremy



From nas at arctrix.com  Thu Oct 12 15:20:10 2000
From: nas at arctrix.com (Neil Schemenauer)
Date: Thu, 12 Oct 2000 06:20:10 -0700
Subject: [Python-Dev] test_minidom non-failure failure? (take 2)
In-Reply-To: <14822.6858.920988.167252@bitdiddle.concentric.net>; from jeremy@beopen.com on Thu, Oct 12, 2000 at 04:10:50PM -0400
References: <14821.58057.358947.271778@bitdiddle.concentric.net> <20001012023134.A18254@glacier.fnational.com> <200010121739.MAA07968@cj20424-a.reston1.va.home.com> <20001012032448.A18407@glacier.fnational.com> <14822.6858.920988.167252@bitdiddle.concentric.net>
Message-ID: <20001012062010.A19026@glacier.fnational.com>

On Thu, Oct 12, 2000 at 04:10:50PM -0400, Jeremy Hylton wrote:
> The question, then, is what to do about the -l option.  I assume we
> should remove the -l option from the Makefile, so that "make test"
> doesn't turn on DEBUG_SAVEALL.  Or do we need to change regrtest in
> some way so that it still reports on tests that create evil things?

This is a policy decision.  Is it okay for the test suite to
create garbage that is not collectable by reference counting?  If
yes, what about garbage that is not collectable by the (current)
GC?  

  Neil



From guido at python.org  Thu Oct 12 23:21:39 2000
From: guido at python.org (Guido van Rossum)
Date: Thu, 12 Oct 2000 16:21:39 -0500
Subject: [Python-Dev] test_minidom non-failure failure? (take 2)
In-Reply-To: Your message of "Thu, 12 Oct 2000 16:10:50 -0400."
             <14822.6858.920988.167252@bitdiddle.concentric.net> 
References: <14821.58057.358947.271778@bitdiddle.concentric.net> <20001012023134.A18254@glacier.fnational.com> <200010121739.MAA07968@cj20424-a.reston1.va.home.com> <20001012032448.A18407@glacier.fnational.com>  
            <14822.6858.920988.167252@bitdiddle.concentric.net> 
Message-ID: <200010122121.QAA09024@cj20424-a.reston1.va.home.com>

> The question, then, is what to do about the -l option.  I assume we
> should remove the -l option from the Makefile, so that "make test"
> doesn't turn on DEBUG_SAVEALL.

This seems to make sense, yes.  Since the "leaked" objects that are
found will be released by the GC code, I see no point in reporting
these during the regression test.  This can only confuse people (like
it did Jeremy :-).

> Or do we need to change regrtest in
> some way so that it still reports on tests that create evil things?

Any form of evilness that can be detected without *too* much effort is
worth it...  I have no idea what kind of evil we're looking for here
or how to detect is, so I can't answer yes or no.

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



From fdrake at beopen.com  Thu Oct 12 22:18:15 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Thu, 12 Oct 2000 16:18:15 -0400 (EDT)
Subject: [Python-Dev] New development documentation up...
Message-ID: <14822.7303.953870.727070@cj42289-a.reston1.va.home.com>

  I don't normally post when I've updated the development copy of the
documentation, but there are a couple of big additions there now.
  Martin von L?wis contributed substantial SAX2 documentation, which
I've now integrated.  Thanks, Martin!
  Chris Barker is working on new documentation for the Macintosh
manual; I've only just started to look at it, but there's definately a
*lot* of new material.  That's not checked into CVS yet, but will be
once I've had more time to go over it.  Thanks, Chris!

	ftp://python.beopen.com/pub/docco/devel/index.html


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From nas at arctrix.com  Thu Oct 12 15:28:04 2000
From: nas at arctrix.com (Neil Schemenauer)
Date: Thu, 12 Oct 2000 06:28:04 -0700
Subject: [Python-Dev] test_minidom non-failure failure? (take 2)
In-Reply-To: <200010122121.QAA09024@cj20424-a.reston1.va.home.com>; from guido@python.org on Thu, Oct 12, 2000 at 04:21:39PM -0500
References: <14821.58057.358947.271778@bitdiddle.concentric.net> <20001012023134.A18254@glacier.fnational.com> <200010121739.MAA07968@cj20424-a.reston1.va.home.com> <20001012032448.A18407@glacier.fnational.com> <14822.6858.920988.167252@bitdiddle.concentric.net> <200010122121.QAA09024@cj20424-a.reston1.va.home.com>
Message-ID: <20001012062804.B19026@glacier.fnational.com>

On Thu, Oct 12, 2000 at 04:21:39PM -0500, Guido van Rossum wrote:
> Any form of evilness that can be detected without *too* much effort is
> worth it...  I have no idea what kind of evil we're looking for here
> or how to detect is, so I can't answer yes or no.

That would be reference cycles with finalizers (ie. instances
with __del__ methods).  The current garbage collector does not
free such structures but instead appends them to gc.garbage.
Sorry for not being clear.

In any case, regrtest should probably print a more clueful
message when objects are found in gc.garbage.  That would go a
long way in clearing up the confusion.  I'll see about a patch.

  Neil



From guido at python.org  Thu Oct 12 23:26:49 2000
From: guido at python.org (Guido van Rossum)
Date: Thu, 12 Oct 2000 16:26:49 -0500
Subject: [Python-Dev] test_minidom non-failure failure? (take 2)
In-Reply-To: Your message of "Thu, 12 Oct 2000 06:20:10 MST."
             <20001012062010.A19026@glacier.fnational.com> 
References: <14821.58057.358947.271778@bitdiddle.concentric.net> <20001012023134.A18254@glacier.fnational.com> <200010121739.MAA07968@cj20424-a.reston1.va.home.com> <20001012032448.A18407@glacier.fnational.com> <14822.6858.920988.167252@bitdiddle.concentric.net>  
            <20001012062010.A19026@glacier.fnational.com> 
Message-ID: <200010122126.QAA09072@cj20424-a.reston1.va.home.com>

> This is a policy decision.  Is it okay for the test suite to
> create garbage that is not collectable by reference counting?

I don't see why that should be forbidden.  After all some of the code
we test has such leaks -- we haven't declared those absolute bugs.

> If yes, what about garbage that is not collectable by the (current)
> GC?

Can you give an example of how such garbage can be created?

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



From jeremy at beopen.com  Thu Oct 12 22:38:29 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Thu, 12 Oct 2000 16:38:29 -0400 (EDT)
Subject: [Python-Dev] test_minidom non-failure failure? (take 2)
In-Reply-To: <20001012062804.B19026@glacier.fnational.com>
References: <14821.58057.358947.271778@bitdiddle.concentric.net>
	<20001012023134.A18254@glacier.fnational.com>
	<200010121739.MAA07968@cj20424-a.reston1.va.home.com>
	<20001012032448.A18407@glacier.fnational.com>
	<14822.6858.920988.167252@bitdiddle.concentric.net>
	<200010122121.QAA09024@cj20424-a.reston1.va.home.com>
	<20001012062804.B19026@glacier.fnational.com>
Message-ID: <14822.8517.675600.578272@bitdiddle.concentric.net>

>>>>> "NS" == Neil Schemenauer <nas at arctrix.com> writes:

  NS> In any case, regrtest should probably print a more clueful
  NS> message when objects are found in gc.garbage.  That would go a
  NS> long way in clearing up the confusion.  I'll see about a patch.

I think there is some value to issueing reports when a test creates
trash that can't be cleaned up by the GC, but it doesn't make sense to
report this by default.  If "make test" reports an error, it should
mean that something has gone wrong with the user's build and the
interpreter is broken.  That's not the case here.  The build was fine;
it's just the test that is iffy.

I think we should turn of the -l option by default *and* patch it so
that the output is more useful.  I would suggest printing a count of
the objects, perhaps organized by type/class name.  Something like
this: 

    Test created 6 uncollectable objects
    4 foo.Bar instances
    2 foo.Baz instances

Jeremy



From tim_one at email.msn.com  Thu Oct 12 22:33:41 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Thu, 12 Oct 2000 16:33:41 -0400
Subject: [Python-Dev] RE: [Numpy-discussion] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison)
In-Reply-To: <Pine.A32.3.90.1001012140201.14856A-100000@elvis.med.Virginia.EDU>
Message-ID: <LNBBLJKPBEHFEDALKOLCEEACHLAA.tim_one@email.msn.com>

[Steven D. Majewski]
> ...
> I also mostly agree with Tim, except that I'm not sure that bad or
> incomplete ieee support is always better than none at all.

This is true, because having Python is better than not having Python, and in
having Python you indeed have bad *and* incomplete 754 support on every 754
platform it runs on.  Even better, it's a subset of damaged 754 support
unique to each platform whose details can't be guessed or documented in
advance of trying it exhaustively to see what happens(*), and a subset that
can change delightfully across releases, compiler upgrades, library upgrades
and seemingly irrelevant minor config changes.  So if bad or incomplete IEEE
support is good, Python is-- here as elsewhere --the King of Languages
<wink>.

Every step of this dance is thoroughly predictable.  In this case, I'm doing
my darnedest to nudge Python its very first step towards *real* 754 support,
and getting dumped on for it by a 754 fan.  Simultaneously, the "old guard"
defends their lifestyle against new-fangled ideas <wink>, asking for
protections unaware that 754 *requires* they get a better form of the
protections they seek than they've dreamed of so far.  It appears that
nobody on either side has actually read the std, and I've become the very
754 Storm Trooper I used to despise.  Computer life is great <wink>.

all-it's-missing-is-variety-ly y'rs  - tim


(*) Quiz:  *if* you can manage to trick Python into creating a NaN on your
particular 754 platform, does the Python expression NaN == 1.0 return true,
false, or raise an exception?  Answer before you try it.  Then try it on
enough 754 platforms until you give up trying to guess in advance.  NaN ==
NaN is predictable in Python, and is the one 754 feature Python guarantees
won't work correctly on any 754 platform (although I've heard that it loses
this predictability when run using NumPy's flavor of comparisons instead of
core Python's).





From nas at arctrix.com  Thu Oct 12 15:43:09 2000
From: nas at arctrix.com (Neil Schemenauer)
Date: Thu, 12 Oct 2000 06:43:09 -0700
Subject: [Python-Dev] test_minidom non-failure failure? (take 2)
In-Reply-To: <200010122126.QAA09072@cj20424-a.reston1.va.home.com>; from guido@python.org on Thu, Oct 12, 2000 at 04:26:49PM -0500
References: <14821.58057.358947.271778@bitdiddle.concentric.net> <20001012023134.A18254@glacier.fnational.com> <200010121739.MAA07968@cj20424-a.reston1.va.home.com> <20001012032448.A18407@glacier.fnational.com> <14822.6858.920988.167252@bitdiddle.concentric.net> <20001012062010.A19026@glacier.fnational.com> <200010122126.QAA09072@cj20424-a.reston1.va.home.com>
Message-ID: <20001012064309.C19026@glacier.fnational.com>

On Thu, Oct 12, 2000 at 04:26:49PM -0500, Guido van Rossum wrote:
> > This is a policy decision.  Is it okay for the test suite to
> > create garbage that is not collectable by reference counting?
> 
> I don't see why that should be forbidden.  After all some of the code
> we test has such leaks -- we haven't declared those absolute bugs.

Again, "-l" should probably not be a default.  I don't know who
added it to TESTOPTS but it wasn't me.

> Can you give an example of how such garbage can be created?

Look at test_gc.  Here is an example:

    class Foo:
        def __del__(self):
            pass
    foo = Foo()
    foo.foo = foo
    del foo

Theoretically this structure could be collected without problem
but the GC is too simple minded to realize that there is only one
finalizer involved.  Here's a better example:

    foo = Foo()
    bar = Foo()
    foo.bar = bar
    bar.foo = foo
    del foo, bar

The GC cannot safely break this cycle so it punts and adds the
instance objects involved to gc.garbage and forgets about it.

  Neil



From tim_one at email.msn.com  Thu Oct 12 23:38:13 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Thu, 12 Oct 2000 17:38:13 -0400
Subject: [Python-Dev] Re: getopt() prototype [was: checkin-message of something or other]
In-Reply-To: <20001012211436.Z12812@xs4all.nl>
Message-ID: <LNBBLJKPBEHFEDALKOLCIEAGHLAA.tim_one@email.msn.com>

[Thomas Wouters, on getopt]
> ...
> From what I read in the getopt(3) manpage on my linux box the
> prototype mixup comes from a POSIX.2 flaw, but I'm not sure.)

I bet it's actually talking about Interpretation 150 to POSIX.2, here (while
you can't read the std online, you can read the complaints online!):

http://standards.ieee.org/reading/ieee/interp/1003-2-92_int/pasc-1003.2-150.
html

Doesn't have anything to do with the prototype, alas.

> Does anyone have a system where the prototype to getopt() is not
> defined in header files ? My Solaris 2.x testbox has that problem, but
> the box in question is one huge mess, and I doubt it has anything to do
> with Solaris in particular. ...

Sure:  Windows doesn't have a getopt; getopt isn't std C (not even in C99).
Assorted derived stds demand that a getopt protoptype appear in stdlib.h,
and others that it appear in unistd.h.

I have a different suggestion:  screw it.  getopt keeps creating problems on
GNUish systems too, because without the POSIXLY_CORRECT envar set, the GNU
getopt shuffles all the "option strings" to the front, making a mess of,
e.g.,

python myprog.py -v

The Python source tree already has its own getopt implementation
(Python/getopt.c) -- let's rename its contained function to PyOS_Getopt, get
rid of the irritating __BEOS__ #ifdef'ery therein, prototype it the way we
like, and have Python use that instead on all systems.  Every second we've
spent tracking down problems with platform-supplied getopts has been a waste
of time.

they've-had-21-years-to-straighten-out-"the-std"-getopt-and-they-blew-it-
    ly y'rs  - tim





From jack at oratrix.nl  Fri Oct 13 00:03:57 2000
From: jack at oratrix.nl (Jack Jansen)
Date: Fri, 13 Oct 2000 00:03:57 +0200
Subject: [Python-Dev] MacPython 2.0c1 available
Message-ID: <20001012220402.ABE8D104729@oratrix.oratrix.nl>

MacPython 2.0c1 is available, both as binary installer and in source
form. You can find it through
http://www.cwi.nl/~jac/macpython.html. If people give it a testdrive
please let me know whether it works, and, in the unlikely event it
doesn't:-) what the problems are.

Thanks,
--
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/ ++++



From guido at python.org  Fri Oct 13 01:07:28 2000
From: guido at python.org (Guido van Rossum)
Date: Thu, 12 Oct 2000 18:07:28 -0500
Subject: [Python-Dev] Re: getopt() prototype [was: checkin-message of something or other]
In-Reply-To: Your message of "Thu, 12 Oct 2000 17:38:13 -0400."
             <LNBBLJKPBEHFEDALKOLCIEAGHLAA.tim_one@email.msn.com> 
References: <LNBBLJKPBEHFEDALKOLCIEAGHLAA.tim_one@email.msn.com> 
Message-ID: <200010122307.SAA09493@cj20424-a.reston1.va.home.com>

> I have a different suggestion:  screw it.  getopt keeps creating problems on
> GNUish systems too, because without the POSIXLY_CORRECT envar set, the GNU
> getopt shuffles all the "option strings" to the front, making a mess of,
> e.g.,
> 
> python myprog.py -v
> 
> The Python source tree already has its own getopt implementation
> (Python/getopt.c) -- let's rename its contained function to PyOS_Getopt, get
> rid of the irritating __BEOS__ #ifdef'ery therein, prototype it the way we
> like, and have Python use that instead on all systems.  Every second we've
> spent tracking down problems with platform-supplied getopts has been a waste
> of time.

Excellent.  After 2.0.

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



From thomas at xs4all.net  Fri Oct 13 00:18:01 2000
From: thomas at xs4all.net (Thomas Wouters)
Date: Fri, 13 Oct 2000 00:18:01 +0200
Subject: [Python-Dev] Re: getopt() prototype [was: checkin-message of something or other]
In-Reply-To: <LNBBLJKPBEHFEDALKOLCIEAGHLAA.tim_one@email.msn.com>; from tim_one@email.msn.com on Thu, Oct 12, 2000 at 05:38:13PM -0400
References: <20001012211436.Z12812@xs4all.nl> <LNBBLJKPBEHFEDALKOLCIEAGHLAA.tim_one@email.msn.com>
Message-ID: <20001013001801.A12812@xs4all.nl>

On Thu, Oct 12, 2000 at 05:38:13PM -0400, Tim Peters wrote:
> [Thomas Wouters, on getopt]
> > ...
> > From what I read in the getopt(3) manpage on my linux box the
> > prototype mixup comes from a POSIX.2 flaw, but I'm not sure.)
> 
> I bet it's actually talking about Interpretation 150 to POSIX.2, here (while
> you can't read the std online, you can read the complaints online!):

> http://standards.ieee.org/reading/ieee/interp/1003-2-92_int/pasc-1003.2-150.
> html

> Doesn't have anything to do with the prototype, alas.

Ah, that sounds about right. Nifty link, too. I thought it had something to
do with the prototype because of this comment:

CONFORMING TO
       getopt():
              POSIX.2,    provided   the   environment   variable
              POSIXLY_CORRECT is set.  Otherwise, the elements of
              argv  aren't really const, because we permute them.
              We pretend they're const in  the  prototype  to  be
              compatible with other systems.


> I have a different suggestion:  screw it.  getopt keeps creating problems on
> GNUish systems too, because without the POSIXLY_CORRECT envar set, the GNU
> getopt shuffles all the "option strings" to the front, making a mess of
  [ a lot of things ]

Ahh, yes, I see Python/getopt.c and the autoconf check that enables it when
necessary. Funny, I've seen that file a number of times, and read it, and
read the getopt autoconf test as well, but somehow I never connected it with
the loose prototype in main.c. I'm +1 on doing what you suggested, then.

Wonder why it hasn't been done yet, though... we have no use for a
system-wide getopt, except for a slightly smaller binary on systems that do
have a 'good' system getopt. We can't use enhancements made to system getopt
or anything, anyway.

> they've-had-21-years-to-straighten-out-"the-std"-getopt-and-they-blew-it-
>     ly y'rs  - tim

what-do-you-want-to-bet-it's-going-to-take-longer-for-Python-getopt-modules-
	ly y'rs,

-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!



From m.favas at per.dem.csiro.au  Fri Oct 13 02:47:25 2000
From: m.favas at per.dem.csiro.au (Mark Favas)
Date: Fri, 13 Oct 2000 08:47:25 +0800
Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich
 comparison)
Message-ID: <39E65B9D.B9F6BA70@per.dem.csiro.au>

Just a little unreality check - the whole world is not (yet) Linux - or
even MS. The behaviour of math.exp(-746) on my flavours of 1.5.2 on
Solaris boxes and DEC Alphas (Tru64 Unix) is the same as the behaviour
of 2.0 - OverflowError: math range error. Thus, on these platform, the
proposed fixes _will_ change behaviour. But that's cool - I like Tim's
proposed, um, steps to "rationalizing" fp behaviour, and will do what I
can to help in the future.
-- 
Email - m.favas at per.dem.csiro.au
        CSIRO Exploration & Mining



From tim_one at email.msn.com  Fri Oct 13 07:15:13 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Fri, 13 Oct 2000 01:15:13 -0400
Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich  comparison)
In-Reply-To: <39E65B9D.B9F6BA70@per.dem.csiro.au>
Message-ID: <LNBBLJKPBEHFEDALKOLCCEBBHLAA.tim_one@email.msn.com>

[Mark Favas]
> Just a little unreality check - the whole world is not (yet) Linux - or
> even MS. The behaviour of math.exp(-746) on my flavours of 1.5.2 on
> Solaris boxes and DEC Alphas (Tru64 Unix) is the same as the behaviour
> of 2.0 - OverflowError: math range error.

This is unfortunate.  Guido never intended for Python to raise exceptions on
underflow (and especially not *Over*flowError(!)), but he apparently didn't
run on any platforms where this happened (I never have!), and AFAIK nobody
ever mentioned this before.

> Thus, on these platform, the proposed fixes _will_ change behaviour.

See "unfortunate" above <0.5 wink>.

> But that's cool - I like Tim's proposed, um, steps to "rationalizing"
> fp behaviour, and will do what I can to help in the future.

Want to fund a crack group of 754 experts for a year?  Didn't think so.
Constructive complaints will help a lot.  So will beta testing.  For
example, I'm very keen to know whether the current CVS version of Python
(2.0c1) still raises OverflowError for math.exp(-746) on your Solaris and/or
Tru64 Unix boxes.  Running the (current CVS) std test suite will tell you:
test_libm will pass or fail accordingly.  If it's still busted on one of
your systems, we've only got about a day to fix it (2.0 final is shipping
early next week, and we have to let the codebase settle down for a couple
days before building the final release).

but-since-it's-been-a-random-mess-for-a-decade-already-i'm-not-
    losing-much-sleep-over-it-ly y'rs  - tim





From tim_one at email.msn.com  Fri Oct 13 07:18:52 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Fri, 13 Oct 2000 01:18:52 -0400
Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich  comparison)
In-Reply-To: <LNBBLJKPBEHFEDALKOLCCEBBHLAA.tim_one@email.msn.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCKEBBHLAA.tim_one@email.msn.com>

[Tim hallucinated ...]
> ... I'm very keen to know whether the current CVS version of Python
> (2.0c1) still raises OverflowError for math.exp(-746) on your
> Solaris and/or Tru64 Unix boxes.

Sorry for contradicting myself within a single sentence:  I couldn't care
less what happens in 2.0c1 anymore.  Like I clearly said at the start,
"current CVS version" is the question.





From bwarsaw at beopen.com  Fri Oct 13 07:33:57 2000
From: bwarsaw at beopen.com (Barry A. Warsaw)
Date: Fri, 13 Oct 2000 01:33:57 -0400 (EDT)
Subject: [Python-Dev] test_minidom non-failure failure? (take 2)
References: <14821.58057.358947.271778@bitdiddle.concentric.net>
	<20001012023134.A18254@glacier.fnational.com>
	<200010121739.MAA07968@cj20424-a.reston1.va.home.com>
	<20001012032448.A18407@glacier.fnational.com>
	<14822.6858.920988.167252@bitdiddle.concentric.net>
	<20001012062010.A19026@glacier.fnational.com>
	<200010122126.QAA09072@cj20424-a.reston1.va.home.com>
	<20001012064309.C19026@glacier.fnational.com>
Message-ID: <14822.40645.656159.493390@anthem.concentric.net>

>>>>> "NS" == Neil Schemenauer <nas at arctrix.com> writes:

    NS> Again, "-l" should probably not be a default.  I don't know
    NS> who added it to TESTOPTS but it wasn't me.

I did, but at the time -l set LEAK_DEBUG not DEBUG_SAVEALL, and I
think (but don't really remember) that LEAK_DEBUG had different
semantics than it does now.

No matter.  This was useful when gc was spankin' new and only
semi-tested.  It's probably fine to turn off -l in "make test" by
default for the 2.0 release.

-Barry



From tim_one at email.msn.com  Fri Oct 13 10:01:16 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Fri, 13 Oct 2000 04:01:16 -0400
Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison)
In-Reply-To: <slrn8ucd0a.4id.hzhu@localhost.localdomain>
Message-ID: <LNBBLJKPBEHFEDALKOLCIEBCHLAA.tim_one@email.msn.com>

[Tim]
> ...
> We cannot consider this to be a bug since Python has had no *intended*
> behavior whatsoever wrt 754 gimmicks.  We can and do consider gripes
> about these accidents to be feature requests.

[Huaiyu Zhu]
> Yes it varies widely in Python.  But isn't that precisely because Python
> does not support IEEE?

Yes, but that's darned near tautological <0.5 wink>.

> If Python does not actively undermine IEEE on platforms that have it,
> would it still vary widely across these platforms?

Yes.  Your own -lieee example showed that math.sqrt(-1) computes not only a
non-754 result, but a senseless result, on your platform under 1.5.2.  If I
show you a platform, how are you going to decide whether it "has" IEEE?  754
is a very involved std, and it's still rare to find a platform C that
supports it correctly.  On platform C's that do support it correctly, I know
of none that do so without requiring platform-specific tricks.  Python has
*nothing* portable it can rely on, and its mass of utterly non-754-aware
code building on haphazard C implementations adds up to the random
x-platform crap we have today.

...
[T]
> The patch to stop setting -lieee was contributed by a Python user who
> claimed it fixed bugs on *their* platform.  That's "the reason".
> We don't want to screw them either.

[H]
> Q: What bug?  Which platform?  Maybe there is another way that has less
>    impact on others?  How to find out?

I didn't check it in, and you can search the CVS archives as easily as I can
(I'm not inclined to, since I don't think it can affect the outcome of
this).  Jeremy Hylton may, or may not, remember more about it (IIRC, he said
he checked it in).

> ...
> If there is a way to fix the bug on that other platform while still keep
> -lieee on Linux, would that be acceptable?

No:  Guido *wants* overflow to raise OverflowError by default, and *wants*
sqrt(-1.0) to raise ValueError by default.  Python's x-platform fp numerics
today are an utter mess, and the best we can do for 2.0 is to make them as
consistent as we have time to make them, despite that we know it will break
some of your code (but you can still link with -lieee if you feel you must),
and that Mark Favas has confirmed it will break code under both his Solaris
and Tru64 Unix systems (but for a reason opposite of yours:  he's been
getting OverflowError on underflow since 1.5.2, and we're taking that away
from him, and he'll have *no* way to go back).  At this point we favor
forcing consistency over maintaining platform accidents, no matter how
attached people have gotten to them; else we'll be stuck with them forever.

[oh some of Kahan's papers, at http://http.cs.berkeley.edu/~wkahan/]
> Interesting! I've glanced through some of Prof Kahan's writings.

He is an entertaining writer, although his rhetoric is often more extreme
than either of ours <wink>.

> It appears that he favors raising flags that can be checked optionally,
and
> he is against mandatary raising exceptions.

Have you read the 754 std?  He's in favor of the 754 std.

[quotes snipped, except for my favorite, which I've paraphrased many times
 over the years on c.l.py]
> ...
>   They are called "Exceptions" because to any policy for handling them,
>   imposed in advance upon all programmers by the computer system, some
>   programmers will have good reason to take exception.

> ...
> From these quotes and others I understand that he wants f.p. exceptions to
> be merely messanges, not errors that force programmers to take extra
> actions, unless the programmer choose to.  So what aspect of Java did he
> think is deficient?  It is the "Trap" style exception that mandate a users
> action.

His paper "How JAVA's Floating-Point Hurts Everyone Everywhere" lists his 5
main gripes about Java in bullet points at the top of page 3.  The paper
runs on to 80 pages.  You somehow managed to miss 79.89 of them <0.4 wink>,
reducing it to a bogus claim about Java that Kahan didn't make (Java has
neither "Trap" nor "Flag" style fp exception signaling).

> He told "A cautionary Tale of the Ariane 5",

Which has nothing to do with Java -- the software in question was written in
Ada, which (unlike Java) has "Trap" style.  Why he put it in a paper about
Java is a bit of a mystery; I write it off to rhetorical excess.

> the European rocket that mulfunctioned after lift off.  It turned out
> that a piece of software produced an unimportant exception that is
> not caught by a handler and caused debugging data to be dumped to a
> critical memory location.  This would have been avoided if the exception
> merely raised a flag and returned a NaN, and the program continued.

Actually, that was impossible to do, and he didn't suggest that.  What he
wrote is

    Had overflow merely obeyed the IEEE 754 default policy, the
    recalibration software would have raised a flag and delivered an
    invalid result both to be ignored by the motor guidance programs,
    and the Ariane 5 would have pursued its intended trajectory.

Note that he didn't say NaN.  He couldn't, because this was overflow in a
conversion from Float to Integer.  Despite his cheery optimism here, 754 is
approximately useless in this case, since there is no generally accepted
"invalid result" in integer formats (and 754 doesn't define one either --
the result of overflow in converting floats to ints is ill-defined in 754;
754 doesn't even require that it set the overflow flag).

> So do we want every Python program to bomb whenever there is a floating
> point value outside bound and is not trapped by try/except?

By default, yes, Guido does, but for overflow, not underflow.  If you read
the following section of Kahan's paper, you should have noticed that he is
*just* as critical of just returning Infs and NaNs (which is all Java does,
and which is the accidental Python behavior you're arguing we keep in glibc)
as he is of just trapping!  His conclusion:  "Without Traps nor Flags, Java?
s floating-point is Dangerous":

    Without flags, detecting rare creations of Inf and NaN before they
    disappear requires programmed tests and branches that, besides
    duplicating tests already performed by the hardware, slow down the
    program and impel a programmer to make decisions prematurely in many
    cases. Worse, a plethora of tests and branches undermines a program?s
    modularity, clarity and concurrency.

I agree with him there wholeheartedly:  without the 754-mandated flags,
*and* without raising exceptions, the subset of 754 remaining sucks.

>> ironically, 754 is hardest to sell to those who could benefit from
>> it the most.

> So far the only concern from number-crunchers voiced here is that it might
> allow sqrt(-1)==0, which is not the case.

Gimme a break!  In the very msg Paul Dubois said that, he also said "Some
people use Inf but most people want the code to STOP so they can find out
where the INFS started.  Otherwise, two hours later you have big arrays of
Infs and no idea how it happened.".  I'm starting to drop my assumption of
good faith on your part:  what you remember and how you paraphrase (whether
it's Paul or Kahan) is extremely selective, beyond normal bounds of
zeal-inspired distortion.

> I was a fortran programmer before.  I switched to using IEEE ten years
> ago as soon as it was available on the machine I was using.  So there
> are different opinions.

Certainly, and good 754 support will cater to most of them.  I don't believe
your opinion (or mine, for that matter) reflects anything even close to the
majority view here, though.  As I said in my reply to Paul, my observations
(based on 15 years on the vendor side of the fp biz) matched his exactly
(based on his experience with hundreds of numeric code authors):  a vast
majority still want divide-by-0, invalid operation, and overflow to raise an
exception the vast majority of the time.

> ...
> Obviously we agree on the benefit of having a choice.  But we
> have different perspective on what choice means.  Your want a choice
> to force user to take explicit action, I want a choice to ignore these
> events.

No.  I want exactly the choices 754 lays out:  user-settable sticky flags
and user-maskable exceptions.  We're not getting that for 2.0.  And we're
*never* getting it if 2.0 doesn't do *something* to start disabusing people
of the notion that their historical numeric platform accidents in Python
will be faithfully preserved forever more.

> The ideal solution might be to have a sys.fp_exception class.  Each
> exception would set a flag like fp_exception.overflow so that user can
> check them.  There could also be a variable like fp_exception.force_trap,
> which when set, could make each f.p. exception to produce a Python
> exception.  This would confirm to IEEE 754 and give both of us a choice
> we want.

Kinda, except that each of the 5 754-defined traps must be individually
maskable.  754 spells out what's needed.  A PEP will be required to spell
out the Python- and C-level APIs.  I've corresponded (just -- no time now) a
little with Kevin Jacobs about that offline.

> Now that we are in feature freeze for 2.0, we can't get both choices.
> Can we adopt the one that does not break behaviors on previous official
> release, even if that's only by accident?

Not as far as Guido or I are concerned, no.  You can link with -lieee
yourself if you must, although I can't recommend perpetuating the x-platform
confusion here.  We want to say that, e.g., math.exp works substantially the
same way on *all* platforms under 2.0, not repeat the same decade-old "umm,
don't know, and no way to guess -- try it on your platform and see what it
does" yet again.  I don't expect 2.0 will actually achieve that on all
platforms, but it should on the primary ones.

> ...
> So now I know why people reported that NaN and Inf were broken on HPUX
> and Windows and some others.  If Python had simply ignored the flags ...

Then we would have broken 754 subsets in slightly subtler ways, and still
wildly varying across platforms.

> ...
> Could you please point a URL to "presubstitution"?  In the paragraphs I
> quoted the only mention of presubstitute is with NaNs and Inf, etc.

Sorry, I don't save URLs, and don't recall whether this was in a paper or on
David Hough's "Numeric Interest" mailing list in the early 90's.  A Google
search on "presubstitution Kahan" turns up 4 promising-looking hits I'll
leave you to pursue.  The basic idea is that the programmer gets to specify,
via library calls (whatever), which particular fp value each 754 exceptional
case returns.  So, e.g., if it made sense for some part of the app, the
programmer could say they wanted +- pi returned instead +- Inf, if and
whenever overflow happened.  Then set it back to +- Inf (or anything else
they needed) later.  This would be best if supported in HW directly, of
course.

> ...
> You are not confirming to 754 until you allow all the exceptions to go
> through with well defined values as default.

I know that, but don't care.  As I said, enabling overflow + invalid + div0
by default is the only scheme that can be *sold*.  If you can find two NumPy
users in favor of disabling them all by default, I'll be mildly astonished.
754 did itself enormous harm by insisting on that trivial point (it's
trivial because, with proper support, anyone can change the defaults to
anything they like with one line of code):  I worked in the supercomputer
biz at the time 754 was adopted, and for a decade after, and the "non stop"
defaults were *universally* opposed by customers.  Scared the hell out of
language stds committees too, which goes a lot farther than the 754 folks
would like to admit toward explaining why language committees stayed away
from 754 bindings in droves.  C99 is 15 years(!) after the fact.

> Raising Python exceptions on some of them does not confirm to 754, as
> the default IEEE 754 behavior on f.p. exception is not a Python exception,
> but just a raised flag.

See above.

> Before that happens, what is the motive to make IEEE less usable for those
> who have it (pretty much every one nowadays), even if just by accident?

I think I've repeated the reasons to death already, and you've repeated to
death that you'll never agree.  So no more from me on that.

> ...
> But just to clarify some wordings you quoted in another post: I meant that
> sqrt(-1)==0 is insane, whether silent or not.

I agree.

> Raising an exception is sane,

Not according to 754's default rules, which you wanted me to take as sacred
just a few paragraphs ago <wink>.

> although OverflowError is not so reasonable.

I'd say it's insane.

> Raising a ValueError is reasonable.

I expect we'll have to make InvalidOperationError a subclass of ValueError
for that reason, when 754 support materializes.

> But just returning NaN without a fuss is even better.

You're going to find that's a very lonely position.

> My favorite is returning 1j, as MatPy does.

Then you should use cmath.sqrt instead of math.sqrt.  Even $3 business
calculators have a sqrt key these days, and you do not want to be on the
other end of email when trying to explain to a businessperson why their
crappy std deviation program returned a complex number <0.1 wink>.

> if-it-ain't-broke-don't-fix-it-ly y'rs

it-it-weren't-broke-we-wouldn't-ly y'rs  - tim





From fgranger at altern.org  Fri Oct 13 12:08:23 2000
From: fgranger at altern.org (Francois Granger)
Date: Fri, 13 Oct 2000 12:08:23 +0200
Subject: [Python-Dev] Re: [Pythonmac-SIG] MacPython 2.0c1 available
In-Reply-To: <20001012220402.ABE8D104729@oratrix.oratrix.nl>
Message-ID: <B60CABB6.14362%fgranger@altern.org>

on 13/10/00 0:03, Jack Jansen at jack at oratrix.nl wrote:

> MacPython 2.0c1 is available, both as binary installer and in source
> form. You can find it through
> http://www.cwi.nl/~jac/macpython.html.

This one works better.

http://www.cwi.nl/~jack/macpython.html


-- 
Fran?ois Granger
fgranger at altern.org




From nas at arctrix.com  Fri Oct 13 08:37:17 2000
From: nas at arctrix.com (Neil Schemenauer)
Date: Thu, 12 Oct 2000 23:37:17 -0700
Subject: [Python-Dev] test_minidom non-failure failure? (take 2)
In-Reply-To: <14822.40645.656159.493390@anthem.concentric.net>; from bwarsaw@beopen.com on Fri, Oct 13, 2000 at 01:33:57AM -0400
References: <14821.58057.358947.271778@bitdiddle.concentric.net> <20001012023134.A18254@glacier.fnational.com> <200010121739.MAA07968@cj20424-a.reston1.va.home.com> <20001012032448.A18407@glacier.fnational.com> <14822.6858.920988.167252@bitdiddle.concentric.net> <20001012062010.A19026@glacier.fnational.com> <200010122126.QAA09072@cj20424-a.reston1.va.home.com> <20001012064309.C19026@glacier.fnational.com> <14822.40645.656159.493390@anthem.concentric.net>
Message-ID: <20001012233717.A20054@glacier.fnational.com>

On Fri, Oct 13, 2000 at 01:33:57AM -0400, Barry A. Warsaw wrote:
> I think (but don't really remember) that LEAK_DEBUG had
> different semantics than it does now.

Nope.  LEAK_DEBUG prints to stderr information about all garbage
the GC finds, even stuff the GC can free.  The thinking was that
GC would be an option and people would want to find applications
that leak when only using reference counting.

> No matter.  This was useful when gc was spankin' new and only
> semi-tested.  It's probably fine to turn off -l in "make test" by
> default for the 2.0 release.

I've left -l enabled for now.  Detecting tests that create
uncollectable garbage is probably a good thing.  It doesn't cost
much and the message should be fairly clear now.

  Neil



From fdrake at beopen.com  Fri Oct 13 15:34:03 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Fri, 13 Oct 2000 09:34:03 -0400 (EDT)
Subject: [Python-Dev] test_minidom non-failure failure? (take 2)
In-Reply-To: <20001012233717.A20054@glacier.fnational.com>
References: <14821.58057.358947.271778@bitdiddle.concentric.net>
	<20001012023134.A18254@glacier.fnational.com>
	<200010121739.MAA07968@cj20424-a.reston1.va.home.com>
	<20001012032448.A18407@glacier.fnational.com>
	<14822.6858.920988.167252@bitdiddle.concentric.net>
	<20001012062010.A19026@glacier.fnational.com>
	<200010122126.QAA09072@cj20424-a.reston1.va.home.com>
	<20001012064309.C19026@glacier.fnational.com>
	<14822.40645.656159.493390@anthem.concentric.net>
	<20001012233717.A20054@glacier.fnational.com>
Message-ID: <14823.3915.245246.310674@cj42289-a.reston1.va.home.com>

Neil Schemenauer writes:
 > I've left -l enabled for now.  Detecting tests that create
 > uncollectable garbage is probably a good thing.  It doesn't cost
 > much and the message should be fairly clear now.

  Perhaps one thing that could be done is to reduce the volume of the
output; perhaps just list the first 1K or 2K of the repr?


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From nas at arctrix.com  Fri Oct 13 09:09:48 2000
From: nas at arctrix.com (Neil Schemenauer)
Date: Fri, 13 Oct 2000 00:09:48 -0700
Subject: [Python-Dev] test_minidom non-failure failure? (take 2)
In-Reply-To: <14823.3915.245246.310674@cj42289-a.reston1.va.home.com>; from fdrake@beopen.com on Fri, Oct 13, 2000 at 09:34:03AM -0400
References: <20001012023134.A18254@glacier.fnational.com> <200010121739.MAA07968@cj20424-a.reston1.va.home.com> <20001012032448.A18407@glacier.fnational.com> <14822.6858.920988.167252@bitdiddle.concentric.net> <20001012062010.A19026@glacier.fnational.com> <200010122126.QAA09072@cj20424-a.reston1.va.home.com> <20001012064309.C19026@glacier.fnational.com> <14822.40645.656159.493390@anthem.concentric.net> <20001012233717.A20054@glacier.fnational.com> <14823.3915.245246.310674@cj42289-a.reston1.va.home.com>
Message-ID: <20001013000948.C20054@glacier.fnational.com>

On Fri, Oct 13, 2000 at 09:34:03AM -0400, Fred L. Drake, Jr. wrote:
> Perhaps one thing that could be done is to reduce the volume of the
> output; perhaps just list the first 1K or 2K of the repr?

It just prints the number of object found now.

  Neil



From fdrake at beopen.com  Fri Oct 13 16:06:22 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Fri, 13 Oct 2000 10:06:22 -0400 (EDT)
Subject: [Python-Dev] test_minidom non-failure failure? (take 2)
In-Reply-To: <20001013000948.C20054@glacier.fnational.com>
References: <20001012023134.A18254@glacier.fnational.com>
	<200010121739.MAA07968@cj20424-a.reston1.va.home.com>
	<20001012032448.A18407@glacier.fnational.com>
	<14822.6858.920988.167252@bitdiddle.concentric.net>
	<20001012062010.A19026@glacier.fnational.com>
	<200010122126.QAA09072@cj20424-a.reston1.va.home.com>
	<20001012064309.C19026@glacier.fnational.com>
	<14822.40645.656159.493390@anthem.concentric.net>
	<20001012233717.A20054@glacier.fnational.com>
	<14823.3915.245246.310674@cj42289-a.reston1.va.home.com>
	<20001013000948.C20054@glacier.fnational.com>
Message-ID: <14823.5854.638859.950835@cj42289-a.reston1.va.home.com>

Neil Schemenauer writes:
 > It just prints the number of object found now.

  Ok, I must have missed the checkin that changed that.  This is fine
in my book as well.
  Thanks for staying on top of this work!  I think you've really done
a great job with the GC effort.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From cgw at fnal.gov  Fri Oct 13 17:18:23 2000
From: cgw at fnal.gov (Charles G Waldman)
Date: Fri, 13 Oct 2000 10:18:23 -0500 (CDT)
Subject: [Python-Dev] can't build with threads on OSF/1
Message-ID: <14823.10175.741638.857531@buffalo.fnal.gov>

Sorry, I don't have time to investigate this fully right now.  Maybe
this weekend.  For now this is just a heads-up.  Hopefully, something
is just misconfigured on this system.

The machine in question is running OSF1 V4.0 878 alpha

I can only build Python from current CVS sources on OSF/1 if I specify
--without-thread.   If I don't specify this I get the following errors
at link time:

Unresolved:
__pthread_mutex_init
__pthread_mutex_destroy
__pthread_mutex_lock
__pthread_mutex_unlock
__pthread_cond_init
__pthread_cond_destroy
__pthread_cond_signal
__pthread_cond_wait
__pthread_create
__pthread_detach

I tried sending a message with the output of ./configure and make
attached, but it was over the 40K limit.  If anybody wants to see
these, email me.



From nas at arctrix.com  Fri Oct 13 10:28:49 2000
From: nas at arctrix.com (Neil Schemenauer)
Date: Fri, 13 Oct 2000 01:28:49 -0700
Subject: [Python-Dev] can't build with threads on OSF/1
In-Reply-To: <14823.10175.741638.857531@buffalo.fnal.gov>; from cgw@fnal.gov on Fri, Oct 13, 2000 at 10:18:23AM -0500
References: <14823.10175.741638.857531@buffalo.fnal.gov>
Message-ID: <20001013012849.C20168@glacier.fnational.com>

On Fri, Oct 13, 2000 at 10:18:23AM -0500, Charles G Waldman wrote:
> Unresolved:
> __pthread_mutex_init
[...]

What is the LIBS variable set to in Modules/Makefile?  It looks
your missing something like "-lpthread".

  Neil



From cgw at fnal.gov  Fri Oct 13 17:35:52 2000
From: cgw at fnal.gov (Charles G Waldman)
Date: Fri, 13 Oct 2000 10:35:52 -0500 (CDT)
Subject: [Python-Dev] can't build with threads on OSF/1
In-Reply-To: <20001013012849.C20168@glacier.fnational.com>
References: <14823.10175.741638.857531@buffalo.fnal.gov>
	<20001013012849.C20168@glacier.fnational.com>
Message-ID: <14823.11224.545609.761307@buffalo.fnal.gov>

Neil Schemenauer writes:
 > On Fri, Oct 13, 2000 at 10:18:23AM -0500, Charles G Waldman wrote:
 > > Unresolved:
 > > __pthread_mutex_init
 > [...]
 > 
 > What is the LIBS variable set to in Modules/Makefile?  It looks
 > your missing something like "-lpthread".

Hehehe.  I might be kinda thick sometimes, but I think I would have
caught that.  Here's a little more of the "make" output:

cd Modules;  make OPT="-O -Olimit 1500" VERSION="2.0"  prefix="/usr/local" exec_prefix="/usr/local"  LIBRARY=../libpython2.0.a link
 cc   python.o  ../libpython2.0.a -ldb                                 -lpthreads -lm  -o python 
ld:
Unresolved:
__pthread_mutex_init
__pthread_mutex_destroy
__pthread_mutex_lock
__pthread_mutex_unlock
__pthread_cond_init
__pthread_cond_destroy
__pthread_cond_signal
__pthread_cond_wait
__pthread_create
__pthread_detach
*** Exit 1
Stop.
*** Exit 1
Stop.




From thomas at xs4all.net  Fri Oct 13 18:34:36 2000
From: thomas at xs4all.net (Thomas Wouters)
Date: Fri, 13 Oct 2000 18:34:36 +0200
Subject: [Python-Dev] can't build with threads on OSF/1
In-Reply-To: <14823.10175.741638.857531@buffalo.fnal.gov>; from cgw@fnal.gov on Fri, Oct 13, 2000 at 10:18:23AM -0500
References: <14823.10175.741638.857531@buffalo.fnal.gov>
Message-ID: <20001013183436.B12812@xs4all.nl>

On Fri, Oct 13, 2000 at 10:18:23AM -0500, Charles G Waldman wrote:

> Sorry, I don't have time to investigate this fully right now.  Maybe
> this weekend.  For now this is just a heads-up.  Hopefully, something
> is just misconfigured on this system.

> The machine in question is running OSF1 V4.0 878 alpha

That's a former DEC alpha, right ? Perhaps running configure with
'--with-dec-threads' will solve the problem ? I'm not sure if that will work
alone, so you might need '--with-dec-threads --with-threads=no' to disable
'normal' thread-checking. 

You can also try this by hand; after running configure, edit
Modules/Makefile.pre, and change

LDLAST=

into

LDLAST= -threads

(not -lthreads, just -threads) That seems to be the only difference
--with-dec-threads uses.

I looked at this before, but don't have an alpha or anything else that needs
--with-dec-threads, so I couldn't detect this automatically. I do think it
should be done automatically, though. Perhaps I can figure it if you can
send me, for instance, config.log and the output of configure, and find the
time to run a few tests later. 

> I can only build Python from current CVS sources on OSF/1 if I specify
> --without-thread.   If I don't specify this I get the following errors
> at link time:

> Unresolved:
> __pthread_mutex_init

> I tried sending a message with the output of ./configure and make
> attached, but it was over the 40K limit.  If anybody wants to see
> these, email me.

If the above doesn't fix it, I can take a look at the output of configure
and config.log. No need to see the output of make just yet.

-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!



From cgw at fnal.gov  Fri Oct 13 20:31:34 2000
From: cgw at fnal.gov (Charles G Waldman)
Date: Fri, 13 Oct 2000 13:31:34 -0500 (CDT)
Subject: [Python-Dev] can't build with threads on OSF/1
In-Reply-To: <20001013183436.B12812@xs4all.nl>
References: <14823.10175.741638.857531@buffalo.fnal.gov>
	<20001013183436.B12812@xs4all.nl>
Message-ID: <14823.21766.733905.575290@buffalo.fnal.gov>

Thomas Wouters writes:
 > 
 > That's a former DEC alpha, right ? Perhaps running configure with
 > '--with-dec-threads' will solve the problem ? I'm not sure if that will work
 > alone, so you might need '--with-dec-threads --with-threads=no' to disable
 > 'normal' thread-checking. 

Thank you, that indeed solves the problem.  Sorry for the noise.

It would be nice if configure were smart enough to figure this out!




From cgw at fnal.gov  Fri Oct 13 20:38:26 2000
From: cgw at fnal.gov (Charles G Waldman)
Date: Fri, 13 Oct 2000 13:38:26 -0500 (CDT)
Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee,
 and rich  comparison)
In-Reply-To: <LNBBLJKPBEHFEDALKOLCIECGHLAA.tim_one@email.msn.com>
References: <200010131453.JAA23050@buffalo.fnal.gov>
	<LNBBLJKPBEHFEDALKOLCIECGHLAA.tim_one@email.msn.com>
Message-ID: <14823.22178.605732.455689@buffalo.fnal.gov>

Tim Peters wrote:
 > I'm very keen to know whether the current CVS version of Python
 > (2.0c1) still raises OverflowError for math.exp(-746) on your
 > Solaris and/or Tru64 Unix boxes.

I just repeated this test, on the following 4 platforms:

1)   SunOS fsui02 5.6 Generic_105181-21 sun4u sparc SUNW,Ultra-Enterprise
     cc: WorkShop Compilers 4.2 30 Oct 1996 C 4.2

2)   OSF1 V4.0 878 alpha
     DEC C V5.6-079 on Digital UNIX V4.0 (Rev. 878)

3)   IRIX64 6.5 07151432 IP27
     MIPSpro Compilers: Version 7.2.1

4)   Linux 2.2.16 #31 SMP Thu Jun 29 14:51:26 CDT 2000 i686
     gcc version 2.95.2 19991024 (release)

On all of the above systems, math.exp(-999) returns 0.0, math.sqrt(-1)
raises an exception, and test_math.py completes successfully.

Testing-ly (not to be confused with testily) yr's,
		cgw



From tim_one at email.msn.com  Fri Oct 13 20:56:43 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Fri, 13 Oct 2000 14:56:43 -0400
Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich  comparison)
In-Reply-To: <14823.22178.605732.455689@buffalo.fnal.gov>
Message-ID: <LNBBLJKPBEHFEDALKOLCIECKHLAA.tim_one@email.msn.com>

[Charles G Waldman]
> I just repeated this test, on the following 4 platforms:
>
> 1)   SunOS fsui02 5.6 Generic_105181-21 sun4u sparc SUNW,Ultra-Enterprise
>      cc: WorkShop Compilers 4.2 30 Oct 1996 C 4.2
>
> 2)   OSF1 V4.0 878 alpha
>      DEC C V5.6-079 on Digital UNIX V4.0 (Rev. 878)
>
> 3)   IRIX64 6.5 07151432 IP27
>      MIPSpro Compilers: Version 7.2.1
>
> 4)   Linux 2.2.16 #31 SMP Thu Jun 29 14:51:26 CDT 2000 i686
>      gcc version 2.95.2 19991024 (release)
>
> On all of the above systems, math.exp(-999) returns 0.0, math.sqrt(-1)
> raises an exception, and test_math.py completes successfully.

Excellent!  Note that test_math.py was augmented to verify that:

1. exp(-huge) returns 0 without exception.
2. exp(+huge) raises OverflowError.
3. sqrt(-1) raises ValueError.

None of those were reliable across platforms before, and I'm afraid there's
strong reason to suspect one or more still won't work right under Mandrake
Linux when Python is compiled with -O (this based on the output of a C
program someone posted to c.l.py yesterday).    But it's a world better than
it used to be.

> Testing-ly (not to be confused with testily) yr's,

You bet -- everyone leave testily to me on this one.  I'm bitter enough
about floating-point in stinking C for everyone combined <0.9 wink>.





From thomas at xs4all.net  Fri Oct 13 21:19:38 2000
From: thomas at xs4all.net (Thomas Wouters)
Date: Fri, 13 Oct 2000 21:19:38 +0200
Subject: [Python-Dev] can't build with threads on OSF/1
In-Reply-To: <14823.21766.733905.575290@buffalo.fnal.gov>; from cgw@fnal.gov on Fri, Oct 13, 2000 at 01:31:34PM -0500
References: <14823.10175.741638.857531@buffalo.fnal.gov> <20001013183436.B12812@xs4all.nl> <14823.21766.733905.575290@buffalo.fnal.gov>
Message-ID: <20001013211938.C12812@xs4all.nl>

On Fri, Oct 13, 2000 at 01:31:34PM -0500, Charles G Waldman wrote:
> Thomas Wouters writes:
>  > 
>  > That's a former DEC alpha, right ? Perhaps running configure with
>  > '--with-dec-threads' will solve the problem ? I'm not sure if that will work
>  > alone, so you might need '--with-dec-threads --with-threads=no' to disable
>  > 'normal' thread-checking. 

> Thank you, that indeed solves the problem.  Sorry for the noise.

No problem. When I went over the README file a few weeks back, and sent
Guido an update, this particular issue was one of the biggest problems for
me: the old README, which assumed threads were not default, was quite
adamant about using --with-dec-threads for OSF/1 and its incarnations.
Unfortunately, it doesn't say why :) And the configure script only says that
it's necessary to get threadsafe libraries.

> It would be nice if configure were smart enough to figure this out!

Configure is as smart as we make it. configure is made by autoconf, which is
moderately intelligent, and we just have to add the extra geniality to
configure.in. If the only check we need is 'does this system call itself
OSF1', we can easily add that. See the attached patch (configure.in version
only. Let me know if you need a patched configure as well, I don't know if
OSF systems come with autoconf. It's pretty large, though, and you don't
need to generate configure on the same system as you run it on. Just apply
the configure.in patch, type 'autoconf', and copy the resulting configure
script to your OSF1 machine.)

The question is, is this enough ? Will this detect all the OSF platforms
that need '-threads', and will it only add it to those platforms ? It
wouldn't be particularly nice of configure if it insisted on adding
'-threads' on platforms that don't need it, or worse, break because of it.
For instance, the patch uses 'OSF*', which might be too generic... but
'OSF1' might be too restrictive :-) A better fix would probably be to write
a test program that explicitly uses threads & the -threads arguments, but
that could fail for a large number of reasons, which doesn't mean -threads
isn't needed :P

(Configure is really amusing like that. For instance, if your compile system
is broken, like when you unpacked a new linux kernel source tree in
/usr/src/linux, but forgot to type 'make symlinks', configure will assume
the worst (every check is negative, after all.) If you're lucky, it will
complain because you miss an essential feature... If you're unlucky, it
finishes cleanly, writes the config.cache file, your compile fails, you
figure out the problem, and you keep compiling using the wrong autoconf
'settings'. And re-configuring doesn't fix it, because the config.cache file
is just fine ;)

-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
-------------- next part --------------
Index: configure.in
===================================================================
RCS file: /cvsroot/python/python/dist/src/configure.in,v
retrieving revision 1.172
diff -c -r1.172 configure.in
*** configure.in	2000/10/12 17:11:38	1.172
--- configure.in	2000/10/13 19:15:11
***************
*** 805,810 ****
--- 805,819 ----
      LIBS="$LIBS -lthread"
      LIBOBJS="$LIBOBJS thread.o"
      USE_THREAD_MODULE=""])
+ 
+     if test "$USE_THREAD_MODULE" != "#"
+     then
+         # If the above checks didn't disable threads, (at least) OSF1
+         # needs this '-threads' argument during linking.
+         case $ac_sys_system in
+         OSF*) LDLAST=-threads;;
+         esac
+     fi
  fi
  
  # Check for GC support

From skip at mojam.com  Fri Oct 13 21:39:42 2000
From: skip at mojam.com (Skip Montanaro)
Date: Fri, 13 Oct 2000 14:39:42 -0500 (CDT)
Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich  comparison)
In-Reply-To: <LNBBLJKPBEHFEDALKOLCIECKHLAA.tim_one@email.msn.com>
References: <14823.22178.605732.455689@buffalo.fnal.gov>
	<LNBBLJKPBEHFEDALKOLCIECKHLAA.tim_one@email.msn.com>
Message-ID: <14823.25854.786347.542654@beluga.mojam.com>

    Tim> None of those were reliable across platforms before, and I'm afraid
    Tim> there's strong reason to suspect one or more still won't work right
    Tim> under Mandrake Linux when Python is compiled with -O (this based on
    Tim> the output of a C program someone posted to c.l.py yesterday).  But
    Tim> it's a world better than it used to be.

After executing

    cvs update -d .
    ./configure
    make clean
    make OPT=-O3

I get the following output from regrtest.py regarding test_math:

    % ./python Lib/test/regrtest.py test_math
    test_math
    1 test OK.

This is on a Mandrake 7.1 system.  Here are the bits I think are relevant to
identify my environment:

    % cat /etc/issue.net
    Linux Mandrake release 7.1 (helium)
    Kernel 2.2.16-9mdk on an i686
    % gcc -v
    Reading specs from /usr/lib/gcc-lib/i586-mandrake-linux/2.95.3/specs
    gcc version 2.95.3 19991030 (prerelease)
    % rpm -q -a | egrep glibc
    glibc-devel-2.1.3-15mdk
    compat-glibc-5.3-2.0.7.6mdk
    glibc-2.1.3-15mdk

If you have a C test program you'd like me to try, shoot it over.  I'll be
glad to run it and shoot back the results.

Skip



From fdrake at beopen.com  Fri Oct 13 21:41:46 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Fri, 13 Oct 2000 15:41:46 -0400 (EDT)
Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich  comparison)
In-Reply-To: <14823.25854.786347.542654@beluga.mojam.com>
References: <14823.22178.605732.455689@buffalo.fnal.gov>
	<LNBBLJKPBEHFEDALKOLCIECKHLAA.tim_one@email.msn.com>
	<14823.25854.786347.542654@beluga.mojam.com>
Message-ID: <14823.25978.181614.85977@cj42289-a.reston1.va.home.com>

Skip Montanaro writes:
 > This is on a Mandrake 7.1 system.  Here are the bits I think are relevant to
 > identify my environment:

  The test passes for me as well on Mandrake 7.1.  Here's the
environment info:

% ./python -tt ../Lib/test/regrtest.py test_math
test_math
1 test OK.
% cat /etc/issue.net 
Welcome to %h
Linux Mandrake release 7.1 (helium)
Kernel 2.2.15-4mdk on an i686
% gcc -v
Reading specs from /usr/lib/gcc-lib/i586-mandrake-linux/2.95.3/specs
gcc version 2.95.3 19991030 (prerelease)
% rpm -qa | egrep glibc
nedit-5.1.1-1.glibc
glibc-profile-2.1.3-5mdk
glibc-2.1.3-5mdk
compat-glibc-5.3-2.0.7.6mdk
glibc-devel-2.1.3-5mdk

 > If you have a C test program you'd like me to try, shoot it over.  I'll be
 > glad to run it and shoot back the results.

  Same here...


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From cgw at fnal.gov  Fri Oct 13 21:52:44 2000
From: cgw at fnal.gov (Charles G Waldman)
Date: Fri, 13 Oct 2000 14:52:44 -0500 (CDT)
Subject: [Python-Dev] gcc versions (was:RE:  Possible bug (was Re: some other junk, ...))
In-Reply-To: <14823.25854.786347.542654@beluga.mojam.com>
References: <14823.22178.605732.455689@buffalo.fnal.gov>
	<LNBBLJKPBEHFEDALKOLCIECKHLAA.tim_one@email.msn.com>
	<14823.25854.786347.542654@beluga.mojam.com>
Message-ID: <14823.26636.59174.832572@buffalo.fnal.gov>

Skip Montanaro writes:

 > This is on a Mandrake 7.1 system.  Here are the bits I think are relevant to
 > identify my environment:

 >     % gcc -v
 >     Reading specs from /usr/lib/gcc-lib/i586-mandrake-linux/2.95.3/specs
 >     gcc version 2.95.3 19991030 (prerelease)

AFAIK, this version of GCC was never "blessed" by the GCC maintainers
and should not be being used for any production work.  I think
Mandrake did a bad thing by shipping this version.  Not quite as bad
as what RedHat did by shipping the completely not-for-general-use
gcc-2.96, but nonetheless still a bad thing.  When will distribution
builders learn that having a higher version number is not necessarily
a good thing?  Why do they keep second-guessing the good advice of the
GCC Steering Committee?  Sigh...

In any case, I don't think we should put effort into chasing down bugs
that are caused by bogus C compilers.  Any reports coming in from
RedHat 7.0 users or Mandrake 7.1 need to be evaluated in this light.




From fdrake at beopen.com  Fri Oct 13 21:58:53 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Fri, 13 Oct 2000 15:58:53 -0400 (EDT)
Subject: [Python-Dev] gcc versions (was:RE:  Possible bug (was Re: some other junk, ...))
In-Reply-To: <14823.26636.59174.832572@buffalo.fnal.gov>
References: <14823.22178.605732.455689@buffalo.fnal.gov>
	<LNBBLJKPBEHFEDALKOLCIECKHLAA.tim_one@email.msn.com>
	<14823.25854.786347.542654@beluga.mojam.com>
	<14823.26636.59174.832572@buffalo.fnal.gov>
Message-ID: <14823.27005.800291.217346@cj42289-a.reston1.va.home.com>

Charles G Waldman writes:
 > AFAIK, this version of GCC was never "blessed" by the GCC maintainers
 > and should not be being used for any production work.  I think
 > Mandrake did a bad thing by shipping this version.  Not quite as bad

  I agree.

 > In any case, I don't think we should put effort into chasing down bugs
 > that are caused by bogus C compilers.  Any reports coming in from
 > RedHat 7.0 users or Mandrake 7.1 need to be evaluated in this light.

  I think Skip & I were showing that there isn't a bug for Mandrake
7.1.  I don't know what version of GCC shipped with Mandrake 7.0,
which may have been the version Tim received the report for (I recall
he said "Mandrake 7", which isn't specific).


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From larsga at garshol.priv.no  Fri Oct 13 22:08:05 2000
From: larsga at garshol.priv.no (Lars Marius Garshol)
Date: 13 Oct 2000 22:08:05 +0200
Subject: [XML-SIG] Re: [Python-Dev] test_minidom non-failure failure? (take 2)
In-Reply-To: <14821.60663.213246.179325@cj42289-a.reston1.va.home.com>
References: <14821.58057.358947.271778@bitdiddle.concentric.net> 	<20001012023134.A18254@glacier.fnational.com> <14821.60663.213246.179325@cj42289-a.reston1.va.home.com>
Message-ID: <m37l7cpkre.fsf@lambda.garshol.priv.no>

* Fred L. Drake, Jr.
|
| This looks like a problem in the unlink() method of the DOM.  Could
| you please check that the unlink() method is updated to handle the
| latest version of the other changes?  

It seems that the current unlink() does not remove sibling cycles.
Patch #101897 adds a line to set sibling references to None, which
seems to make regrtest.py -l happy.

--Lars M.




From prescod at prescod.net  Fri Oct 13 22:12:38 2000
From: prescod at prescod.net (Paul)
Date: Fri, 13 Oct 2000 15:12:38 -0500 (CDT)
Subject: [XML-SIG] Re: [Python-Dev] test_minidom non-failure failure?
 (take 2)
In-Reply-To: <m37l7cpkre.fsf@lambda.garshol.priv.no>
Message-ID: <Pine.LNX.4.21.0010131512240.4759-100000@amati.techno.com>

Right, I just checked in the fix to that.

 Paul Prescod

On 13 Oct 2000, Lars Marius Garshol wrote:

> 
> * Fred L. Drake, Jr.
> |
> | This looks like a problem in the unlink() method of the DOM.  Could
> | you please check that the unlink() method is updated to handle the
> | latest version of the other changes?  
> 
> It seems that the current unlink() does not remove sibling cycles.
> Patch #101897 adds a line to set sibling references to None, which
> seems to make regrtest.py -l happy.
> 
> --Lars M.
> 
> 
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://www.python.org/mailman/listinfo/python-dev
> 




From tim_one at email.msn.com  Fri Oct 13 22:23:31 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Fri, 13 Oct 2000 16:23:31 -0400
Subject: Mandrake vs glibc (was RE: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich  comparison)
In-Reply-To: <14823.25854.786347.542654@beluga.mojam.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCMEDEHLAA.tim_one@email.msn.com>

The original source of my concern was this c.l.py post from David Cooke:

    http://www.deja.com/getdoc.xp?AN=680840594

He ran a little C program that Huaiyu Zhu had posted earlier in the thread.
According to David's results, under "Linux-Mandrake 7.1 (glibc 2.1.3) ...
without -lieee, but compiled with -O ... gcc 2.95.2.", platform exp and sqrt
*never* set errno, regardless of input.  In which case what Python does with
the platform NaN result from math.sqrt(-1.) is an accident (and probably
ends up setting errno to ERANGE itself by mistake), and an overflowing exp
would let the platform +Inf result pass thru silently.

So, if David's report is correct, and best I understand it you were all
using 7.1 too with at least some level of optimization, it's A Mystery why
CVS test_math.py succeeds on that system (its new math.sqrt(-1) test would
probably fail; its new math.exp(+huge) test would almost certainly fail).
I'm anal enough about this stuff that I'd try to figure out why if I had a
Mandrake system, but in the cosmic scheme of things I doubt it's important
enough for anyone else to burn time on.





From jeremy at beopen.com  Sat Oct 14 01:05:02 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Fri, 13 Oct 2000 19:05:02 -0400 (EDT)
Subject: [Python-Dev] build problems large and small on FreeBSD
Message-ID: <14823.38174.143372.125749@bitdiddle.concentric.net>

I just built the latest CVS sources on a FreeBSD machine (4.1-RELEASE
FreeBSD).  There are a number of compiler warnings, all having to do
with redefinitions, plus some linker warnings and a test failure.

I don't have time to investigate further, but thought I'd let people
know in case someone else has time to take a look.

test_math failed -- overflowing exp() didn't trigger OverflowError

Python 2.0c1 (#2, Oct 13 2000, 15:50:26) 
[GCC 2.95.2 19991024 (release)] on freebsd4
Type "copyright", "credits" or "license" for more information.
>>> import math
>>> math.exp(1200)
Inf

The warnings from the linker seem harmless enough.  I don't know why
it is complaining about setkey and des_setkey.  

/usr/lib/libc.so: WARNING!  setkey(3) not present in the system!
/usr/lib/libc.so: warning: this program uses gets(), which is unsafe.
/usr/lib/libc.so: warning: mktemp() possibly used unsafely; consider using mkstemp()
/usr/lib/libc.so: WARNING!  des_setkey(3) not present in the system!
/usr/lib/libc.so: WARNING!  encrypt(3) not present in the system!
/usr/lib/libc.so: warning: tmpnam() possibly used unsafely; consider using mkstemp()
/usr/lib/libc.so: warning: this program uses f_prealloc(), which is stupid.
/usr/lib/libc.so: WARNING!  des_cipher(3) not present in the system!
/usr/lib/libc.so: warning: tempnam() possibly used unsafely; consider using mkstemp()

The compiler-time warnings look like they are caused by a configure
problem.  If so, I don't know how to fix it :-).

gcc -O3 -I../../Python/../Include -I.. -DHAVE_CONFIG_H -c ../../Python/thread.c
In file included from /usr/include/unistd.h:42,
                 from ../../Python/thread.c:28:
/usr/include/sys/unistd.h:71: warning: `_POSIX_THREADS' redefined
../config.h:136: warning: this is the location of the previous definition
In file included from ../../Python/thread.c:118:
../../Python/thread_pthread.h:59: warning: `pthread_attr_default' redefined
/usr/include/pthread.h:158: warning: this is the location of the previous definition
../../Python/thread_pthread.h:60: warning: `pthread_mutexattr_default' redefined
/usr/include/pthread.h:157: warning: this is the location of the previous definition
../../Python/thread_pthread.h:61: warning: `pthread_condattr_default' redefined
/usr/include/pthread.h:156: warning: this is the location of the previous definition

Jeremy



From jeremy at beopen.com  Sat Oct 14 01:11:10 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Fri, 13 Oct 2000 19:11:10 -0400 (EDT)
Subject: [Python-Dev] warnings --with-pydebug
Message-ID: <14823.38542.908547.275077@bitdiddle.concentric.net>

If you configure using '--with-pydebug' you get a lot of compile-time
warnings. 

../../Python/ceval.c: In function `eval_code2':
../../Python/ceval.c:672: warning: value computed is not used
../../Python/ceval.c:675: warning: value computed is not used
../../Python/ceval.c:678: warning: value computed is not used
../../Python/ceval.c:680: warning: value computed is not used
../../Python/ceval.c:681: warning: value computed is not used
[etc.]

I assume these are caused by the definition of Py_INCREF
#define Py_INCREF(op) (_Py_RefTotal++, (op)->ob_refcnt++)

Is there some way to change this macro so that the warnings are
silenced? 

Jeremy



From thomas at xs4all.net  Sat Oct 14 01:28:19 2000
From: thomas at xs4all.net (Thomas Wouters)
Date: Sat, 14 Oct 2000 01:28:19 +0200
Subject: [Python-Dev] build problems large and small on FreeBSD
In-Reply-To: <14823.38174.143372.125749@bitdiddle.concentric.net>; from jeremy@beopen.com on Fri, Oct 13, 2000 at 07:05:02PM -0400
References: <14823.38174.143372.125749@bitdiddle.concentric.net>
Message-ID: <20001014012819.D12812@xs4all.nl>

On Fri, Oct 13, 2000 at 07:05:02PM -0400, Jeremy Hylton wrote:

> The warnings from the linker seem harmless enough.  I don't know why
> it is complaining about setkey and des_setkey.  

That's probably due to 'crypt()' being used, or some other library call that
Python uses indirectly. If you want crypt(), you need to install a seperate
DES encryption package under FreeBSD, IIRC. (It uses md5-hashes for all
crypt purposes by default, because of the US Counter-Espionage Protection
Plan or something :) If you don't want to install those, don't enable the
crypt module. There are a couple of pure python crypt() implementations
around, by the way, which always use pure DES crypt().

> /usr/lib/libc.so: warning: this program uses gets(), which is unsafe.

This one is weirdish. I don't see any gets() call in Python, so I have to
assume it's in some library or header file Python includes. A good candidate
would be readline, which has appalled me before :) but who knows :P I'm
inclined to think it isn't a library that comes with FreeBSD by default,
since they are usually pretty picky about such things. (especially if it
generates a linker warning each time it's used!)

> /usr/lib/libc.so: warning: mktemp() possibly used unsafely; consider using mkstemp()
> /usr/lib/libc.so: warning: tmpnam() possibly used unsafely; consider using mkstemp()
> /usr/lib/libc.so: warning: tempnam() possibly used unsafely; consider using mkstemp()

Yes, I've seen this before. Debian-unstable (I think ?) complains about
tmpnam() and tempnam() as well. The manpages just say 'don't use
this function, use mkstemp(3)'. It doesn't mention a reason, but it's
probably because the files/directories created by these functions are
predictable, which means you shouldn't use them for security-by-obscurity.

The mktemp() warning doesn't come from Python, looks like. Probably another
library that is included. If you really care about which it is, you'll have
to comment them out one by one (I'd suggest starting with the oldest and
least FreeBSDish one, i.e. readline :) but I don't think it's going to
really matter. Python does use 'tempnam' and 'tmpnam', but only in the
posixmodule, to provide Python versions. I'm not sure if we can just change
these functions to use mkstemp (or tempfile, see below) internally, without
breaking code, though I expect it'll be alright. What's more, these
functions are new since 1.5.2. And also, I just noticed a bug/typo in the
tempnam docstring.

The one funny bit, though, is that these three functions point to mkstemp(),
and the mkstemp() manpage reads this:

       Don't use this  function,  use  tmpfile(3)  instead.  It's
       better defined and more portable.

"When does the hurting stop ?"

> /usr/lib/libc.so: warning: this program uses f_prealloc(), which is stupid.

And this falls in the 'it wasn't us' category again.

> The compiler-time warnings look like they are caused by a configure
> problem.  If so, I don't know how to fix it :-).

> gcc -O3 -I../../Python/../Include -I.. -DHAVE_CONFIG_H -c ../../Python/thread.c
> In file included from /usr/include/unistd.h:42,
>                  from ../../Python/thread.c:28:
> /usr/include/sys/unistd.h:71: warning: `_POSIX_THREADS' redefined
> ../config.h:136: warning: this is the location of the previous definition

Hm, yes. This looks like an unfortunate clash between a Python internal
#define and a FreeBSD libc internal #define. I'm not sure if this is really
the case, maybe the Python one serves exactly the same purpose as the
FreeBSD one, but in that case, configure shouldn't redefine it. We can
either rename the #define in Python, as it's only used to determine which
thread functionality is available, or adjust the configure tests to see if
it is #defined and not redefine it if so.

(Or rather, to be sure that it defines the right thing, configure would have
to test for posix threads, check the #define (if any), and if they don't
match up, scream its head off. So perhaps renaming is the smarter thing.) On
the other hand, the fact that you only got a warning, and not an error,
means that Python isn't defining it to a different value than FreeBSD did, so
it's not really a problem. It might be a problem if Python #defines it, but
FreeBSD does not, but FreeBSD does have code that checks that #define, and
starts doing weird things...

> In file included from ../../Python/thread.c:118:
> ../../Python/thread_pthread.h:59: warning: `pthread_attr_default' redefined
> /usr/include/pthread.h:158: warning: this is the location of the previous definition
> ../../Python/thread_pthread.h:60: warning: `pthread_mutexattr_default' redefined
> /usr/include/pthread.h:157: warning: this is the location of the previous definition
> ../../Python/thread_pthread.h:61: warning: `pthread_condattr_default' redefined
> /usr/include/pthread.h:156: warning: this is the location of the previous definition

Not sure about these, because I don't know enough about the various types of
posix thread standards, and almost-posix thread almost-standards. I'm not
sure if those names are reserved in any way, but they are apparently
clashing with FreeBSD names. Or perhaps it's FreeBSD 'compatibility' code
that does the defines like Python does, too. A simple '#undef' or '#ifndef'
would suffice, here, I think, but I'm not sure.


-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!



From thomas at xs4all.net  Sat Oct 14 01:33:59 2000
From: thomas at xs4all.net (Thomas Wouters)
Date: Sat, 14 Oct 2000 01:33:59 +0200
Subject: [Python-Dev] warnings --with-pydebug
In-Reply-To: <14823.38542.908547.275077@bitdiddle.concentric.net>; from jeremy@beopen.com on Fri, Oct 13, 2000 at 07:11:10PM -0400
References: <14823.38542.908547.275077@bitdiddle.concentric.net>
Message-ID: <20001014013359.E12812@xs4all.nl>

On Fri, Oct 13, 2000 at 07:11:10PM -0400, Jeremy Hylton wrote:
> If you configure using '--with-pydebug' you get a lot of compile-time
> warnings. 

> ../../Python/ceval.c: In function `eval_code2':
> ../../Python/ceval.c:672: warning: value computed is not used
> ../../Python/ceval.c:675: warning: value computed is not used
> ../../Python/ceval.c:678: warning: value computed is not used
> ../../Python/ceval.c:680: warning: value computed is not used
> ../../Python/ceval.c:681: warning: value computed is not used
> [etc.]

> I assume these are caused by the definition of Py_INCREF
> #define Py_INCREF(op) (_Py_RefTotal++, (op)->ob_refcnt++)

> Is there some way to change this macro so that the warnings are
> silenced? 

Yes, prefix it with '(void)':

#define Py_INCREF(op) (void)(_Py_RefTotal++, (op)->ob_refcnt++)

However, that means that the 'return value' of Py_INCREF() must never be
used anywhere. (If it does, it'll generate an error.) The return value of
Py_INCREF() is not terribly useful, though. Both in debug and in normal
mode, it expands to the refcount of the object *before* it was INCREF'd.

I still consider this kind of warning (I've seen it before, always with
macros that do several things by using the otherwise fairly useless
tuple-creator in C ;) a bit of a bug in gcc: it knows both those statements
have sideeffects, and it's obvious we want to throw away the first result,
so why worry about the second ? But at least it isn't screwing up
floating-point operations, and nobody's perfect :-)

-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!



From huaiyu_zhu at yahoo.com  Sat Oct 14 02:25:49 2000
From: huaiyu_zhu at yahoo.com (Huaiyu Zhu)
Date: Fri, 13 Oct 2000 17:25:49 -0700 (PDT)
Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich
 comparison)
In-Reply-To: <LNBBLJKPBEHFEDALKOLCIEBCHLAA.tim_one@email.msn.com>
Message-ID: <Pine.LNX.4.10.10010131015350.3117-100000@rocket.knowledgetrack.com>

Tim,

Thank you for the explanations.  We actually agree more than it appears:

- Full IEEE 754 support in Python is good, which should allow the user to
  decide when to use raised flags and when to use Python exceptions.

- If the user default can be changed with one line of code, it does not
  matter if Python default use exceptions, even if that's not strict
  compliance in words.  The "factory default" might as well set for the
  benefit of newbies.

- Without IEEE 754 support, or with just partial support, f.p. computation
  is a mess.

Following are some contentious issues:

I am not so sure that even with 754, there would still be a great variety.
I see you giving one example: sqrt(-1) in 1.5.2.  But wasn't that caused by
extra Python checking?  I say this because errno==0 in C.  Maybe I'm missing
something.  Or, do you mean that glibc itself is deficient, because it
should have set the flag?

My worry concerns the decision to unify 2.0 f.p. behavior in a specific way
before full IEEE 754 support.  I understand that you say this does not count
as a changed behavior because the previous one is accidental.  But I don't
see the particular fixed subset chosen as any better than any other. I agree
that I do have a choice of using -lieee, though.

It is interesting to know that someone actually relies on OverflowError to
detect underflow.  But why not let them continue that as well, given that
all of these would be available in the future anyway?

> At this point we favor forcing consistency over maintaining platform
> accidents, no matter how attached people have gotten to them; else we'll
> be stuck with them forever.

I do not understand.  Once there is full IEEE 754, everyone would have a
choice, which pretty much includes all the things people are doing now.
Before that happens, why consistency accross platform is deemed more
important than consistency accross releases?  My naive thinking is that
people port more from 1.5.2 to 2.0 than from one platform to another, isn't
it?  :-)

Following does not have much new to say, just some clarification.

You are right to emphasise that Kahan does not favor any subset of IEEE 754:

> >   They are called "Exceptions" because to any policy for handling them,
> >   imposed in advance upon all programmers by the computer system, some
> >   programmers will have good reason to take exception.

Yes.  And that's what's happening. :-)

> His paper "How JAVA's Floating-Point Hurts Everyone Everywhere" lists his 5
> main gripes about Java in bullet points at the top of page 3.  The paper
> runs on to 80 pages.  You somehow managed to miss 79.89 of them <0.4 wink>,
> reducing it to a bogus claim about Java that Kahan didn't make (Java has
> neither "Trap" nor "Flag" style fp exception signaling).

Thank you for correcting me on this one.  I did "glance over" all the pages.
I was somewhat puzzled by his decriptions, so I made a quick test: 1/0, and
got Exception in thread "main" java.lang.ArithmeticException: / by zero

But now I see that 1/0.0 is Infinity.  So is Math.exp(777).  And so on.
So that teaches me to test, test, test, ...

> > He told "A cautionary Tale of the Ariane 5",
> 
> Which has nothing to do with Java -- the software in question was written in
> Ada, which (unlike Java) has "Trap" style.  Why he put it in a paper about
> Java is a bit of a mystery; I write it off to rhetorical excess.

You are right it does not apply to Java.  I guess he meant that as a warning
that changing to the other side might be equally bad.

> > So do we want every Python program to bomb whenever there is a floating
> > point value outside bound and is not trapped by try/except?
> 
> By default, yes, Guido does, but for overflow, not underflow.

That's the harsh reality I have to live with, I suppose. <0.9wink>

>  If you read
> the following section of Kahan's paper, you should have noticed that he is
> *just* as critical of just returning Infs and NaNs (which is all Java does,
> and which is the accidental Python behavior you're arguing we keep in glibc)
> as he is of just trapping!  His conclusion:  "Without Traps nor Flags, Java?
> s floating-point is Dangerous":
> 
>     Without flags, detecting rare creations of Inf and NaN before they
>     disappear requires programmed tests and branches that, besides
>     duplicating tests already performed by the hardware, slow down the
>     program and impel a programmer to make decisions prematurely in many
>     cases. Worse, a plethora of tests and branches undermines a program?s
>     modularity, clarity and concurrency.
> 
> I agree with him there wholeheartedly:  without the 754-mandated flags,
> *and* without raising exceptions, the subset of 754 remaining sucks.

That is true, but all these problems apply to "without raising flags",
whether with or without "raising exceptions".  Silent overflow forces
programmers to do extra checking if they need to find them.  Mandatory
exception forces programmer to do extra checking if they don't want them to
stop the program.  Which is more common?  It depends on programming style.
In my programs, intentional NaN is far more than NaN by mistake.

As to whether it is dangerous, I would say that if an overflow is really an
error, good programming style requires that it be detected much earlier than
the actual overflow.  I agree this cannot be expected of everyone, though.

> >> ironically, 754 is hardest to sell to those who could benefit from
> >> it the most.
> 
> > So far the only concern from number-crunchers voiced here is that it might
> > allow sqrt(-1)==0, which is not the case.
> 
> Gimme a break!  In the very msg Paul Dubois said that, he also said "Some
> people use Inf but most people want the code to STOP so they can find out
> where the INFS started.  Otherwise, two hours later you have big arrays of
> Infs and no idea how it happened.".  I'm starting to drop my assumption of
> good faith on your part:  what you remember and how you paraphrase (whether
> it's Paul or Kahan) is extremely selective, beyond normal bounds of
> zeal-inspired distortion.

Well, I was talking about whether anyone has shown a concern to oppose 754.
I was not talking about whether exception is prefered to flags.  See the
line I was replying to?  Actually, thinking about it, Paul was not talking
about concerns over 754, either.  So there appears zero resistence to 754
from number crunchers here.

> > Obviously we agree on the benefit of having a choice.  But we
> > have different perspective on what choice means.  Your want a choice
> > to force user to take explicit action, I want a choice to ignore these
> > events.
> 
> No.  I want exactly the choices 754 lays out:  user-settable sticky flags
> and user-maskable exceptions.  We're not getting that for 2.0.  And we're
> *never* getting it if 2.0 doesn't do *something* to start disabusing people
> of the notion that their historical numeric platform accidents in Python
> will be faithfully preserved forever more.

Let me make it clear that we agree on all essential points about full 754
support.  The difference only exists in the period before that.  Since both
the 1.5.2 accidental behaviors and the one you want to unify to are just
subsets of the full support, it does not appear to me that disabling several
of them is a prerequisite for the full support.

> Kinda, except that each of the 5 754-defined traps must be individually
> maskable.  754 spells out what's needed.  A PEP will be required to spell
> out the Python- and C-level APIs.  I've corresponded (just -- no time now) a
> little with Kevin Jacobs about that offline.

Great!  If the true IEEE 754 support could come soon, all my gripe is moot.
So I'll stop disturbing you on the good work.  :-)

OK, I see that you want consistency above anything else before that good day
comes.  Well, consistency is good.  Whether the price is too high is a
subjective judgement.  So I'll just use the -lieee hack for myself, then.

[On presubstitution] 

Ok, I found it.  It looks good.

[On whether 754 default uses flags or exceptions] 

I agree with you: the system default matters very little as long as users
can set their own defaults easily.
 
> I expect we'll have to make InvalidOperationError a subclass of ValueError
> for that reason, when 754 support materializes.

That'll be handy.

> > My favorite is returning 1j, as MatPy does.
> 
> Then you should use cmath.sqrt instead of math.sqrt. 

Thanks.

Huaiyu




From skip at mojam.com  Sat Oct 14 02:29:06 2000
From: skip at mojam.com (Skip Montanaro)
Date: Fri, 13 Oct 2000 19:29:06 -0500 (CDT)
Subject: [Python-Dev] Simple xml.sax example?
Message-ID: <14823.43218.337621.157021@beluga.mojam.com>

Is there a simple example available that demonstrates how to use elements of
the new xml.sax package?  I'd prefer something that doesn't require me to
install anything other than what comes with the Python 2.0 distribution?

Thanks,

Skip




From cbarker at jps.net  Sat Oct 14 03:22:28 2000
From: cbarker at jps.net (Chris Barker)
Date: Fri, 13 Oct 2000 18:22:28 -0700
Subject: [Python-Dev] RE: [Numpy-discussion] RE: Possible bug (was Re: numpy, 
 overflow, inf, ieee, and rich comparison)
References: <LNBBLJKPBEHFEDALKOLCEEACHLAA.tim_one@email.msn.com>
Message-ID: <39E7B554.29A168E3@jps.net>

Incomplete vs. non-at-all IEEE 754 support is a non argument. If you
have full IEEE support (which it seems everyone here thinks would be
good, but difficult), it is clear what you have. If not, you are not
consistent with a standard, and therefor making up your own. That being
the case, it's a matter of what we want the Python standard to be.

I, for one think that NaN and Inf are fantastic!!! I think the best
argument for them here is that it is almost impossible to do a lot of
array based calculations without them, and you can't do serious number
crunching in Python without array based calculations.

I've come to Python from MATLAB for numerics, and I really appreciated
MATLAB's way of handling all this. I don't think MATLAB has true 754
support, as I don't think you can change the behaviour, but you do get a
consistent result across platforms (including non-iee machines like the
Cray?---I have no idea). 

I have not yet heard a decent response to the question of what to do
when a single value in a large array is bad, and causes an exception.
This really does render Python essentially useless for Numerics for me.
I suspect all those number crunchers that want an exception rather than
an Inf are NOT using array-oriented languages. My goal is to dump MATLAB
for Python, but this may prevent me from doing that.

Does anyone know what other array-oriented languages use? I know what
MATLAB does:

>> exp(-777)
ans =
     0
>> exp(777)
ans =
   Inf
>> sqrt(-1)
ans =
        0 + 1.0000i

Hey! I like that! Python is dynamic, why can't we just get the actual
answer to sqrt(-1), without using cmath, that always returns a complex ?
sorry, other subjet, not meant to be raised at the moment.

>> 54/0
Warning: Divide by zero.
ans =
   Inf                   

Here we get a warning, but also a result that won't crash the
computation.

>> a = 0/0
Warning: Divide by zero.
a =
   NaN
>> b = a
b =
   NaN
>> a == b
ans =
     0            

So comparing two NaNs yields a false, as it should, and though Python
won't do it now, it could. One thing that a numerical routine should
NEVER do is give an incorrect answer. No answer is often bad, but an
incorrect one is much worse. NaN == NaN must return false.

Does anyone know what FORTRAN 90 specifies (if anything)? What other
array-oriented languages are there?

I think what MATLAB does is what Tim is calling "bad *and* incomplete
754 support" Incomplete is surely true, "bad" is clearly a matter of
opinion. It seems we have a variety of users of numerics in Python, that
I break into three broad catagories:

Casual users:
mostly doing non-numeric stuff, with the occasional calculation:
This group could use any non-cryptic handling of over/underflow, it just
doesn't matter.

Mid-level number crunchers:
This is the group I put myself in. We crunch a lot of numbers, really
like the array semantics (and speed) of NumPy, and are doing things like
graphing functions, statistical calculations, etc. We have probably only
taken one of two (at most) numerical analysis courses, and many don't
know what the heck IEE 754 is. (The one Numerical Analysis course I did
take, happened to be with Kahan, which is why I know what it is)

For this group, the incomplete IEEE support is probably the best way to
go. We're more likely to be annoyed by our whole computation stopping
because of one bad data point, than we are to be pissed off that it
didn't stop when it started to compute garbage.

Hard Core Number crunchers:
These are the folks that do things like write optimised routines for
particular architectures, adn teach numerical analysis courses. These
folks want either FULL IEEE, or plain old "classic" overflow and
underflow errors, that they can handle themselves. Do these folks really
use Python as other than a glue language? Are they really doing massive
number crunching in Python itself, rather than in C (or whatever)
extensions? If so, I'd be surprised is they didn't find Huaiyu's
argument compelling when doing array based calculations.

Tim pointed out that Python was not designed with 754 in mind, so for
2.0, what he is doing is probably our best bet, but it seems to not be
the best ultimate solution, I hope using NaN and Inf will be considered
for future versions, even if it is incomplete 754 compliance.

Note: if the ultimate goal is REAL IEEE 754 compliance, is it possible
without custom re-compiling your own interpreter? If so, is there any
chance that it will come any time soon (2.1 ?) , so we don't have to
have this discussion at all?

Thanks for all of your work on this, Python just keeps getting better!!

-Chris

-- 
Christopher Barker,
Ph.D.                                                           
cbarker at jps.net                      ---           ---           ---
http://www.jps.net/cbarker          -----@@       -----@@       -----@@
                                   ------@@@     ------@@@     ------@@@
Water Resources Engineering       ------   @    ------   @   ------   @
Coastal and Fluvial Hydrodynamics -------      ---------     --------    
------------------------------------------------------------------------
------------------------------------------------------------------------



From cgw at fnal.gov  Sat Oct 14 04:44:42 2000
From: cgw at fnal.gov (Charles G Waldman)
Date: Fri, 13 Oct 2000 21:44:42 -0500 (CDT)
Subject: [Python-Dev] RE: [Numpy-discussion] RE: Possible bug (was Re:
 numpy, overflow, inf, ieee, and rich comparison)
In-Reply-To: <39E7B554.29A168E3@jps.net>
References: <LNBBLJKPBEHFEDALKOLCEEACHLAA.tim_one@email.msn.com>
	<39E7B554.29A168E3@jps.net>
Message-ID: <14823.51354.977817.409017@buffalo.fnal.gov>

Chris Barker writes:

 > Hey! I like that! Python is dynamic, why can't we just get the actual
 > answer to sqrt(-1), without using cmath, that always returns a complex ?

You have to import the sqrt function from somewhere.  Either you
import it from math or from cmath, depending on which flavor you need.
Anybody sophisticated enough to know what complex numbers are, and
sophisticated enough to want to get complex values as a result of a
calculation, should be sophisticated enough to be able to type
"cmath".





From larsga at garshol.priv.no  Sat Oct 14 12:19:20 2000
From: larsga at garshol.priv.no (Lars Marius Garshol)
Date: 14 Oct 2000 12:19:20 +0200
Subject: [Python-Dev] Simple xml.sax example?
In-Reply-To: <14823.43218.337621.157021@beluga.mojam.com>
References: <14823.43218.337621.157021@beluga.mojam.com>
Message-ID: <m34s2fpvx3.fsf@lambda.garshol.priv.no>

* Skip Montanaro
|
| Is there a simple example available that demonstrates how to use
| elements of the new xml.sax package?

Here are a couple from an internal seminar I recently gave on this.  I
could make the slides available as well, if there is interest.

--Lars M.

--- elem_count.py

import sys

from xml.sax import make_parser, handler

class FancyCounter(handler.ContentHandler):

    def __init__(self):
        self._elems = 0
        self._attrs = 0
        self._elem_types = {}
        self._attr_types = {}

    def startElement(self, name, attrs):
        self._elems = self._elems + 1
        self._attrs = self._attrs + len(attrs)
        self._elem_types[name] = self._elem_types.get(name, 0) + 1

        for name in attrs.keys():
            self._attr_types[name] = self._attr_types.get(name, 0) + 1

    def endDocument(self):
        print "There were", self._elems, "elements."
        print "There were", self._attrs, "attributes."

        print "---ELEMENT TYPES"
        for pair in  self._elem_types.items():
            print "%20s %d" % pair

        print "---ATTRIBUTE TYPES"
        for pair in  self._attr_types.items():
            print "%20s %d" % pair

            
parser = make_parser()
parser.setContentHandler(FancyCounter())
parser.parse(sys.argv[1])

--- roundtrip.py

"""
A simple demo that reads in an XML document and spits out an equivalent,
but not necessarily identical, document.
"""

import sys, string

from xml.sax import saxutils, handler, make_parser

# --- The ContentHandler

class ContentGenerator(handler.ContentHandler):

    def __init__(self, out = sys.stdout):
        handler.ContentHandler.__init__(self)
        self._out = out

    # ContentHandler methods
        
    def startDocument(self):
        self._out.write('<?xml version="1.0" encoding="iso-8859-1"?>\n')

    def startElement(self, name, attrs):
        self._out.write('<' + name)
        for (name, value) in attrs.items():
            self._out.write(' %s="%s"' % (name, saxutils.escape(value)))
        self._out.write('>')

    def endElement(self, name):
        self._out.write('</%s>' % name)

    def characters(self, content):
        self._out.write(saxutils.escape(content))

    def ignorableWhitespace(self, content):
        self._out.write(content)
        
    def processingInstruction(self, target, data):
        self._out.write('<?%s %s?>' % (target, data))

# --- The main program

parser = make_parser()
parser.setContentHandler(ContentGenerator())
parser.parse(sys.argv[1])

--- rss2html.py

import sys

from xml.sax import make_parser, handler

# --- Templates

top = \
"""
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML>
<HEAD>
  <TITLE>%s</TITLE>
</HEAD>

<BODY>
<H1>%s</H1>
"""

bottom = \
"""
</ul>

<HR>
<ADDRESS>
Converted to HTML by sax_rss2html.py.
</ADDRESS>

</BODY>
</HTML>
"""

# --- The ContentHandler

class RSSHandler(handler.ContentHandler):

    def __init__(self, out = sys.stdout):
        handler.ContentHandler.__init__(self)
        self._out = out

        self._text = ""
        self._parent = None
        self._list_started = 0
        self._title = None
        self._link = None
        self._descr = ""

    # ContentHandler methods

    def startElement(self, name, attrs):
        if name == "channel" or name == "image" or name == "item":
            self._parent = name

        self._text = ""

    def endElement(self, name):
        if self._parent == "channel":
            if name == "title":
                self._out.write(top % (self._text, self._text))
            elif name == "description":
                self._out.write("<p>%s</p>\n" % self._text)

        elif self._parent == "item":
            if name == "title":
                self._title = self._text
            elif name == "link":
                self._link = self._text
            elif name == "description":
                self._descr = self._text
            elif name == "item":
                if not self._list_started:
                    self._out.write("<ul>\n")
                    self._list_started = 1

                self._out.write('  <li><a href="%s">%s</a> %s\n' %
                                (self._link, self._title, self._descr))

                self._title = None
                self._link = None
                self._descr = ""

        if name == "rss":
            self._out.write(bottom)
                
    def characters(self, content):
        self._text = self._text + content

# --- Main program

parser = make_parser()
parser.setContentHandler(RSSHandler())
parser.parse(sys.argv[1])




From thomas at xs4all.net  Sat Oct 14 13:05:41 2000
From: thomas at xs4all.net (Thomas Wouters)
Date: Sat, 14 Oct 2000 13:05:41 +0200
Subject: [Python-Dev] can't build with threads on OSF/1
In-Reply-To: <20001013211938.C12812@xs4all.nl>; from thomas@xs4all.net on Fri, Oct 13, 2000 at 09:19:38PM +0200
References: <14823.10175.741638.857531@buffalo.fnal.gov> <20001013183436.B12812@xs4all.nl> <14823.21766.733905.575290@buffalo.fnal.gov> <20001013211938.C12812@xs4all.nl>
Message-ID: <20001014130541.F12812@xs4all.nl>

On Fri, Oct 13, 2000 at 09:19:38PM +0200, Thomas Wouters wrote:

> On Fri, Oct 13, 2000 at 01:31:34PM -0500, Charles G Waldman wrote:

[ DEC threads (OSF1) are not automatically detected, causing a compilation
  failure on such systems ]

> > It would be nice if configure were smart enough to figure this out!

> ... we can easily add that. See the attached patch ...

Charles, if you get a chance to test this patch before monday, please do. I
think it's important to try and get the thread compiling right, now that
threads are on by default. This is going to create a lot of confusion with
OSF-users that don't read the README all the way through!

If you can't test it, perhaps we can apply it before 2.0 none the less. I
personally think there are more systems calling themselves OSF1 that do need
the -threads argument than there are that don't need it (if any) and the
patch only adds -threads if threads are really enabled. (Or perhaps change
the patch to read 'OSF1)' instead of 'OSF*)' in the case stmt, to be
conservative.)

-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!



From effbot at telia.com  Sat Oct 14 13:35:29 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Sat, 14 Oct 2000 13:35:29 +0200
Subject: [Python-Dev] can't build with threads on OSF/1
References: <14823.10175.741638.857531@buffalo.fnal.gov> <20001013183436.B12812@xs4all.nl> <14823.21766.733905.575290@buffalo.fnal.gov> <20001013211938.C12812@xs4all.nl> <20001014130541.F12812@xs4all.nl>
Message-ID: <009801c035d2$dc8ff4c0$3c6340d5@hagrid>

Thomas Wouters wrote:
> (Or perhaps change the patch to read 'OSF1)' instead of 'OSF*)'
> in the case stmt, to be conservative.)

are there really any others?

(that "1" is part of the original name, it's not a version number)

</F>





From thomas at xs4all.net  Sat Oct 14 13:28:20 2000
From: thomas at xs4all.net (Thomas Wouters)
Date: Sat, 14 Oct 2000 13:28:20 +0200
Subject: [Python-Dev] can't build with threads on OSF/1
In-Reply-To: <009801c035d2$dc8ff4c0$3c6340d5@hagrid>; from effbot@telia.com on Sat, Oct 14, 2000 at 01:35:29PM +0200
References: <14823.10175.741638.857531@buffalo.fnal.gov> <20001013183436.B12812@xs4all.nl> <14823.21766.733905.575290@buffalo.fnal.gov> <20001013211938.C12812@xs4all.nl> <20001014130541.F12812@xs4all.nl> <009801c035d2$dc8ff4c0$3c6340d5@hagrid>
Message-ID: <20001014132820.Y12776@xs4all.nl>

On Sat, Oct 14, 2000 at 01:35:29PM +0200, Fredrik Lundh wrote:

> Thomas Wouters wrote:
> > (Or perhaps change the patch to read 'OSF1)' instead of 'OSF*)'
> > in the case stmt, to be conservative.)

> are there really any others?

Don't know. That's why I asked it :)

> (that "1" is part of the original name, it's not a version number)

Ah, but that doesn't explain why configure.in OSF*) in some cases, and OSF1)
in others:

        case $ac_sys_system in
        OSF1)   CC=cc
                without_gcc=;;

versus

if test -z "$LDSHARED"
then
        case $ac_sys_system/$ac_sys_release in
[..]
        OSF*) LDSHARED="ld -shared -expect_unresolved \"*\"";;
[..]

I guess the OSF*) action is specific enough (most likely to lead to errors
on systems that call themselves, say, OSFORME) that we don't really have to
worry about it right now.

-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!



From fdrake at beopen.com  Sat Oct 14 14:32:33 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Sat, 14 Oct 2000 08:32:33 -0400 (EDT)
Subject: [Python-Dev] Simple xml.sax example?
In-Reply-To: <m34s2fpvx3.fsf@lambda.garshol.priv.no>
References: <14823.43218.337621.157021@beluga.mojam.com>
	<m34s2fpvx3.fsf@lambda.garshol.priv.no>
Message-ID: <14824.21089.373315.436615@cj42289-a.reston1.va.home.com>

Lars Marius Garshol writes:
 > Here are a couple from an internal seminar I recently gave on this.  I
 > could make the slides available as well, if there is interest.

  Could we include this in Demos/xml/ ?


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From cgw at fnal.gov  Sat Oct 14 15:08:30 2000
From: cgw at fnal.gov (Charles G Waldman)
Date: Sat, 14 Oct 2000 08:08:30 -0500 (CDT)
Subject: [Python-Dev] can't build with threads on OSF/1
In-Reply-To: <20001014130541.F12812@xs4all.nl>
References: <14823.10175.741638.857531@buffalo.fnal.gov>
	<20001013183436.B12812@xs4all.nl>
	<14823.21766.733905.575290@buffalo.fnal.gov>
	<20001013211938.C12812@xs4all.nl>
	<20001014130541.F12812@xs4all.nl>
Message-ID: <14824.23246.159738.283035@buffalo.fnal.gov>

Thomas Wouters writes:
 > 
 > Charles, if you get a chance to test this patch before monday, please do. I
 > think it's important to try and get the thread compiling right, now that
 > threads are on by default.

OK, I just tried it and it worked for me.  (I only tested it on one
OSF/1 system, but I suppose that's better than nothing).

Thanks for patching this, I think you are right that it will save a
lot of confusion (at least for that handful of people running this
OS!)



From m.favas at per.dem.csiro.au  Sat Oct 14 15:11:11 2000
From: m.favas at per.dem.csiro.au (Mark Favas)
Date: Sat, 14 Oct 2000 21:11:11 +0800
Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich
 comparison)
Message-ID: <39E85B6F.E95AD41F@per.dem.csiro.au>

[Huaiyu Zhu, replying to Tim...]
>It is interesting to know that someone actually relies on >OverflowError to detect underflow.  But why not let them continue that >as well, given that all of these would be available in the future >anyway?

I think I'm the someone referred to - but I _don't_ rely on this at all.
I was reporting that, on my platforms, the behaviour of exp(-666) did
_not_ change between 1.5.2 and 2.0, both of which raised an
OverflowError (for underflow). I prefer Tim's change so that exp(-huge)
will produce 0, and that exp(huge) produces an OverflowError, even
though this changes the behaviour when moving from 1.5.2 to 2.x...

[Huaiyu Zhu again]
>Before that happens, why consistency accross platform is deemed more
>important than consistency accross releases?  My naive thinking is >that people port more from 1.5.2 to 2.0 than from one platform to >another, isn't it?  :-)

In spite of the smiley, I'd have to say (politely) "Rubbish!". One of
the many attractions of Python to me _is_ cross-platform consistency -
more so than up-version consistency. In my previous life as a
computational chemist I spent a lot of effort in writing code that was
portable - indeed, we developed a pre-processor language (which spat out
FORTRAN) to try to more easily handle
OS/compiler/word-size/FP-characteristic/phase-of-moon issues. I first
came up against IEEE stuff in the early 80's, and I agree with Tim - as
a user, I hated the non-stop defaults. Mollycoddled by CDC machines, I
was used to my code stopping when I divided by zero - it usually
indicated a coding or algorithmic error. When (if) Python supports
access to masking/unmasking 754 exceptions, that'll be good - in the
meantime, from my POV, the steps taken by Tim/Guido are in the right
direction.

-- 
Mark Favas  -   m.favas at per.dem.csiro.au
CSIRO, Private Bag No 5, Wembley, Western Australia 6913, AUSTRALIA



From thomas at xs4all.net  Sat Oct 14 19:12:34 2000
From: thomas at xs4all.net (Thomas Wouters)
Date: Sat, 14 Oct 2000 19:12:34 +0200
Subject: [Python-Dev] can't build with threads on OSF/1
In-Reply-To: <14824.23246.159738.283035@buffalo.fnal.gov>; from cgw@fnal.gov on Sat, Oct 14, 2000 at 08:08:30AM -0500
References: <14823.10175.741638.857531@buffalo.fnal.gov> <20001013183436.B12812@xs4all.nl> <14823.21766.733905.575290@buffalo.fnal.gov> <20001013211938.C12812@xs4all.nl> <20001014130541.F12812@xs4all.nl> <14824.23246.159738.283035@buffalo.fnal.gov>
Message-ID: <20001014191234.G12812@xs4all.nl>

On Sat, Oct 14, 2000 at 08:08:30AM -0500, Charles G Waldman wrote:
> Thomas Wouters writes:

>  > Charles, if you get a chance to test this patch before monday, please do. I
>  > think it's important to try and get the thread compiling right, now that
>  > threads are on by default.

> OK, I just tried it and it worked for me.  (I only tested it on one
> OSF/1 system, but I suppose that's better than nothing).

Yeah, I already tested it on the ther platforms I have. Not really
necessary, since the patch is really tiny and can only really be a problem
on platforms that have a 'system name' that matches 'OSF*' but don't need
'-threads'. Thanx for testing that it works, though.

Jeremy, are you OK on checking this autoconf change in ? Is it in time for
2.0-final ?

-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!



From jeremy at beopen.com  Sun Oct 15 00:11:30 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Sat, 14 Oct 2000 18:11:30 -0400
Subject: [Python-Dev] RE: [Python-checkins] CVS: distutils/distutils util.py,1.55,1.56
In-Reply-To: <200010140407.VAA08029@slayer.i.sourceforge.net>
Message-ID: <AJEAKILOCCJMDILAPGJNOEDKCCAA.jeremy@beopen.com>

Greg,

Do you intend these most recent changes to be included in 2.0 final on
Monday?  Just giving you a heads up in case you didn't realize what the
release schedule is.  The only changes we should be making are critical bugs
fixes for mainline code (non-demo, tools, etc.).

Also, there is some code in the top-level of the CVS repository that hasn't
been put in the previous source tarballs; at least the C code for the
Windows installer, but maybe other things as well.  Can you recommend how to
include this in the source distribution for the final release?  We'd like to
include *all* the source code for distutils.

Jeremy





From barry at scottb.demon.co.uk  Sun Oct 15 01:28:45 2000
From: barry at scottb.demon.co.uk (Barry Scott)
Date: Sun, 15 Oct 2000 00:28:45 +0100
Subject: [Python-Dev] Python 2.0b2 note for Windows developers
In-Reply-To: <LNBBLJKPBEHFEDALKOLCGEEEHKAA.tim_one@email.msn.com>
Message-ID: <000001c03636$7f5b5600$060210ac@private>


> -----Original Message-----
> From: Tim Peters [mailto:tim_one at email.msn.com]
> Sent: 08 October 2000 20:29
> To: Barry Scott; PythonDev; Python list
> Subject: RE: [Python-Dev] Python 2.0b2 note for Windows developers
> 
> 
> [Barry]
> > 	Two requests:
> >
> > 1. Can you ship the .PDB files for the debug images so devo's
> >    do not need to build the python sources to debug extensions.
> >    And Yes I know the .ZIP will be huge. If you want a
> >    compromise only include the .PDB for python20_d.dll.
> 
> Sure!  Most .pdb files are highly compressible, and the zip size hit isn't
> anything to worry about.

	Thanks

> 
> > 2. Place the files into libs, pyd etc dirs. I had to extract
> >    the groups into the right places which is a bit tedious
> >    and error prone.
> 
> No.  If you want a directory structure that doesn't match the actual build
> directory structure, I can't read your mind, and have no reason to believe
> that the specific artificial structure you have in mind is of use to anyone

	The structure I refer to is the one used by the Python Windows installer.

> but you.  Don't be so helpless <wink>:  write a tiny Python script to move

	I comment not because I'm lazy but because it seemed that every
	developer would need to reorganise the files.

> the files where you want them after unpacking.  What I upload will be an
> exact image of the build directory structure.  Most feedback I've gotten is
> that people want exactly that, because they *want* to compile Python

	I'd not thought of that. MY assumption was that I build the release
	windows code against the files installed by the python windows installer.
	And that the debug settings would logically point into the same
	structure.

> themselves and just want to avoid jumping thru all the snaky hoops needed to
> compile the 3rd-party subprojects (from _tkinter to zlib).
> 
> alphabetically y'rs  - tim

		Barry




From MarkH at ActiveState.com  Sun Oct 15 01:53:03 2000
From: MarkH at ActiveState.com (Mark Hammond)
Date: Sun, 15 Oct 2000 10:53:03 +1100
Subject: [Python-Dev] Python 2.0b2 note for Windows developers
In-Reply-To: <000001c03636$7f5b5600$060210ac@private>
Message-ID: <ECEPKNMJLHAPFFJHDOJBGEJADNAA.MarkH@ActiveState.com>

[Tim]
> the files where you want them after unpacking.  What I upload
> will be an exact image of the build directory structure.  Most
> feedback I've gotten is that people want exactly that,
> because they *want* to compile Python

[Barry]
> I'd not thought of that.

My either.  I must admit mild surprise at that.  If people want the debug
files in the same tree as the build tree, it seems all they are trying to
do is avoid the initial huge build.  If they intend compiling, why are they
asking for the binaries?

My experience with people wanting debug binaries is that they either don't
want to, or can not build.  When people need debug binaries, they go one of
2 routes - try and find pre-built debugs, or build them themselves.  I
can't see when people ever do both.

For the last year or so, I have been making Debug builds of win32all
available to registered users.  This has always been made available in the
"install" structure - quite a bit different than the source/build
structure.  I've never been asked for anything different.

Just-FWIW ly,

Mark.




From nick at nickbower.com  Sun Oct 15 07:09:26 2000
From: nick at nickbower.com (Nick Bower)
Date: Sun, 15 Oct 2000 05:09:26 GMT
Subject: [Python-Dev] RE: [Numpy-discussion] RE: Possible bug (was Re:
 numpy,  overflow, inf, ieee, and rich comparison)
In-Reply-To: <39E7B554.29A168E3@jps.net>
References: <LNBBLJKPBEHFEDALKOLCEEACHLAA.tim_one@email.msn.com> <39E7B554.29A168E3@jps.net>
Message-ID: <20001015.5092600@cricket.>

> Does anyone know what other array-oriented languages use? I know what
> MATLAB does:

I'm an Interactive Data Language or IDL user (the Univ of Wisconsin's 
Space Science Ceter is split down the middle between this and MatLab,  
but python/numpy is definitely on the increase).  As you can see from 
results below, like MatLab over/under-flows in IDL are reported but do 
not stop execution.  This is the best (only) possible scenario for an 
interactive arrays and visualization environment.

IDL> print, exp(-777)
      0.00000
% Program caused arithmetic error: Floating underflow
IDL> print, exp(777)
          Inf
% Program caused arithmetic error: Floating overflow
IDL> print, sqrt(-1)
         -NaN
% Program caused arithmetic error: Floating illegal operand
IDL> print, 54/0
      54
% Program caused arithmetic error: Integer divide by 0





From martin at loewis.home.cs.tu-berlin.de  Sun Oct 15 17:57:18 2000
From: martin at loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Sun, 15 Oct 2000 17:57:18 +0200
Subject: [Python-Dev] Mandrake vs glibc
Message-ID: <200010151557.RAA05091@loewis.home.cs.tu-berlin.de>

> So, if David's report is correct, and best I understand it you were
> all using 7.1 too with at least some level of optimization, it's A
> Mystery why CVS test_math.py succeeds on that system (its new
> math.sqrt(-1) test would probably fail; its new math.exp(+huge) test
> would almost certainly fail).  I'm anal enough about this stuff that
> I'd try to figure out why if I had a Mandrake system, but in the
> cosmic scheme of things I doubt it's important enough for anyone
> else to burn time on.

Well, I don't know about Mandrake, but I have glibc 2.1.94 here, and I
get

Python 2.0 (#104, Oct 15 2000, 15:47:19) 
[GCC 2.95.2 19991024 (release)] on linux2
Type "copyright", "credits" or "license" for more information.
>>> import math
>>> math.sqrt(-1)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
OverflowError: math range error
>>> math.exp(800)
inf
>>> math.exp(-800)
0.0

It turns that Tcl8.3 and Tk8.3, on my system, link with -lieee. That
is implemented as

_LIB_VERSION_TYPE _LIB_VERSION = _IEEE_;

in this version of glibc, which in turn changes the behaviour of 

double __exp(double x)		/* wrapper exp */
{
	double z;
	z = __ieee754_exp(x);
	if(_LIB_VERSION == _IEEE_) return z;
	if(__finite(x)) {
	    if(x>o_threshold)
	        return __kernel_standard(x,x,6); /* exp overflow */
	    else if(x<u_threshold)
	        return __kernel_standard(x,x,7); /* exp underflow */
	}
	return z;
}

As a rationale for linking with -lieee, the Tcl/Tk configure.in offers

#       Also, Linux requires the "ieee" library for math to
#       work right (and it must appear before "-lm").

Without testing, it seems that this would give some interesting
consequences on installations where Tkinter is a shared module: the
outcome of these functions could depend on whether Tkinter is imported
or not. I can't produce such a scenario with the BeOpen binaries on a
RedHat systems; the Tcl 8.0 RPMs of RedHat include the
tcltk-8.0-ieee.patch, which removes the line 

AC_CHECK_LIB(ieee, main, [MATH_LIBS="-lieee $MATH_LIBS"])

from both Tcl's and Tk's configure.in.

Of course, the problem is not restricted to Tcl: any extension module
that links with a shared library that includes libieee.a would change
the behaviour of Python's math functions.

Regards,
Martin




From martin at loewis.home.cs.tu-berlin.de  Sun Oct 15 18:43:23 2000
From: martin at loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Sun, 15 Oct 2000 18:43:23 +0200
Subject: [Python-Dev] distutils extra sources
Message-ID: <200010151643.SAA05423@loewis.home.cs.tu-berlin.de>

> Can you recommend how to include this in the source distribution for
> the final release?

Even though I was not asked, I still answer :-) I think having the
source code for the installer is essential, just so that people won't
get frightened by the potential for a Trojan Horse in front of the
gates (or, rather, the windows?-)

I'd put the installer (i.e. all of distutils/misc except for
get_metadata.py) into Tools/wininst.  (I'd actually preferred to see
the wininst sources in distutils in a different directory as well).

In case you need some descripting text as well, here's my proposal.
In Tools/README, maybe it would be

wininst    Sources for Windows installer of distutils.command.bdist_wininst.

For Tools/wininst/README, see the text below.

One complication is that invoking bdist_wininst as a program will
regenerate the module, but it expects the installer binary in
../../misc/wininst.exe; I'm not sure whether it is worth the effort to
change that for the Python distribution.

Regards,
Martin

THE WINDOWS INSTALLER
=====================

The distutils support the command bdist_wininst, which will produce a
windows auto-installing executable using the information in the setup
function. The executable consists of a user interface program,
concatenated with a zip archive of the distributed files. This
directory contains the sources of the user interface program. The
bdist_wininst command itself does not need the sources, instead, it
has an embedded copy of the installer binary file. If the installer
program is modified, bdist_wininst.py must be updated by invoking it
as a program (i.e. "python bdist_wininst.py")

Building the installer
----------------------

To build the installer, you need a copy of Microsoft Visual C++
version 6; the project file is wininst.dsp. You may also use the
executable compressor UPX, which is available from
http://upx.tsx.org. UPX must be installed into c:\util. Using UPX is
not strictly required - it just reduces the size of the installation
program itself.

Using the bdist_wininst command
-------------------------------
To create an binary distribution of your package for Windows, simply
invoke "python setup.py bdist_wininst" in your package directory. If
your package does not contain C modules, you may invoke this command
on any system; if it does contain C modules, bdist_wininst will need
the C compiler used to build Python (typically MSVC++). It will not
need MSVC++ or UPX to build the setup program.

To build the ZIP file contained in the installer, bdist_wininst will
first try an external zip program (zip.exe) that understands the -rq
option, such as Info-ZIP
(http://www.info-zip.org/pub/infozip/Zip.html). If no such program is
found, it will next try the zipfile module, which is available if
Python was build with zlib support.




From larsga at garshol.priv.no  Sun Oct 15 19:52:16 2000
From: larsga at garshol.priv.no (Lars Marius Garshol)
Date: 15 Oct 2000 19:52:16 +0200
Subject: [Python-Dev] Simple xml.sax example?
In-Reply-To: <14824.21089.373315.436615@cj42289-a.reston1.va.home.com>
References: <14823.43218.337621.157021@beluga.mojam.com> 	<m34s2fpvx3.fsf@lambda.garshol.priv.no> <14824.21089.373315.436615@cj42289-a.reston1.va.home.com>
Message-ID: <m3vguunga7.fsf@lambda.garshol.priv.no>

* Lars Marius Garshol
|
| Here are a couple from an internal seminar I recently gave on this.
| I could make the slides available as well, if there is interest.

* Fred L. Drake, Jr.
| 
| Could we include this in Demos/xml/ ?

Sure.  Do whatever you like with them.  

--Lars M.




From hinsen at cnrs-orleans.fr  Sun Oct 15 21:04:27 2000
From: hinsen at cnrs-orleans.fr (Konrad Hinsen)
Date: Sun, 15 Oct 2000 21:04:27 +0200
Subject: [Python-Dev] RE: [Numpy-discussion] RE: Possible bug (was Re: numpy, 
 overflow, inf, ieee, and rich comparison)
In-Reply-To: <39E7B554.29A168E3@jps.net> (message from Chris Barker on Fri, 13
	Oct 2000 18:22:28 -0700)
References: <LNBBLJKPBEHFEDALKOLCEEACHLAA.tim_one@email.msn.com> <39E7B554.29A168E3@jps.net>
Message-ID: <200010151904.VAA32561@chinon.cnrs-orleans.fr>

> I've come to Python from MATLAB for numerics, and I really appreciated
> MATLAB's way of handling all this. I don't think MATLAB has true 754

MATLAB is fine for simple interactive data processing, and its
behaviour is adapted to this task. I don't think anyone would use
MATLAB for developing complex algorithms, its programming language
isn't strong enough for that. Python is, so complex algorithms have to
be considered as well. And for that kind of application, continuing a
calculation with Infs and NaNs is a debugging nightmare.

> I have not yet heard a decent response to the question of what to do
> when a single value in a large array is bad, and causes an exception.

I'd like to have at least the option of raising an exception in that
case. Note that this is not what NumPy does today.

> >> sqrt(-1)
> ans =
>	   0 + 1.0000i
>
> Hey! I like that! Python is dynamic, why can't we just get the actual
> answer to sqrt(-1), without using cmath, that always returns a complex ?

For the same reason that makes 2/3 return zero instead of a float
division result. Like C or Fortran, Python treats integers, floats,
and complex numbers as different data types. And the return type of a
function should depend only on the types, but not the values, of its
parameters (for consistency, not because of any implementational
limitation). So sqrt(a) for a of type float can either always return a
float (math, Numeric) and crash for negative arguments, or always
return a complex (cmath).

The "right" solution, in my opinion, would be to have a single
"number" type of which integers, float, and complex numbers are simply
different internal representations. But such a change cannot be
introduced without breaking a lot of code.

Konrad.
--
-------------------------------------------------------------------------------
Konrad Hinsen                            | E-Mail: hinsen at cnrs-orleans.fr
Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24
Rue Charles Sadron                       | Fax:  +33-2.38.63.15.17
45071 Orleans Cedex 2                    | Deutsch/Esperanto/English/
France                                   | Nederlands/Francais
-------------------------------------------------------------------------------



From tim_one at email.msn.com  Sun Oct 15 21:22:09 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Sun, 15 Oct 2000 15:22:09 -0400
Subject: [Python-Dev] Python 2.0b2 note for Windows developers
In-Reply-To: <000001c03636$7f5b5600$060210ac@private>
Message-ID: <LNBBLJKPBEHFEDALKOLCCEFKHLAA.tim_one@email.msn.com>

[Tim]
> the files where you want them after unpacking.  What I upload
> will be an exact image of the build directory structure.  Most
> feedback I've gotten is that people want exactly that,
> because they *want* to compile Python

[Barry Scott]
> I'd not thought of that.

[Mark Hammond]
> My either.  I must admit mild surprise at that.

Not me, because this is the Python core:  extension writers often have
problems with their use of the Python C API, and the core is what supplies
that.  It's not surprising that they want to, e.g., drop some printfs into
Python itself to see what's going on.  Then they need to recompile Python.
Plus that all the examples and instructions for building extensions assume
you're working in a build-- not a release --tree.

> If people want the debug files in the same tree as the build tree,

Some people, not all; by my informal count so far, "most", but it's like 2
or 3 to 1 -- and that's not only a ratio but a grand-total count.

> it seems all they are trying to do is avoid the initial huge build.  If
> they intend compiling, why are they asking for the binaries?

The "huge initial build" is no more than a few minutes, *provided* that they
don't have to crawl over the web too to get source for, and figure out what
to do with, the subprojects w/ a 3rd-party component (_tkinter, bsddb,
pyexpat and zlib).  Dealing with the latter for the first time can consume
hours.

> My experience with people wanting debug binaries is that they either don't
> want to, or can not build.

If they can't build, it's hard to take their claim to be developing
extension modules seriously <wink>.

> ...
> For the last year or so, I have been making Debug builds of win32all
> available to registered users.  This has always been made available in
> the "install" structure - quite a bit different than the source/build
> structure.  I've never been asked for anything different.

Were you *asked* for even that much?  Barry's was the first request Guido
recalls ever getting.  It sounded reasonable to me to supply *something*, so
I did.  But the download stats for this zip file suggest it's not popular
enough to be worth  arguing over.  Still, I've gotten a little feedback on
it, and most people seem to be happy.  Not all developers want the same
thing, and a flat .zip file with no internal directory structure is
maximally flexible.

If a handful of other Windows developers pop up who swear they can't live
with a flat file, and can't bear to write a little Python or .bat script to
move the files to where they want them, and swear they want some directory
structure that's a fuzzy generalization of the Windows install structure,
and swear they all want the same fuzzy generalization (e.g., where do they
want the .pdb files?  there are none in the install tree now), then, sure,
I'll make the *other* peoples' lives a bit more difficult by default.  I'm
not going to ship two (or more!) of these things, though.

view-it-as-a-chance-for-activestate-to-take-over<wink>-ly y'rs  - tim





From tim_one at email.msn.com  Sun Oct 15 22:35:27 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Sun, 15 Oct 2000 16:35:27 -0400
Subject: [Python-Dev] RE: [Numpy-discussion] RE: Possible bug (was Re: numpy,  overflow, inf, ieee, and rich comparison)
In-Reply-To: <200010151904.VAA32561@chinon.cnrs-orleans.fr>
Message-ID: <LNBBLJKPBEHFEDALKOLCGEFLHLAA.tim_one@email.msn.com>

[cbarker at jps.net]
>> I've come to Python from MATLAB for numerics, and I really appreciated
>> MATLAB's way of handling all this. I don't think MATLAB has true 754 ...

[Konrad Hinsen]
> MATLAB is fine for simple interactive data processing, and its
> behaviour is adapted to this task. I don't think anyone would use
> MATLAB for developing complex algorithms, its programming language
> isn't strong enough for that. Python is, so complex algorithms have to
> be considered as well. And for that kind of application, continuing a
> calculation with Infs and NaNs is a debugging nightmare.

A non-constructive (because futile) speculation:  the first time I saw what
754 was intending to do, my immediate reaction was "hmm -- the exponent
field is too narrow!".  With a max (double) val in the ballpark of 1e300,
you get an infinity as soon as you square something as small as 1e150, and
once you get a few infinities, NaNs are sure to follow (due to Inf-Inf and
Inf/Inf).  The dynamic range for 754 singles is much smaller still.

There's no doubt about Cray arithmetic being hard to live with, but while
Mr. Cray didn't worry about proper rounding, he did devote 15 bits to Cray's
exponent field (vs. 11 for 754).  As a result, overflows were generally a
non-issue on Cray boxes, and *nobody* complained (in my decade there) about
Cray HW raising a fatal exception if one occurred.

In return, you got only 48 bits of precision (vs. 53 for 754).  But, for
most physical problems, how accurate are the inputs?  10 bits on a good day,
20 bits on a great day?  Crays worked despite their sloppy numerics because,
for most problems to which they were applied, they carried more than twice
the precision *and* dynamic range than the final results needed.

>> I have not yet heard a decent response to the question of what to do
>> when a single value in a large array is bad, and causes an exception.

I'd usually trace back and try to figure out how it got "bad" to begin with
...

> I'd like to have at least the option of raising an exception in that
> case. Note that this is not what NumPy does today.

Does NumPy use the fpectl module?  I suppose not.  LLNL contribued that
code, but we hear very little feedback on it.  It arranges to (in
platform-dependent ways) convert the 754 overflow, divide-by-0 and
invalid-operation signals into Python exceptions.  In core Python, this is
accomplished at the extraordinary expense of doing a setjmp before, and a
function call + double->int conversion after, every single fp operation.  A
chief problem is that SIGFPE is the only handle C gives us on fp "errors",
and the C std does not allow returning from a SIGFPE handler (the result of
trying to is undefined, and indeed varies wildly across platforms); so if
you want to regain control, you have to longjmp out of the handler.

The NumPy implementation could use the PyFPE_START_PROTECT and
PyFPE_END_PROTECT macros to brackete entire array operations, though, and so
pay for the setjmp etc only once per array op.  This is difficult stuff, but
doable.


>> >> sqrt(-1)
>> ans =
>>	   0 + 1.0000i
>>
>> Hey! I like that! Python is dynamic, why can't we just get the actual
>> answer to sqrt(-1), without using cmath, that always returns a complex ?

> For the same reason that makes 2/3 return zero instead of a float
> division result. Like C or Fortran, Python treats integers, floats,
> and complex numbers as different data types.

You know I'm in general agreement with you on this one, but I have to draw a
distinction here:  Guido thinks that 2/3 returning 0 was a design mistake,
but not that math.sqrt(-1) raising an exception is a mistake.  Most Python
users won't know what to do with a complex number, so it's "an error" to
them.  I would like to view this in P3K (if not earlier) as being akin to
754 exceptions:  some people are delighted to have 1e300**2 return +Inf,
while others want to see OverflowError instead, and still others want to see
+Inf *and* have a sticky flag set saying "an overflow occurred".  We could
treat f(x) (for f == sqrt and everything else) the same way wrt to a new
ComplexResultFromNonComplexInputsError:  define "non-stop" complex results,
let the user choose whether to do nonstop or raise an exception, and a
supply a sticky flag saying whether or not any complex results were
generated from non-complex inputs.

> ...
> The "right" solution, in my opinion, would be to have a single
> "number" type of which integers, float, and complex numbers are simply
> different internal representations. But such a change cannot be
> introduced without breaking a lot of code.

The current distinction between ints and longs (unbounded ints) should also
get swallowed by this.  A way to get from here to there is especially
irksome at the C API level, since, e.g., many C API functions pass Python
ints as C longs directly.  A smaller number pass Python floats as C doubles
directly.

it's-wonderful-that-p3k-will-solve-everything<wink>-ly y'rs  - tim





From MarkH at ActiveState.com  Mon Oct 16 01:49:19 2000
From: MarkH at ActiveState.com (Mark Hammond)
Date: Mon, 16 Oct 2000 10:49:19 +1100
Subject: [Python-Dev] Wierd buffer "add" behaviour.
Message-ID: <ECEPKNMJLHAPFFJHDOJBIEJMDNAA.MarkH@ActiveState.com>

I just struck this, and wonder if it is intentional:

* Adding 2 buffer objects together yields a string.  Fair enough.
* Adding a buffer and a string yields a type error!  Eeek.

This yields the following strange behaviour:

>>> a=buffer('a')
>>> a+a
'aa'
>>> a+a+a
Traceback (innermost last):
  File "<interactive input>", line 1, in ?
TypeError: cannot add type "buffer" to string
>>> 

That doesnt seem correct to me?

Mark.



From rob at hooft.net  Mon Oct 16 07:39:13 2000
From: rob at hooft.net (Rob W. W. Hooft)
Date: Mon, 16 Oct 2000 07:39:13 +0200 (CEST)
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib calendar.py,1.17,1.18
In-Reply-To: <200010091242.FAA02671@slayer.i.sourceforge.net>
References: <200010091242.FAA02671@slayer.i.sourceforge.net>
Message-ID: <14826.38017.352907.716552@temoleh.chem.uu.nl>

Just checking my E-mail coming back from holidays, I see:

  diff -C2 -r1.17 -r1.18
  *** calendar.py 2000/08/30 14:01:28     1.17
  --- calendar.py 2000/10/09 12:42:04     1.18
  ***************
  *** 55,60 ****
    def leapdays(y1, y2):
        """Return number of leap years in range [y1, y2).
  !        Assume y1 <= y2 and no funny (non-leap century) years."""
  !     return (y2+3)/4 - (y1+3)/4

    def weekday(year, month, day):
  --- 55,62 ----
    def leapdays(y1, y2):
        """Return number of leap years in range [y1, y2).
  !        Assume y1 <= y2."""
  !     y1 -= 1
  !     y2 -= 1
  !     return (y2/4 - y1/4) - (y2/100 - y1/100) + (y2/400 - y1/400)

    def weekday(year, month, day):

I am worried about the use of "-=" here. The code basically says: "if the
arguments are mutable numeric types, I'd like to modify them in place". In
c.l.py it has been stressed multiple times that "-=" is not the same as
"=   -". I think this is clearly a place where "=   -" is preferable over
"-=". Even though you might think people will always call this with 
python integers, you can never be sure enough.

Rob

-- 
=====   rob at hooft.net          http://www.hooft.net/people/rob/  =====
=====   R&D, Nonius BV, Delft  http://www.nonius.nl/             =====
===== PGPid 0xFA19277D ========================== Use Linux! =========



From pf at artcom-gmbh.de  Mon Oct 16 09:23:11 2000
From: pf at artcom-gmbh.de (Peter Funk)
Date: Mon, 16 Oct 2000 09:23:11 +0200 (MEST)
Subject: [Python-Dev] gettext may fail to find .mo file (was Re: [PATCH] gettext)
In-Reply-To: <lblmvq8czj.fsf@mask.tf.hut.fi>
Message-ID: <m13l4c3-000Dm8C@artcom0.artcom-gmbh.de>

Hi Ulf,

Ulf Betlehem:
[...]
>         ok, I compiled 2.0c1 and tried gettext. Now, there seems to be
>         a bug in the "normalize and expand" code that can prevent
>         gettext from finding an existing .mo file. The normalization
>         is done using a dictionary and therefore the languages get
>         reordered (as dict keys do). Later when selecting language the
>         function returns None if 'C' happens to come before the
>         required languages. I've included a patch to fix this.

Your patch looks good to me.  Thanks for taking the time to test and 
contributing the patch.  I've submitted your bug report and your 
patch to sourceforge.

See:
https://sourceforge.net/bugs/?func=detailbug&bug_id=116964&group_id=5470
https://sourceforge.net/patch/?func=detailpatch&patch_id=101928&group_id=5470

Regards, Peter
P.S.: Cc to python-dev
-- 
Peter Funk, Oldenburger Str.86, D-27777 Ganderkesee, Germany, Fax:+49 4222950260
office: +49 421 20419-0 (ArtCom GmbH, Grazer Str.8, D-28359 Bremen)



From mal at lemburg.com  Mon Oct 16 09:50:22 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Mon, 16 Oct 2000 09:50:22 +0200
Subject: [Python-Dev] Wierd buffer "add" behaviour.
References: <ECEPKNMJLHAPFFJHDOJBIEJMDNAA.MarkH@ActiveState.com>
Message-ID: <39EAB33E.35B72EA4@lemburg.com>

Mark Hammond wrote:
> 
> I just struck this, and wonder if it is intentional:
> 
> * Adding 2 buffer objects together yields a string.  Fair enough.
> * Adding a buffer and a string yields a type error!  Eeek.

This just seems plain wrong. Adding two buffers should yield
a new buffer -- in the long run, buffers should replace strings
wrt to holding binary data. If not even buffers themselves
implement this idea, I don't see any perspective for ever getting
there...
 
> This yields the following strange behaviour:
> 
> >>> a=buffer('a')
> >>> a+a
> 'aa'
> >>> a+a+a
> Traceback (innermost last):
>   File "<interactive input>", line 1, in ?
> TypeError: cannot add type "buffer" to string
> >>>
> 
> That doesnt seem correct to me?

Neither to me.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From thomas.heller at ion-tof.com  Mon Oct 16 11:14:49 2000
From: thomas.heller at ion-tof.com (Thomas Heller)
Date: Mon, 16 Oct 2000 11:14:49 +0200
Subject: [Python-Dev] Wierd buffer "add" behaviour.
References: <ECEPKNMJLHAPFFJHDOJBIEJMDNAA.MarkH@ActiveState.com>
Message-ID: <037601c03751$88ecc1b0$e000a8c0@thomasnotebook>

IMHO, the whole buffer interface is weird.

- Only the Buffer_FromObject() function is exposed to the python
level (as buffer()), the other functions are missing. This
means that one could only use the buffer interface in
extension modules. Was this intentional?

- No way a python class can expose the buffer interface

- There is a bug in the buffer interface (which
prevented recently that I could use buffer objects
at all, I had to implement my own)

PyObject *base = PyBuffer_New(100);
PyObject *buffer = PyBuffer_FromObject(base, 0, 100);
Py_DECREF(base);

After this code is executed,
buffer points to deallocated memory (because
buffer does not hold a reference to base anymore).

(Guido classified this as a wish, but at least
it contradicts the documentation)

Thomas




From MarkH at ActiveState.com  Mon Oct 16 11:38:26 2000
From: MarkH at ActiveState.com (Mark Hammond)
Date: Mon, 16 Oct 2000 20:38:26 +1100
Subject: [Python-Dev] Wierd buffer "add" behaviour.
In-Reply-To: <037601c03751$88ecc1b0$e000a8c0@thomasnotebook>
Message-ID: <ECEPKNMJLHAPFFJHDOJBMEKHDNAA.MarkH@ActiveState.com>

> IMHO, the whole buffer interface is weird.

I'm not sure that weird is the correct term for your points (it is for my
spelling, though :-)

> - Only the Buffer_FromObject() function is exposed to the
...
> - No way a python class can expose the buffer interface

These are simply oversights, I would suggest.  Nothing in the design
prevents this.

> - There is a bug in the buffer interface (which
> prevented recently that I could use buffer objects
> at all, I had to implement my own)

This looks like quite a simple bug.  bufferobject.c, line 77:

	/* if the base object is another buffer, then "deref" it */
	if ( PyBuffer_Check(base) )
		base = ((PyBufferObject *)base)->b_base;

if the condition was changed to:

	if ( PyBuffer_Check(base) && ((PyBufferObject *)base)->b_base)

Then I think this one would be solved?

A more serious design flaw is the one Fredrik pointed out quite some time
ago.  If you have (eg.) an "array" object and query for its buffer, life is
good.  If the array then resizes itself, your pointer is now dangling.  The
simplest solution to this is probably to simply define the lifetimes of
these pointers as very very short ;-)

Mark.




From mal at lemburg.com  Mon Oct 16 12:14:46 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Mon, 16 Oct 2000 12:14:46 +0200
Subject: [Python-Dev] Wierd buffer "add" behaviour.
References: <ECEPKNMJLHAPFFJHDOJBMEKHDNAA.MarkH@ActiveState.com>
Message-ID: <39EAD516.7EA34C20@lemburg.com>

Mark Hammond wrote:
> [Problems with the buffer interface]
> If you have (eg.) an "array" object and query for its buffer, life is
> good.  If the array then resizes itself, your pointer is now dangling.  The
> simplest solution to this is probably to simply define the lifetimes of
> these pointers as very very short ;-)

...or disable the buffer interface for mutable types altogether !

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From gstein at lyra.org  Mon Oct 16 15:01:26 2000
From: gstein at lyra.org (Greg Stein)
Date: Mon, 16 Oct 2000 06:01:26 -0700
Subject: [Python-Dev] Wierd buffer "add" behaviour.
In-Reply-To: <39EAB33E.35B72EA4@lemburg.com>; from mal@lemburg.com on Mon, Oct 16, 2000 at 09:50:22AM +0200
References: <ECEPKNMJLHAPFFJHDOJBIEJMDNAA.MarkH@ActiveState.com> <39EAB33E.35B72EA4@lemburg.com>
Message-ID: <20001016060126.X347@lyra.org>

On Mon, Oct 16, 2000 at 09:50:22AM +0200, M.-A. Lemburg wrote:
> Mark Hammond wrote:
>...
> > This yields the following strange behaviour:
> > 
> > >>> a=buffer('a')
> > >>> a+a
> > 'aa'
> > >>> a+a+a
> > Traceback (innermost last):
> >   File "<interactive input>", line 1, in ?
> > TypeError: cannot add type "buffer" to string
> > >>>
> > 
> > That doesnt seem correct to me?
> 
> Neither to me.

It is caused by the non-commutative aspect of Python types. You end up with
a string, and that type doesn't know how to add a buffer to itself.

Ideally, it might be nice to allow a string to append any object that
exports the buffer-interface. But when somebody goes and writes
"abc"+my_array ... hoo boy, will we hear complaints.

The alternative is to allow the buffer to resolve the type conflict and do
the appending within the buffer code.

Of course, the choice of returning a string (from buf+buf) rather than a
buffer was arguably the wrong choice.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/



From guido at python.org  Mon Oct 16 16:30:44 2000
From: guido at python.org (Guido van Rossum)
Date: Mon, 16 Oct 2000 09:30:44 -0500
Subject: [Python-Dev] mutable integers
In-Reply-To: Your message of "Mon, 16 Oct 2000 07:39:13 +0200."
             <14826.38017.352907.716552@temoleh.chem.uu.nl> 
References: <200010091242.FAA02671@slayer.i.sourceforge.net>  
            <14826.38017.352907.716552@temoleh.chem.uu.nl> 
Message-ID: <200010161430.JAA28885@cj20424-a.reston1.va.home.com>

Rob W. W. Hooft:

> Just checking my E-mail coming back from holidays, I see:
[...]
>     def leapdays(y1, y2):
>         """Return number of leap years in range [y1, y2).
>   !        Assume y1 <= y2."""
>   !     y1 -= 1
>   !     y2 -= 1
>   !     return (y2/4 - y1/4) - (y2/100 - y1/100) + (y2/400 - y1/400)
> 
> I am worried about the use of "-=" here. The code basically says: "if the
> arguments are mutable numeric types, I'd like to modify them in place". In
> c.l.py it has been stressed multiple times that "-=" is not the same as
> "=   -". I think this is clearly a place where "=   -" is preferable over
> "-=". Even though you might think people will always call this with 
> python integers, you can never be sure enough.

Hmm...  Your fear sounds a little paranoid for this particular case,
but I can't say that I totally disagree in general.  This is
definitely something to keep in mind when writing polymorphic
functions for which a NumPy array might be an acceptable input
argument.

I don't think it's worth checking in a patch in this case.

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



From hinsen at cnrs-orleans.fr  Mon Oct 16 17:52:43 2000
From: hinsen at cnrs-orleans.fr (Konrad Hinsen)
Date: Mon, 16 Oct 2000 17:52:43 +0200
Subject: [Python-Dev] RE: [Numpy-discussion] RE: Possible bug (was Re: numpy,  overflow, inf, ieee, and rich comparison)
In-Reply-To: <LNBBLJKPBEHFEDALKOLCGEFLHLAA.tim_one@email.msn.com>
References: <LNBBLJKPBEHFEDALKOLCGEFLHLAA.tim_one@email.msn.com>
Message-ID: <200010161552.RAA02685@chinon.cnrs-orleans.fr>

> > I'd like to have at least the option of raising an exception in that
> > case. Note that this is not what NumPy does today.
> 
> Does NumPy use the fpectl module?  I suppose not.  LLNL contribued that

No. Perhaps it should, but it doesn't make sense unless fpectl works
on a large number of platforms. I confess I have never looked at it. I
want my code to be portable, so I don't even consider using packages
that aren't.

> > For the same reason that makes 2/3 return zero instead of a float
> > division result. Like C or Fortran, Python treats integers, floats,
> > and complex numbers as different data types.
> 
> You know I'm in general agreement with you on this one, but I have to draw a
> distinction here:  Guido thinks that 2/3 returning 0 was a design mistake,
> but not that math.sqrt(-1) raising an exception is a mistake.  Most Python
> users won't know what to do with a complex number, so it's "an error" to
> them.

Well, that would be a good occasion to learn about complex numbers! I
remember having learned about generalized inverses by using APL in
high school (in a very similar way: I was amazed that it could invert
non-square matrices), and that turned out to be very useful knowledge
later on. Perhaps that's a topic for the EDU-SIG...

Anyway, I don't care what math.sqrt(-1) does, but I would definitely
prefer Numeric.sqrt(-1) to return a complex result. And I think that
someone who uses NumPy has probably heard about complex numbers.


> I would like to view this in P3K (if not earlier) as being akin to
> 754 exceptions:  some people are delighted to have 1e300**2 return +Inf,
> while others want to see OverflowError instead, and still others want to see
> +Inf *and* have a sticky flag set saying "an overflow occurred".  We could
> treat f(x) (for f == sqrt and everything else) the same way wrt to a new
> ComplexResultFromNonComplexInputsError:  define "non-stop" complex results,
> let the user choose whether to do nonstop or raise an exception, and a
> supply a sticky flag saying whether or not any complex results were
> generated from non-complex inputs.

There is, however, one difference: in properly debugged production
code, there should be no overflow situations, so it doesn't matter
much how they are treated. Complex number can (do!) occur in
production code, but there could also be production code relying on
exceptions for sqrt(-1) (e.g. for input error checking). Therefore a
program using several libraries might be impossible to run with either
setting.

Since this concerns only the math module, I'd prefer to keep separate
module versions for the two cases, which can be used in parallel.

> > The "right" solution, in my opinion, would be to have a single
> > "number" type of which integers, float, and complex numbers are simply
> > different internal representations. But such a change cannot be
> > introduced without breaking a lot of code.
> 
> The current distinction between ints and longs (unbounded ints) should also
> get swallowed by this.  A way to get from here to there is especially
> irksome at the C API level, since, e.g., many C API functions pass Python
> ints as C longs directly.  A smaller number pass Python floats as C doubles
> directly.

I don't see the problem in that direction, it's rather C API functions
that *return* numbers in C data types that would be difficult to
adapt. But then, why should be C API not be allowed in P3K?

it's-wonderful-that-anything-may-be-changed-in-p3k'ly
  Konrad.
-- 
-------------------------------------------------------------------------------
Konrad Hinsen                            | E-Mail: hinsen at cnrs-orleans.fr
Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24
Rue Charles Sadron                       | Fax:  +33-2.38.63.15.17
45071 Orleans Cedex 2                    | Deutsch/Esperanto/English/
France                                   | Nederlands/Francais
-------------------------------------------------------------------------------



From guido at python.org  Mon Oct 16 20:08:07 2000
From: guido at python.org (Guido van Rossum)
Date: Mon, 16 Oct 2000 13:08:07 -0500
Subject: [Python-Dev] The buffer interface
In-Reply-To: Your message of "Mon, 16 Oct 2000 06:01:26 MST."
             <20001016060126.X347@lyra.org> 
References: <ECEPKNMJLHAPFFJHDOJBIEJMDNAA.MarkH@ActiveState.com> <39EAB33E.35B72EA4@lemburg.com>  
            <20001016060126.X347@lyra.org> 
Message-ID: <200010161808.NAA32318@cj20424-a.reston1.va.home.com>

The buffer interface is one of the most misunderstood parts of
Python.  I believe that if it were PEPped today, it would have a hard
time getting accepted in its current form.

There are also two different parts that are commonly referred by this
name: the "buffer API", which is a C-only API, and the "buffer
object", which has both a C API and a Python API.

Both were largely proposed, implemented and extended by others, and I
have to admit that I'm still uneasy with defending them, especially
the buffer object.  Both are extremely implementation-dependent (in
JPython, neither makes much sense).

The Buffer API
--------------

The C-only buffer API was originally intended to allow efficient
binary I/O from and (in some cases) to large objects that have a
relatively well-understood underlying memory representation.  Examples
of such objects include strings, array module arrays, memory-mapped
files, NumPy arrays, and PIL objects.

It was created with the desire to avoid an expensive memory-copy
operation when reading or writing large arrays.  For example, if you
have an array object containing several millions of double precision
floating point numbers, and you want to dump it to a file, you might
prefer to do the I/O directly from the array's memory buffer rather
than first copying it to a string.  (You lose portability of the data,
but that's often not a problem the user cares about in these cases.)

An alternative solution for this particular problem was consdered:
object types in need of this kind of efficient I/O could define their
own I/O methods, thereby allowing them to hide their internal
representation.  This was implemented in some cases (e.g. the array
module has read() and write() methods) but rejected, because a
simple-minded implementation of this approach would not work with
"file-like" objects (e.g. StringIO files).  It was deemed important
that file-like objects would not place restrictions on the kind of
objects that could interact with them (compared to real file objects).

A possible solution would have been to require that each object
implementing its own read and write methods should support both
efficient I/O to/from "real" file objects and fall-back I/O to/from
"file-like" objects.  The fall-back I/O would have to convert the
object's data to a string object which would then be passed to the
write() method of the file-like object.  This approach was rejected
because it would make it impossible to implement an alternative file
object that would be as efficient as the real file object, since large
object I/O would be using the inefficient fallback interface.

To address these issues, we decided to define an interface that would
let I/O operations ask the objects where their data bytes are in
memory, so that the I/O can go directly to/from the memory allocated
by the object.  This is the classic buffer API.  It has a read-only
and a writable variant -- the writable variant is for mutable objects
that will allow I/O directly into them.  Because we expected that some
objects might have an internal representation distributed over a
(small) number of separately allocated pieces of memory, we also added
the getsegcount() API.  All objects that I know support the buffer API
return a segment count of 1, and most places that use the buffer API
give up if the segment count is larger; so this may be considered as
an unnecessary generalization (and source of complexity).

The buffer API has found significant use in a way that wasn't
originally intended: as a sort of informal common base class for
string-like objects in situations where a char[] or char* type must be
passed (in a read-only fashion) to C code.  This is in fact the most
common use of the buffer API now, and appears to be the reason why the
segment count must typically be 1.

In connection with this, the buffer API has grown a distinction
between character and binary buffers (on the read-only end only).
This may have been a mistake; it was intended to help with Unicode but
it ended up not being used.

The Buffer Object
-----------------

The buffer object has a much less clear reason for its existence.
When Greg Stein first proposed it, he wrote:

    The intent of this type is to expose a string-like interface from
    an object that supports the buffer interface (without making a
    copy). In addition, it is intended to support slices of the target
    object.

    My eventual goal here is to tweak the file object to support
    memory mapping and the buffer interface. The buffer object can
    then return slices of the file without making a new copy. Next
    step: change marshal.c, ceval.c, and compile.c to support a buffer
    for the co_code attribute. Net result is that copies of code
    streams don't need to be copied onto the heap, but can be left in
    an mmap'd file or a frozen file. I'm hoping there will be some
    perf gains (time and memory).

    Even without some of the co_code work, enabling mmap'd files and
    buffers onto them should be very useful. I can probably rattle off
    a good number of other uses for the buffer type.

I don't think that any of these benefits have been realized yet, and
altogether I think that the buffer object causes a lot of confusion.
The buffer *API* doesn't guarantee enough about the lifetime of the
pointers for the buffer *object* to be able to safely preserve those
pointers, even if the buffer object holds on to the base object.  (The
C-level buffer API informally guarantees that the data remains valid
only until you do anything to the base object; this is usually fine as
long as you don't release the global interpreter lock.)

The buffer object's approach to implementing the various sequence
operations is strange: sometimes it behaves like a string, sometimes
it doesn't.  E.g. a slice returns a new string object unless it
happens to address the whole buffer, in which case it returns a
reference to the existing buffer object.  It would seem more logical
that a subslice would return a new buffer object.  Concatenation and
repetition of buffer objects are likewise implemented inconsistently;
it would have been more consistent with the intended purpose if these
weren't supported at all (i.e. if none of the buffer object operations
would allocate new memory except for buffer object headers).

I would have concluded that the buffer object is entirely useless, if
it weren't for some very light use that is being made of it by the
Unicode machinery.  I can't quite tell whether that was done just
because it was convenient, or whether that shows there is a real
need.

What Now?
---------

I'm not convinced that we need the buffer object at all.  For example,
the mmap module defines a sequence object so doesn't seem to need the
buffer object to help it support slices.

Regarding the buffer API, it's clearly useful, although I'm not
convinced that it needs the multiple segment count option or the char
vs. binary buffer distinction, given that we're not using this for
Unicode objects as we originally planned.

I also feel that it would be helpful if there was an explicit way to
lock and unlock the data, so that a file object can release the global
interpreter lock while it is doing the I/O.  But that's not a high
priority (and there are no *actual* problems caused by the lack of
such an API -- just *theoretical*).

For Python 3000, I think I'd like to rethink this whole mess.  Perhaps
byte buffers and character strings should be different beasts, and
maybe character strings could have Unicode and 8-bit subclasses (and
maybe other subclasses that explicitly know about their encoding).
And maybe we'd have a real file base class.  And so on.

What to do in the short run?  I'm still for severely simplifing the
buffer object (ripping out the unused operations) and deprecating it.

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



From cbarker at jps.net  Mon Oct 16 19:38:11 2000
From: cbarker at jps.net (Chris Barker)
Date: Mon, 16 Oct 2000 10:38:11 -0700
Subject: [Python-Dev] Re: numpy,  overflow, inf, ieee, and rich comparison
References: <LNBBLJKPBEHFEDALKOLCGEFLHLAA.tim_one@email.msn.com>
Message-ID: <39EB3D03.A00C78B6@jps.net>


> >> I have not yet heard a decent response to the question of what to do
> >> when a single value in a large array is bad, and causes an exception.
> 
> I'd usually trace back and try to figure out how it got "bad" to begin with

And from Konrad Hinsen
>I'd like to have at least the option of raising an exception in that
>case. Note that this is not what NumPy does today.

Exactly. This was Huaiyu's point. The problem is that for your code to
be usable for folks other than yourself, you'd have to have a lot of
checks in there, and essentially revert to elementwise code, which would
kill you. With the addition of the occasional "isnan" and something like
Matlab's "any" ( "any(isnan(A))" returns true if any of the elements of
A are NaNs) you could set up your code to raise an exception in the
middle of computation. If, on the other hand the Code definiately raises
an exception, than you are stuck with a lot of elementwise coding.

> over/under-flows in IDL are reported but do 
> not stop execution.  This is the best (only) possible scenario for an 
> interactive arrays and visualization environment.

Exactly!!! ("the best (only) possible scenario" part)
 
> IDL> print, 54/0
>       54
> % Program caused arithmetic error: Integer divide by 0

This, however, is wierd!!  54/0 == 54 ??? I'd much rather see a NaN or
Inf here!

> MATLAB is fine for simple interactive data processing, and its
> behaviour is adapted to this task. I don't think anyone would use
> MATLAB for developing complex algorithms, its programming language
> isn't strong enough for that. Python is, so complex algorithms have to
> be considered as well. And for that kind of application, continuing a
> calculation with Infs and NaNs is a debugging nightmare.

People do some pretty complex algorith develpment with MATLAB. I'm also
no so sure about "continuing a calculation with Infs and NaNs is a
debugging nightmare" I'm don't think it's any more of a nighmare than
having your calculation on an entire array stop because of one Inf. It's
just a different trade off. Sprinkle a few "isnan"'s in there and and
you can get the behaviour you want, while not forcing it on all
calculations. Of course, the best option is to have it switchable, but
that may prove to be very difficult.

Are people doing the kind of numeric programming with "complex
algorithms" using Python that Konrad refers to? More importantly, how
many people?

>  Guido thinks that 2/3 returning 0 was a design mistake,
> but not that math.sqrt(-1) raising an exception is a mistake.  Most Python
> users won't know what to do with a complex number, so it's "an error" to
> them.

Guido's philosophy is clearly that Python defaults should be geared to
"Most Python users". I agree, and as I wrote in an earlier post, the
only users for whom the "exception raising only" option is best are the
users Konrad refers to as writing "complex algorithms". I would argue
that those users are few, and the group most able to deal with a
less-that-optimum system.

Maybe we can have true 754 compliance in Py3k, and we can all be happy!!

-Chris





-- 
Christopher Barker,
Ph.D.                                                           
cbarker at jps.net                      ---           ---           ---
http://www.jps.net/cbarker          -----@@       -----@@       -----@@
                                   ------@@@     ------@@@     ------@@@
Water Resources Engineering       ------   @    ------   @   ------   @
Coastal and Fluvial Hydrodynamics -------      ---------     --------    
------------------------------------------------------------------------
------------------------------------------------------------------------



From effbot at telia.com  Mon Oct 16 19:47:55 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Mon, 16 Oct 2000 19:47:55 +0200
Subject: [Python-Dev] The buffer interface
References: <ECEPKNMJLHAPFFJHDOJBIEJMDNAA.MarkH@ActiveState.com> <39EAB33E.35B72EA4@lemburg.com>             <20001016060126.X347@lyra.org>  <200010161808.NAA32318@cj20424-a.reston1.va.home.com>
Message-ID: <00f601c03799$39f2c7b0$3c6340d5@hagrid>

guido wrote:
> What to do in the short run?  I'm still for severely simplifing the
> buffer object (ripping out the unused operations) and deprecating it.

agreed.

(does this mean that we're in post-2.0 mode? ;-)

</F>




From mal at lemburg.com  Mon Oct 16 19:42:15 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Mon, 16 Oct 2000 19:42:15 +0200
Subject: [Python-Dev] Wierd buffer "add" behaviour.
References: <ECEPKNMJLHAPFFJHDOJBIEJMDNAA.MarkH@ActiveState.com> <39EAB33E.35B72EA4@lemburg.com> <20001016060126.X347@lyra.org>
Message-ID: <39EB3DF7.459A1BC1@lemburg.com>

Greg Stein wrote:
> 
> On Mon, Oct 16, 2000 at 09:50:22AM +0200, M.-A. Lemburg wrote:
> > Mark Hammond wrote:
> >...
> > > This yields the following strange behaviour:
> > >
> > > >>> a=buffer('a')
> > > >>> a+a
> > > 'aa'
> > > >>> a+a+a
> > > Traceback (innermost last):
> > >   File "<interactive input>", line 1, in ?
> > > TypeError: cannot add type "buffer" to string
> > > >>>
> > >
> > > That doesnt seem correct to me?
> >
> > Neither to me.
> 
> It is caused by the non-commutative aspect of Python types. You end up with
> a string, and that type doesn't know how to add a buffer to itself.

The problem is that buffer() objects coerce to strings in the
first place... they should return new buffer objects instead
of strings -- then we wouldn't have the above problems.
 
> ... 
> Of course, the choice of returning a string (from buf+buf) rather than a
> buffer was arguably the wrong choice.

Right :-/

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From guido at python.org  Mon Oct 16 20:51:51 2000
From: guido at python.org (Guido van Rossum)
Date: Mon, 16 Oct 2000 13:51:51 -0500
Subject: [Python-Dev] The buffer interface
In-Reply-To: Your message of "Mon, 16 Oct 2000 19:47:55 +0200."
             <00f601c03799$39f2c7b0$3c6340d5@hagrid> 
References: <ECEPKNMJLHAPFFJHDOJBIEJMDNAA.MarkH@ActiveState.com> <39EAB33E.35B72EA4@lemburg.com> <20001016060126.X347@lyra.org> <200010161808.NAA32318@cj20424-a.reston1.va.home.com>  
            <00f601c03799$39f2c7b0$3c6340d5@hagrid> 
Message-ID: <200010161851.NAA32597@cj20424-a.reston1.va.home.com>

> guido wrote:
> > What to do in the short run?  I'm still for severely simplifing the
> > buffer object (ripping out the unused operations) and deprecating it.
> 
> agreed.
> 
> (does this mean that we're in post-2.0 mode? ;-)

Yes :-)

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



From mal at lemburg.com  Mon Oct 16 20:03:15 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Mon, 16 Oct 2000 20:03:15 +0200
Subject: [Python-Dev] The buffer interface
References: <ECEPKNMJLHAPFFJHDOJBIEJMDNAA.MarkH@ActiveState.com> <39EAB33E.35B72EA4@lemburg.com>  
	            <20001016060126.X347@lyra.org> <200010161808.NAA32318@cj20424-a.reston1.va.home.com>
Message-ID: <39EB42E3.B76F37EB@lemburg.com>

Guido van Rossum wrote:
> ...
> I would have concluded that the buffer object is entirely useless, if
> it weren't for some very light use that is being made of it by the
> Unicode machinery.  I can't quite tell whether that was done just
> because it was convenient, or whether that shows there is a real
> need.

I used the buffer object since I thought that buffer() objects
were to replace strings as container for binary data. The buffer
object wraps a memory buffer into a Python object for the purpose
of decoding it into Unicode. 8-bit string objects would have worked
just as well...
 
> What Now?
> ---------
> 
> I'm not convinced that we need the buffer object at all.  For example,
> the mmap module defines a sequence object so doesn't seem to need the
> buffer object to help it support slices.

It would be nice to have an object for "copy by reference" rather
than "malloc + copy". This would be useful for strings (e.g. to
access substrings of a large string), Unicode and binary
data. The buffer object almost does this... it would only have
to stick to always returning buffer objects in coercion, slicing
etc. I also think that the name "buffer" is misleading, since it
really means "reference" in the context published by the Python
interface (the C API also has a way of defining new malloc areas
and referencing them through the buffer interface, but that is
not published in Python).

The other missing data type in Python is one for binary data.
Currently, string objects are in common use for this kind of
data. The problems with this are obvious: in some contexts strings
are expected to contain text data in other binary data. When the
two meet there's great confusion. I'd suggest either making
arrays the Python standard type for holding binary data, or
creating a completely new type (this should then be called
something like "buffer").

> Regarding the buffer API, it's clearly useful, although I'm not
> convinced that it needs the multiple segment count option or the char
> vs. binary buffer distinction, given that we're not using this for
> Unicode objects as we originally planned.

True.
 
> I also feel that it would be helpful if there was an explicit way to
> lock and unlock the data, so that a file object can release the global
> interpreter lock while it is doing the I/O.  But that's not a high
> priority (and there are no *actual* problems caused by the lack of
> such an API -- just *theoretical*).

How about adding a generic low-level lock type for these kind
of tasks. The interpreter could be made aware of these types
to allow a much more fine-grained lock mechanism, e.g. to check
for acquired locks of certain objects only.
 
> For Python 3000, I think I'd like to rethink this whole mess.  Perhaps
> byte buffers and character strings should be different beasts, and
> maybe character strings could have Unicode and 8-bit subclasses (and
> maybe other subclasses that explicitly know about their encoding).
> And maybe we'd have a real file base class.  And so on.

Great... but 3000 is a long way ahead :-(
 
> What to do in the short run?  I'm still for severely simplifing the
> buffer object (ripping out the unused operations) and deprecating it.

Since it isn't all that known anyway, how about streamlining
the buffer object implementations of the various protocols and
removing the distinction between "s" and "t" ?!

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From jcollins at endtech.com  Mon Oct 16 22:22:22 2000
From: jcollins at endtech.com (Jeff Collins)
Date: Mon, 16 Oct 2000 13:22:22 -0700 (PDT)
Subject: [Python-Dev] The buffer interface
In-Reply-To: <200010161808.NAA32318@cj20424-a.reston1.va.home.com>
Message-ID: <Pine.LNX.4.21.0010161135470.15198-100000@localhost.localdomain>

All this just when I was getting accustomed to the thought of using buffer
objects in the Palm Python port...

I need buffer objects for many the same reasons as Greg Stein originally
proposed, as you quoted below.  The on the Palm, the datamanager heap
(used for permanent database storage and limited by the physical memory
size) already stores the compiled python module.  Directly referencing the
data of objects like bytecodes and strings would greatly reduce the
dynamic heap (current limit of 256K on PalmOS 3.5 on devices with 4M RAM
or greater) requirements.

Buffer objects seem like a natural choice.  A record in a Palm database is
just chunk of contiguous memory.  Representing this chunk as a buffer
object would allow the direct referencing it and any of it's slices.  So,
the co_code of code objects could be unmarshalled with a reference to
permanent storage.  Further, with the appropriate modifications, string
objects (char *ob_sval?) could access this memory as well, though this
additional optimization is probably only appropriate for small platforms.

I think that buffer object is fairly important.  They provide a mechanism
for exposing arbitrary chunks of memory (eg, PyBuffer_FromMemory),
something that no other python object does, AFIAK.  Perhaps clarifying the
interface (such as the slice operator returning a buffer, as suggested
below) and providing more hooks from Python for creating buffers (via
newmodule, say) would be helpful.



On Mon, 16 Oct 2000, Guido van Rossum wrote:

> The buffer interface is one of the most misunderstood parts of
> Python.  I believe that if it were PEPped today, it would have a hard
> time getting accepted in its current form.
> 
> There are also two different parts that are commonly referred by this
> name: the "buffer API", which is a C-only API, and the "buffer
> object", which has both a C API and a Python API.
> 
> Both were largely proposed, implemented and extended by others, and I
> have to admit that I'm still uneasy with defending them, especially
> the buffer object.  Both are extremely implementation-dependent (in
> JPython, neither makes much sense).
> 
> The Buffer API
> --------------
> 
> The C-only buffer API was originally intended to allow efficient
> binary I/O from and (in some cases) to large objects that have a
> relatively well-understood underlying memory representation.  Examples
> of such objects include strings, array module arrays, memory-mapped
> files, NumPy arrays, and PIL objects.
> 
> It was created with the desire to avoid an expensive memory-copy
> operation when reading or writing large arrays.  For example, if you
> have an array object containing several millions of double precision
> floating point numbers, and you want to dump it to a file, you might
> prefer to do the I/O directly from the array's memory buffer rather
> than first copying it to a string.  (You lose portability of the data,
> but that's often not a problem the user cares about in these cases.)
> 
> An alternative solution for this particular problem was consdered:
> object types in need of this kind of efficient I/O could define their
> own I/O methods, thereby allowing them to hide their internal
> representation.  This was implemented in some cases (e.g. the array
> module has read() and write() methods) but rejected, because a
> simple-minded implementation of this approach would not work with
> "file-like" objects (e.g. StringIO files).  It was deemed important
> that file-like objects would not place restrictions on the kind of
> objects that could interact with them (compared to real file objects).
> 
> A possible solution would have been to require that each object
> implementing its own read and write methods should support both
> efficient I/O to/from "real" file objects and fall-back I/O to/from
> "file-like" objects.  The fall-back I/O would have to convert the
> object's data to a string object which would then be passed to the
> write() method of the file-like object.  This approach was rejected
> because it would make it impossible to implement an alternative file
> object that would be as efficient as the real file object, since large
> object I/O would be using the inefficient fallback interface.
> 
> To address these issues, we decided to define an interface that would
> let I/O operations ask the objects where their data bytes are in
> memory, so that the I/O can go directly to/from the memory allocated
> by the object.  This is the classic buffer API.  It has a read-only
> and a writable variant -- the writable variant is for mutable objects
> that will allow I/O directly into them.  Because we expected that some
> objects might have an internal representation distributed over a
> (small) number of separately allocated pieces of memory, we also added
> the getsegcount() API.  All objects that I know support the buffer API
> return a segment count of 1, and most places that use the buffer API
> give up if the segment count is larger; so this may be considered as
> an unnecessary generalization (and source of complexity).
> 
> The buffer API has found significant use in a way that wasn't
> originally intended: as a sort of informal common base class for
> string-like objects in situations where a char[] or char* type must be
> passed (in a read-only fashion) to C code.  This is in fact the most
> common use of the buffer API now, and appears to be the reason why the
> segment count must typically be 1.
> 
> In connection with this, the buffer API has grown a distinction
> between character and binary buffers (on the read-only end only).
> This may have been a mistake; it was intended to help with Unicode but
> it ended up not being used.
> 
> The Buffer Object
> -----------------
> 
> The buffer object has a much less clear reason for its existence.
> When Greg Stein first proposed it, he wrote:
> 
>     The intent of this type is to expose a string-like interface from
>     an object that supports the buffer interface (without making a
>     copy). In addition, it is intended to support slices of the target
>     object.
> 
>     My eventual goal here is to tweak the file object to support
>     memory mapping and the buffer interface. The buffer object can
>     then return slices of the file without making a new copy. Next
>     step: change marshal.c, ceval.c, and compile.c to support a buffer
>     for the co_code attribute. Net result is that copies of code
>     streams don't need to be copied onto the heap, but can be left in
>     an mmap'd file or a frozen file. I'm hoping there will be some
>     perf gains (time and memory).
> 
>     Even without some of the co_code work, enabling mmap'd files and
>     buffers onto them should be very useful. I can probably rattle off
>     a good number of other uses for the buffer type.
> 
> I don't think that any of these benefits have been realized yet, and
> altogether I think that the buffer object causes a lot of confusion.
> The buffer *API* doesn't guarantee enough about the lifetime of the
> pointers for the buffer *object* to be able to safely preserve those
> pointers, even if the buffer object holds on to the base object.  (The
> C-level buffer API informally guarantees that the data remains valid
> only until you do anything to the base object; this is usually fine as
> long as you don't release the global interpreter lock.)
> 
> The buffer object's approach to implementing the various sequence
> operations is strange: sometimes it behaves like a string, sometimes
> it doesn't.  E.g. a slice returns a new string object unless it
> happens to address the whole buffer, in which case it returns a
> reference to the existing buffer object.  It would seem more logical
> that a subslice would return a new buffer object.  Concatenation and
> repetition of buffer objects are likewise implemented inconsistently;
> it would have been more consistent with the intended purpose if these
> weren't supported at all (i.e. if none of the buffer object operations
> would allocate new memory except for buffer object headers).
> 
> I would have concluded that the buffer object is entirely useless, if
> it weren't for some very light use that is being made of it by the
> Unicode machinery.  I can't quite tell whether that was done just
> because it was convenient, or whether that shows there is a real
> need.
> 
> What Now?
> ---------
> 
> I'm not convinced that we need the buffer object at all.  For example,
> the mmap module defines a sequence object so doesn't seem to need the
> buffer object to help it support slices.
> 
> Regarding the buffer API, it's clearly useful, although I'm not
> convinced that it needs the multiple segment count option or the char
> vs. binary buffer distinction, given that we're not using this for
> Unicode objects as we originally planned.
> 
> I also feel that it would be helpful if there was an explicit way to
> lock and unlock the data, so that a file object can release the global
> interpreter lock while it is doing the I/O.  But that's not a high
> priority (and there are no *actual* problems caused by the lack of
> such an API -- just *theoretical*).
> 
> For Python 3000, I think I'd like to rethink this whole mess.  Perhaps
> byte buffers and character strings should be different beasts, and
> maybe character strings could have Unicode and 8-bit subclasses (and
> maybe other subclasses that explicitly know about their encoding).
> And maybe we'd have a real file base class.  And so on.
> 
> What to do in the short run?  I'm still for severely simplifing the
> buffer object (ripping out the unused operations) and deprecating it.
> 
> --Guido van Rossum (home page: http://www.python.org/~guido/)
> 
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://www.python.org/mailman/listinfo/python-dev
> 

-- 
Jeffery D. Collins  
Sr. Software Developer
Endeavors Technology, Inc.





From akuchlin at cnri.reston.va.us  Mon Oct 16 21:35:13 2000
From: akuchlin at cnri.reston.va.us (Andrew M. Kuchling)
Date: Mon, 16 Oct 2000 15:35:13 -0400
Subject: [Python-Dev] Post-2.0 strategy
In-Reply-To: <200010161851.NAA32597@cj20424-a.reston1.va.home.com>; from guido@python.org on Mon, Oct 16, 2000 at 01:51:51PM -0500
References: <ECEPKNMJLHAPFFJHDOJBIEJMDNAA.MarkH@ActiveState.com> <39EAB33E.35B72EA4@lemburg.com> <20001016060126.X347@lyra.org> <200010161808.NAA32318@cj20424-a.reston1.va.home.com> <00f601c03799$39f2c7b0$3c6340d5@hagrid> <200010161851.NAA32597@cj20424-a.reston1.va.home.com>
Message-ID: <20001016153513.A14693@amarok.cnri.reston.va.us>

On Mon, Oct 16, 2000 at 01:51:51PM -0500, Guido van Rossum wrote:
>> (does this mean that we're in post-2.0 mode? ;-)
>Yes :-)

Then this is a good time to ask what strategy will be followed
post-2.0.  Do you want a moratorium on massive checkins for a time
while 2.0 shakes out, re-opening the tree for larger changes in a few
months?  Or will you try to live with a CVS branch for 2.0 and re-open
the tree immediately?

--amk




From fdrake at beopen.com  Mon Oct 16 21:37:30 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Mon, 16 Oct 2000 15:37:30 -0400 (EDT)
Subject: [Python-Dev] Post-2.0 strategy
In-Reply-To: <20001016153513.A14693@amarok.cnri.reston.va.us>
References: <ECEPKNMJLHAPFFJHDOJBIEJMDNAA.MarkH@ActiveState.com>
	<39EAB33E.35B72EA4@lemburg.com>
	<20001016060126.X347@lyra.org>
	<200010161808.NAA32318@cj20424-a.reston1.va.home.com>
	<00f601c03799$39f2c7b0$3c6340d5@hagrid>
	<200010161851.NAA32597@cj20424-a.reston1.va.home.com>
	<20001016153513.A14693@amarok.cnri.reston.va.us>
Message-ID: <14827.22778.902987.343492@cj42289-a.reston1.va.home.com>

Andrew M. Kuchling writes:
 > Then this is a good time to ask what strategy will be followed
 > post-2.0.  Do you want a moratorium on massive checkins for a time
 > while 2.0 shakes out, re-opening the tree for larger changes in a few
 > months?  Or will you try to live with a CVS branch for 2.0 and re-open
 > the tree immediately?

  I think a maintenance branch for 2.0.1 (or whatever) should be
created as part of the release process in case we need a quick release
for critical bug fixes.
  The tree should be re-opened after the release via a message to
python-dev after the release is published.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From guido at python.org  Mon Oct 16 22:46:22 2000
From: guido at python.org (Guido van Rossum)
Date: Mon, 16 Oct 2000 15:46:22 -0500
Subject: [Python-Dev] Post-2.0 strategy
In-Reply-To: Your message of "Mon, 16 Oct 2000 15:35:13 -0400."
             <20001016153513.A14693@amarok.cnri.reston.va.us> 
References: <ECEPKNMJLHAPFFJHDOJBIEJMDNAA.MarkH@ActiveState.com> <39EAB33E.35B72EA4@lemburg.com> <20001016060126.X347@lyra.org> <200010161808.NAA32318@cj20424-a.reston1.va.home.com> <00f601c03799$39f2c7b0$3c6340d5@hagrid> <200010161851.NAA32597@cj20424-a.reston1.va.home.com>  
            <20001016153513.A14693@amarok.cnri.reston.va.us> 
Message-ID: <200010162046.PAA05288@cj20424-a.reston1.va.home.com>

> Then this is a good time to ask what strategy will be followed
> post-2.0.  Do you want a moratorium on massive checkins for a time
> while 2.0 shakes out, re-opening the tree for larger changes in a few
> months?  Or will you try to live with a CVS branch for 2.0 and re-open
> the tree immediately?

If we need to issue a patch release, we'll use a branch.  That seems
the only reasonable approach.

The tree will be open for checkins as soon as 2.0 is released (tonight
is looking good!), but I hope the people exercise some restraint and
discuss their plans for significant checkins on the python-dev list
first.

A lot of things should probably be discussed in the form of PEPs too!

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



From tim_one at email.msn.com  Mon Oct 16 21:47:05 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Mon, 16 Oct 2000 15:47:05 -0400
Subject: [Python-Dev] Post-2.0 strategy
In-Reply-To: <20001016153513.A14693@amarok.cnri.reston.va.us>
Message-ID: <LNBBLJKPBEHFEDALKOLCCEICHLAA.tim_one@email.msn.com>

[Andrew M. Kuchling]
> Then this is a good time to ask what strategy will be followed
> post-2.0.  Do you want a moratorium on massive checkins for a time
> while 2.0 shakes out ...

It's not a great time to ask, as we're still balls-to-the-wall *building*
the release and doing last-second checkins (things like NEWS, not code).  So
there's an absolute ban on any checkins until further notice (on
Python-Dev), excepting for those explicitly approved by Jeremy.

After that, I agree with Fred that we should make a 2.0.1 branch
simultaneous with the release.





From jeremy at beopen.com  Tue Oct 17 00:11:49 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Mon, 16 Oct 2000 18:11:49 -0400 (EDT)
Subject: [Python-Dev] Python 2.1 Release Schedule (tentative)
Message-ID: <14827.32037.652156.120714@bitdiddle.concentric.net>

FYI: In anticpation of the Python 2.0 final release this evening, we
just created a new PEP describing the release schedule for Python 2.1.

Jeremy


PEP: 226
Title: Python 2.1 Release Schedule
Version: $Revision: 1.1 $
Author: Jeremy Hylton <jeremy at beopen.com>
Status: Incomplete
Type: Informational
Created: 16-Oct-2000
Python-Version: 2.1
Post-History:

Abstract

    This document describes the post Python 2.0 development and
    release schedule.  According to this schedule, Python 2.1 will be
    released in mid-March of 2001.  The schedule primarily concerns
    itself with PEP-size items.  Small bug fixes and changes will
    occur up until the first beta release.


Tentative Release Schedule

    16-Oct-2000: Python 2.0 final release
 
    These dates represent goals, not commitments.

    16-Dec-2000: 2.1 PEPs ready for review
    01-Feb-2001: First 2.1 beta release
    16-Mar-2001: 2.1 final release


Guidelines for making changes for Python 2.1

    The guidelines and schedule will be revised based on discussion in
    the python-dev at python.org mailing list.

    The PEP system was instituted late in the Python 2.0 development
    cycle and many changes did not follow the process described in PEP
    1.  The development process for 2.1, however, will follow the PEP
    process as documented.

    The first eight weeks following 2.0 final will be the design and
    review phase.  By the end of this period, any PEP that is proposed
    for 2.1 should be ready for review.  This means that the PEP is
    written and discussion has occurred on the python-dev at python.org
    and python-list at python.org mailing lists.

    The next six weeks will be spent reviewing the PEPs and
    implementing and testing the accepted PEPs.  When this period
    stops, we will end consideration of any incomplete PEPs.  Near the
    end of this period, there will be a feature freeze where any small
    features not worthy of a PEP will not be accepted.

    Before the final release, we will have six weeks of beta testing
    and a release candidate or two.


Bug fix releases before 2.1

    We may have to issue Python 2.0.1 for critical bug fixes.  If we
    need to issue a bug fix release, we will use a CVS branch. 


General guidelines for submitting patches and making changes

    Use good sense when committing changes.  You should know what we
    mean by good sense or we wouldn't have given you commit privileges
    <0.5 wink>.  Some specific examples of good sense include:

    - Do whatever the dictator tells you.

    - Discuss any controversial changes on python-dev first.  If you
      get a lot of +1 votes and no -1 votes, make the change.  If you
      get a some -1 votes, think twice; consider asking Guido what he
      thinks.

    - If the change is to code you contributed, it probably makes
      sense for you to fix it.

    - If the change affects code someone else wrote, it probably makes
      sense to ask him or her first.

    - You can use the SourceForge (SF) Patch Manager to submit a patch
      and assign it to someone for review.

    Any significant new feature must be described in a PEP and
    approved before it is checked in.

    Any significant code addition, such as a new module or large
    patch, must include test cases for the regression test and
    documentation.  A patch should not be checked in until the tests
    and documentation are ready.

    If you fix a bug, you should write a test case that would have
    caught the bug.

    If you commit a patch from the SF Patch Manager or fix a bug from
    the Jitterbug database, be sure to reference the patch/bug number
    in the CVS log message.  Also be sure to change the status in the
    patch manager or bug database (if you have access to the bug
    database).

    It is not acceptable for any checked in code to cause the
    regression test to fail.  If a checkin causes a failure, it must
    be fixed within 24 hours or it will be backed out.

    All contributed C code must be ANSI C.  If possible check it with
    two different compilers, e.g. gcc and MSVC.

    All contributed Python code must follow Guido's Python style
    guide.  http://www.python.org/doc/essays/styleguide.html

    It is understood that any code contributed will be released under
    an Open Source license.  Do not contribute code if it can't be
    released this way.



From greg at cosc.canterbury.ac.nz  Tue Oct 17 01:09:55 2000
From: greg at cosc.canterbury.ac.nz (Greg Ewing)
Date: Tue, 17 Oct 2000 12:09:55 +1300 (NZDT)
Subject: [Python-Dev] The buffer interface
In-Reply-To: <200010161808.NAA32318@cj20424-a.reston1.va.home.com>
Message-ID: <200010162309.MAA26975@s454.cosc.canterbury.ac.nz>

Guido:

> The buffer *API* doesn't guarantee enough about the lifetime of the
> pointers for the buffer *object* to be able to safely preserve those
> pointers, even if the buffer object holds on to the base object.

This seems like a fatal flaw to me, which should have
prevented the buffer object in its present form from
ever having been implemented.

I suggest that this problem MUST be fixed, or the
buffer object removed entirely.

Greg Ewing, Computer Science Dept, +--------------------------------------+
University of Canterbury,	   | A citizen of NewZealandCorp, a	  |
Christchurch, New Zealand	   | wholly-owned subsidiary of USA Inc.  |
greg at cosc.canterbury.ac.nz	   +--------------------------------------+



From gstein at lyra.org  Tue Oct 17 03:57:09 2000
From: gstein at lyra.org (Greg Stein)
Date: Mon, 16 Oct 2000 18:57:09 -0700
Subject: [Python-Dev] The buffer interface
In-Reply-To: <Pine.LNX.4.21.0010161135470.15198-100000@localhost.localdomain>; from jcollins@endtech.com on Mon, Oct 16, 2000 at 01:22:22PM -0700
References: <200010161808.NAA32318@cj20424-a.reston1.va.home.com> <Pine.LNX.4.21.0010161135470.15198-100000@localhost.localdomain>
Message-ID: <20001016185709.J25097@lyra.org>

On Mon, Oct 16, 2000 at 01:22:22PM -0700, Jeff Collins wrote:
>...
> I think that buffer object is fairly important.  They provide a mechanism
> for exposing arbitrary chunks of memory (eg, PyBuffer_FromMemory),
> something that no other python object does, AFIAK.  Perhaps clarifying the
> interface (such as the slice operator returning a buffer, as suggested
> below) and providing more hooks from Python for creating buffers (via
> newmodule, say) would be helpful.

There have been quite a few C extensions (and embedding Python!) where the
buffer objects have been used in this fashion. For example, if you have a
string argument that you wish to pass into Python, then you can avoid a copy
by wrapping a Buffer Object around it and passing that.

Many of the issues with the buffer object can be solved with simple changes.
For example, the "mutable object" thing is easily dealt with by having the
object not record the pointer, but just fetch it every time that it wants to
do an operation.
[ and if we extend the buffer API, we could potentially optimize the
  behavior to avoid the ptr refetch on each operation ]

I don't recall the motivation for returning strings. I believe it was based
on an attempt to make the buffer look as much like a string as possible (and
slices and concats return strings). That was a poor choice :-)  ... so,
again, some basic changes to return slices and concats as buffer objects
would make sense.

Extending the buffer() builtin to create writeable buffer objects has been a
reasonably common request. What seems to happen instead is that people
developing C extensions (which desire buffer objects as their params) just
add a new function to the extension to create buffer objects.

Re: the buffer API: At the time the "s"/"t" codes were introduced (before
1.5.2 was released), we had a very different concept of how Unicode objects
would be implemented. At that time, Unicode objects had no 8-bit
representation (just 16-bit chars), so the difference was important. I'm not
clued in enough on the ramifications of torching the difference in the API,
but it would be a nice simplification.

Buffers vs arrays: this is a harder question. Which is the "recommended
binary type [for series of bytes]" ? Buffers can refer to arbitrary memory.
Arrays maintain their own memory. I believe the two models are needed, so
I'd initially offer that both buffers and arrays need to be maintained.
However, given that... what is the purpose of the array if a buffer can
*also* maintain its own memory?

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/



From guido at python.org  Tue Oct 17 05:35:02 2000
From: guido at python.org (Guido van Rossum)
Date: Mon, 16 Oct 2000 22:35:02 -0500
Subject: [Python-Dev] Python 2.0 final release is out!
Message-ID: <200010170335.WAA07253@cj20424-a.reston1.va.home.com>

I am happy to announce that Python 2.0 is released.  I thank my
colleagues at BeOpen PythonLabs and the many volunteers in the Python
developer community for their incredible work on this release over the
past months.  Please pick up the new release at

    http://www.pythonlabs.com/products/python2.0/

There you will find a Windows installer, a source tarball, RedHat
RPMs, downloadable and online documentation, and a long list of new
features and fixed bugs.  Among the new features in Python 2.0 are:

  - Augmented assignment, e.g. x += 1
  - List comprehensions, e.g. [x**2 for x in range(10)]
  - Extended import statement, e.g. import Module as Name
  - Extended print statement, e.g. print >> file, "Hello"
  - Collection of cyclical garbage

For a fuller discussion of the changes in Python 2.0 since Python
1.5.2, please see the article "What's New in Python 2.0" by A.M.
Kuchling and Moshe Zadka:
http://starship.python.net/crew/amk/python/writing/new-python/

All major reported bugs have been fixed in this final release.  We've
gone through an extremely thorough set of beta releases followed by a
release candidate, and therefore we expect that this release will be
stable and virtually problem-free.  If you nevertheless run into a
bug, use the SourceForge bug tracker to report it:
http://sourceforge.net/bugs/?group_id=5470

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



From fdrake at beopen.com  Tue Oct 17 06:53:25 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Tue, 17 Oct 2000 00:53:25 -0400 (EDT)
Subject: [Python-Dev] CVS repository open for business
Message-ID: <14827.56133.84421.68885@cj42289-a.reston1.va.home.com>

  The Python CVS repository is now open for further development.

  If critical patches are needed to the 2.0 release, they should be
developed against the branch tagged "release20-maint", and should be
posted at SourceForge and discussed here on python-dev before checking
them into the branch.
  Thanks to all the Python developers for your hard work and
contributions!


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From mal at lemburg.com  Tue Oct 17 10:16:56 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Tue, 17 Oct 2000 10:16:56 +0200
Subject: [Python-Dev] The buffer interface
References: <200010161808.NAA32318@cj20424-a.reston1.va.home.com> <Pine.LNX.4.21.0010161135470.15198-100000@localhost.localdomain> <20001016185709.J25097@lyra.org>
Message-ID: <39EC0AF8.5FA79E97@lemburg.com>

Greg Stein wrote:
> 
> On Mon, Oct 16, 2000 at 01:22:22PM -0700, Jeff Collins wrote:
> >...
> > I think that buffer object is fairly important.  They provide a mechanism
> > for exposing arbitrary chunks of memory (eg, PyBuffer_FromMemory),
> > something that no other python object does, AFIAK.  Perhaps clarifying the
> > interface (such as the slice operator returning a buffer, as suggested
> > below) and providing more hooks from Python for creating buffers (via
> > newmodule, say) would be helpful.
> 
> There have been quite a few C extensions (and embedding Python!) where the
> buffer objects have been used in this fashion. For example, if you have a
> string argument that you wish to pass into Python, then you can avoid a copy
> by wrapping a Buffer Object around it and passing that.

Perhaps we ought to flesh out the current uses of buffer objects and
then decide how to proceed ?!

IMHO, the problem with buffer objects (apart from the sometimes strange
protocol behaviour) is that there too many "features" built into
it. Simplification and possibly diversification is needed: instead
of trying to achieve every possible C hack with buffer objects
we should try to come up with a reasonably small set of types
which allow only very basic tasks, e.g. 

1. wrapping C memory areas with the possibility of accessing the
   raw bytes in a read-only way (this should be buffer()),

2. providing a non-copying object reference type (I'd call this
   reference()) and

3. maintaining a writeable C memory buffer (arrays provide this feature).

The buffer object currently tries to do all three.

> Many of the issues with the buffer object can be solved with simple changes.
> For example, the "mutable object" thing is easily dealt with by having the
> object not record the pointer, but just fetch it every time that it wants to
> do an operation.
> [ and if we extend the buffer API, we could potentially optimize the
>   behavior to avoid the ptr refetch on each operation ]

Please don't extend the buffer API: the whole design is flawed
since it undermines data encapsulation in very dangerous ways.

If at all, we should consider a new API at abstract API level
which doesn't return raw C pointers, but real Python objects
(e.g. type 2 reference objects).
 
> I don't recall the motivation for returning strings. I believe it was based
> on an attempt to make the buffer look as much like a string as possible (and
> slices and concats return strings). That was a poor choice :-)  ... so,
> again, some basic changes to return slices and concats as buffer objects
> would make sense.

+1.
 
> Extending the buffer() builtin to create writeable buffer objects has been a
> reasonably common request. What seems to happen instead is that people
> developing C extensions (which desire buffer objects as their params) just
> add a new function to the extension to create buffer objects.

Please don't. Instead either suggest to use arrays or come up
with some new type with the sole purpose of providing read-write
access to a chunk of bytes.
 
> Re: the buffer API: At the time the "s"/"t" codes were introduced (before
> 1.5.2 was released), we had a very different concept of how Unicode objects
> would be implemented. At that time, Unicode objects had no 8-bit
> representation (just 16-bit chars), so the difference was important. I'm not
> clued in enough on the ramifications of torching the difference in the API,
> but it would be a nice simplification.

Well, think of it this way: Unicode was the first object to actually
try to make a difference between "s" and "t" -- and failed badly.
In the end, we reverted the decision to make any difference and
now special case Unicode objects in the getargs.c parser (so that
"s" and "t" work virtually the same for Unicode).

+1 on the idea of removing the difference altogether in 2.1.

If anyone needs to a special representation of an object, the object
should provide a clearly defined C API for this instead. E.g.
Unicode has lots of APIs to encode Unicode into quite a few
new repesentations.

> Buffers vs arrays: this is a harder question. Which is the "recommended
> binary type [for series of bytes]" ? Buffers can refer to arbitrary memory.
> Arrays maintain their own memory. I believe the two models are needed, so
> I'd initially offer that both buffers and arrays need to be maintained.
> However, given that... what is the purpose of the array if a buffer can
> *also* maintain its own memory?

Right and that's the problem: buffers shouldn't be able to
own memory. See above.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From barry at scottb.demon.co.uk  Tue Oct 17 10:40:52 2000
From: barry at scottb.demon.co.uk (Barry Scott)
Date: Tue, 17 Oct 2000 09:40:52 +0100
Subject: [Python-Dev] build problems large and small on FreeBSD
In-Reply-To: <14823.38174.143372.125749@bitdiddle.concentric.net>
Message-ID: <001201c03815$f54c4960$060210ac@private>

The FreeBSD ports collection had to be updated to support
importing C++ extensions with Python 1.5.2. (You get things
like cout not defined when importing).

Are the nessesary compile/link changes in 2.0?

		BArry




From gstein at lyra.org  Tue Oct 17 12:48:27 2000
From: gstein at lyra.org (Greg Stein)
Date: Tue, 17 Oct 2000 03:48:27 -0700
Subject: [Python-Dev] Re: [XML-SIG] PyXML home page on SF
In-Reply-To: <Pine.LNX.4.21.0010171130030.9897-100000@aries>; from Nicolas.Chauvat@logilab.fr on Tue, Oct 17, 2000 at 12:18:41PM +0200
References: <200010162335.BAA01015@loewis.home.cs.tu-berlin.de> <Pine.LNX.4.21.0010171130030.9897-100000@aries>
Message-ID: <20001017034827.F26804@lyra.org>

[ moving from xml-sig to python-dev ]

Reality check time...

On Tue, Oct 17, 2000 at 12:18:41PM +0200, Nicolas Chauvat wrote:
> [maintaining a pythonforge.org would take time and ressources]
> 
> Yes. But I understand a commercial company (BeOpen) has taken over python
> development. I think it is the kind of free services they could give
> back to the python community.

If VA Linux is already offering the service, then how does the community
benefit from BeOpen offering the same thing?

More importantly: how is BeOpen going to benefit from it? How do they get a
business return on that investment? That *will* come into play, you know.
Somebody has to pay for those sysadmins and hardware and connectivity.

> > > That would be pyxml.pythonforge.org, distutils.pythonforge.org, etc. :-)
> > 
> > I'd personally hope that python.org becomes accessible in that
> > way. You could probably have all of the current content there, and
> > then also have python.org/projects/pyxml; python.org/users/someone;
> > xml.python.org (and whatever other gimmicks they offer).

The last I heard, the intent was to move python.org from CNRI to a machine
at VA Linux. The content would then become available for the community to
work on; possibly through SourceForge facilities.

> > One advantage of taking things off SF is that responsiveness of that
> > system was really bad. That seems to have improved recently;
> 
> My concern is not about responsiveness as much as distribution (as in
> Internet is a distributed system). SourceForge is a great service. Good.
> Now are we to host every single open source project on SourceForge ? If we
> do so, the day SourceForge closes or changes its policy, or whatever,
> every single open source project will be halted or maybe discontinued.

There is no way that SF is ever going to close and take all of those
projects with it. VA Linux would be see their business instantly vaporized.
As ESR is fond to point out: VA Linux has built their business on trust from
the community. *ANY* failure to meet that trust will kill their biz.

> The people at SourceForge know their job: they provide a good service and
> the tools (code+doc) to implement that same service at other places.
> 
> Why wouldn't a community as big an active as python's put up ressources in
> common to offer such a useful service, but dedicated to python
> development ? There use to be a python.starship.net, maintained by
> volunteers, that is now hosted by BeOpen. Why not take the next step ?

python.starship.net has historically been a disaster area. Poorly maintained
or (even worse) maintained by a whole bunch of people. Have you ever seen
what happens when you give 20 people root access?

Then there was the time that a drive crashed. The machine was *gone* for
months.

Oh, and the network connectivity loss. A month offline, maybe?

The community is way to busy to run a service. Sorry.

That is why I like SF so much. They are ready and willing to run a service
and to fund that operation. And to all appearances, they are running it very
well (and continually upgrading it!).

> > if anybody is to host a similar server, they need to be aware that it
> > is probably hard to compete with SF in terms of provided services. For
> > example, I trust that SF has a reasonable backup strategy - they

They do. It is somewhere on their site. They have a complete backup
strategy. In fact, a while back, they lost a drive and restored most of it
from backup. I forget if there was any actual material lost.

> > simply can't risk a desaster. Anybody hosting a server for just a few
> > projects would not get the same sort of trust from me.
> 
> That's why I think we shouldn't look for someone able to host a server for
> a few projects but for some company(ies) able to put up the ressources for
> "python projects" and volunteers that help them.

Idealistic, but it won't happen. starship.net is my case in point.

> That would also make it easier for people to look for python ressources:
> code in development would be at something.python.org and 3rd party
> software at www.vex.net/parnassus. But I would agree that's a weak
> argument as long as www.python.org continues to be well-maintained with
> no broken links and stays the central hub for python information.

When python.org moves, then it will be maintained much better. I don't
recall the status of that, but I presume that Guido is still pushing to see
it happen.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/



From guido at python.org  Tue Oct 17 05:35:02 2000
From: guido at python.org (Guido van Rossum)
Date: Mon, 16 Oct 2000 22:35:02 -0500
Subject: [Python-Dev] Python 2.0 final release is out!
Message-ID: <mailman.971750281.20361.clpa-moderators@python.org>

I am happy to announce that Python 2.0 is released.  I thank my
colleagues at BeOpen PythonLabs and the many volunteers in the Python
developer community for their incredible work on this release over the
past months.  Please pick up the new release at

    http://www.pythonlabs.com/products/python2.0/

There you will find a Windows installer, a source tarball, RedHat
RPMs, downloadable and online documentation, and a long list of new
features and fixed bugs.  Among the new features in Python 2.0 are:

  - Augmented assignment, e.g. x += 1
  - List comprehensions, e.g. [x**2 for x in range(10)]
  - Extended import statement, e.g. import Module as Name
  - Extended print statement, e.g. print >> file, "Hello"
  - Collection of cyclical garbage

For a fuller discussion of the changes in Python 2.0 since Python
1.5.2, please see the article "What's New in Python 2.0" by A.M.
Kuchling and Moshe Zadka:
http://starship.python.net/crew/amk/python/writing/new-python/

All major reported bugs have been fixed in this final release.  We've
gone through an extremely thorough set of beta releases followed by a
release candidate, and therefore we expect that this release will be
stable and virtually problem-free.  If you nevertheless run into a
bug, use the SourceForge bug tracker to report it:
http://sourceforge.net/bugs/?group_id=5470

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




From guido at python.org  Tue Oct 17 16:06:00 2000
From: guido at python.org (Guido van Rossum)
Date: Tue, 17 Oct 2000 09:06:00 -0500
Subject: [Python-Dev] build problems large and small on FreeBSD
In-Reply-To: Your message of "Tue, 17 Oct 2000 09:40:52 +0100."
             <001201c03815$f54c4960$060210ac@private> 
References: <001201c03815$f54c4960$060210ac@private> 
Message-ID: <200010171406.JAA09272@cj20424-a.reston1.va.home.com>

> The FreeBSD ports collection had to be updated to support
> importing C++ extensions with Python 1.5.2. (You get things
> like cout not defined when importing).
> 
> Are the nessesary compile/link changes in 2.0?

Tell you what: I have no idea. :-(

I believe there were some changes to the Makefile and/or config file
to support C++, but I don't know if this works on FreeBSD.  I'm not a
big C++ user myself, so I rarely try this...

Can you try it?  If it doesn't work out of the box, let's sit down
together and figure out a fix.

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




From fdrake at beopen.com  Tue Oct 17 15:59:46 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Tue, 17 Oct 2000 09:59:46 -0400 (EDT)
Subject: [Python-Dev] Re: [XML-SIG] PyXML home page on SF
In-Reply-To: <Pine.LNX.4.21.0010171130030.9897-100000@aries>
References: <200010162335.BAA01015@loewis.home.cs.tu-berlin.de>
	<Pine.LNX.4.21.0010171130030.9897-100000@aries>
Message-ID: <14828.23378.795196.804989@cj42289-a.reston1.va.home.com>

[Moved to python-dev, since the shift has begun.]

Nicolas Chauvat writes:
 > I'm sure several people from PythonLabs are on this list. What is their
 > opinion ?

  I rather like letting the SourceForge crew take care of running the
service.  Running a website that needs constant updates is no trivial
matter, and SourceForge is *much* more complex than that!
  I have a great deal of respect for the hard work that I know goes
into running SourceForge, and would rather see that effort bolstered
by volunteers & contributions (docs, code, whatever) by people who are
able, than to see the efforts splintered.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From Nicolas.Chauvat at logilab.fr  Tue Oct 17 16:07:36 2000
From: Nicolas.Chauvat at logilab.fr (Nicolas Chauvat)
Date: Tue, 17 Oct 2000 16:07:36 +0200 (CEST)
Subject: [Python-Dev] Re: [XML-SIG] PyXML home page on SF
In-Reply-To: <14828.23378.795196.804989@cj42289-a.reston1.va.home.com>
Message-ID: <Pine.LNX.4.21.0010171600440.10465-100000@aries>

>   I have a great deal of respect for the hard work that I know goes
> into running SourceForge, and would rather see that effort bolstered
> by volunteers & contributions (docs, code, whatever) by people who are
> able, than to see the efforts splintered.

Hum, maybe I did not explain myself correctly and I don't want a
misunderstanding: I never meant "let's create a SourceForge-like tool,
SourceForge is bad", but only "why not host a python specific service
using the SourceForge code and tools", as www.bioinformatics.org does for
projects related to bio-ingeneering.

-- 
Nicolas Chauvat

http://www.logilab.com - "Mais o? est donc Ornicar ?" - LOGILAB, Paris (France)




From guido at python.org  Tue Oct 17 17:26:31 2000
From: guido at python.org (Guido van Rossum)
Date: Tue, 17 Oct 2000 10:26:31 -0500
Subject: [Python-Dev] Re: [XML-SIG] PyXML home page on SF
In-Reply-To: Your message of "Tue, 17 Oct 2000 16:07:36 +0200."
             <Pine.LNX.4.21.0010171600440.10465-100000@aries> 
References: <Pine.LNX.4.21.0010171600440.10465-100000@aries> 
Message-ID: <200010171526.KAA09461@cj20424-a.reston1.va.home.com>

> Hum, maybe I did not explain myself correctly and I don't want a
> misunderstanding: I never meant "let's create a SourceForge-like tool,
> SourceForge is bad", but only "why not host a python specific service
> using the SourceForge code and tools", as www.bioinformatics.org does for
> projects related to bio-ingeneering.

Why not indeed?  Why spend time running a service that SourceForge is
already providing, and very well at that?  This has come up
occasionally at BeOpen but the only argument for it that was ever
brought up (by the marketing folks, of course :-) was the hope that it
would help sell banner ads -- not that there would be an advantage for
the community.

What would be the advantage for the community or running our own?
What's wrong with using SourceForge?  I say, if it ain't broke don't
fix it.  (And then again, there may be a very good reason to run our
own, and maybe I just don't see it. :-)

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




From thomas at xs4all.net  Tue Oct 17 17:11:11 2000
From: thomas at xs4all.net (Thomas Wouters)
Date: Tue, 17 Oct 2000 17:11:11 +0200
Subject: [Python-Dev] Re: [XML-SIG] PyXML home page on SF
In-Reply-To: <200010171526.KAA09461@cj20424-a.reston1.va.home.com>; from guido@python.org on Tue, Oct 17, 2000 at 10:26:31AM -0500
References: <Pine.LNX.4.21.0010171600440.10465-100000@aries> <200010171526.KAA09461@cj20424-a.reston1.va.home.com>
Message-ID: <20001017171111.K12812@xs4all.nl>

On Tue, Oct 17, 2000 at 10:26:31AM -0500, Guido van Rossum wrote:

> > Hum, maybe I did not explain myself correctly and I don't want a
> > misunderstanding: I never meant "let's create a SourceForge-like tool,
> > SourceForge is bad", but only "why not host a python specific service
> > using the SourceForge code and tools", as www.bioinformatics.org does for
> > projects related to bio-ingeneering.

> What would be the advantage for the community or running our own?
> What's wrong with using SourceForge?  I say, if it ain't broke don't
> fix it.  (And then again, there may be a very good reason to run our
> own, and maybe I just don't see it. :-)

There is no advantage that I know of. I know a lot about keeping machines
and websites up and running (that's what I do for a living(*), after all)
and I can tell you you need a big (or very dedicated) sysadmin staff to be
able to offer anything as reliable as SourceForge.

So the website & CVS tree itself could be run on a low-end machine. Say a
PII-300 with 128 MB RAM. You need at least two, preferably three machines,
regardless of performance, to be able to offer 'reliable' services.
Preferably load-balanced by something like a smart switch (we use Alteon
Layer-4 ethernet switches for that task, and you can do cool things with
them. They're also pretty expensive.) And you need a way to back it up. A
tape library or DAT streamer of some kind. Preferably a separate machine to
do the actual backups. Live or fast-cycled backups can also be a lifesaver,
which either requires another machine or two with speedy disks, or storing
your data on something dedicated like a NetApp Filer. (Very cool machine, a
dedicated NFS and CIFS (SMB) fileserver with excellent live backups,
'snapshots', as many as you want/need. Only costs you diskspace. Oh, and
this quality comes at a price, too, of course.)

And then there's the reliable network access, reliable system room (with
reliable and preferably redundant power), and the 24/7 warning system that
wakes up stand-by sysadmins to fix problems.

And for the specialized hardware and software, you need a few people who
know how to handle them. You need several people anyway, to cover all bases
even in the face of illness, vacations and the famous bus accidents. We have
a crew of 12 now, with a few new additions, and even then we run into
trouble with vacations. I dare say we offer more reliable services than
SourceForge does, but we also cost more :-)

In short, the only advantage to not using SourceForge is that you can do
things SourceForge can't or won't. Run software SourceForge won't, for
instance. However, I would strongly suggest making such software
'non-essential', keeping most of the stuff on SourceForge, spend lots less
money on the technical setup, and suffer a bit when the service is down.

*) Where living is defined as 'making enough money to stay breathing and
work on Python', and 'work on Python' has higher importance, of course :-)

-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!



From akuchlin at mems-exchange.org  Tue Oct 17 18:47:34 2000
From: akuchlin at mems-exchange.org (Andrew Kuchling)
Date: Tue, 17 Oct 2000 12:47:34 -0400
Subject: [Python-Dev] Publicity for 2.0 release?
Message-ID: <E13lZtm-0001b4-00@kronos.cnri.reston.va.us>

Is BeOpen doing any publicity for the release of 2.0?  For example,
issuing a press release and sending it to lots of different
publications, such as DDJ, Web Development, Windows programming magazines,
whatever that XML magazine is called, etc.?

(Hmm... www.beopen.com hasn't been updated to mention the new release
-- nor even 2.0c1.)

--amk



From pf at artcom-gmbh.de  Tue Oct 17 19:21:19 2000
From: pf at artcom-gmbh.de (Peter Funk)
Date: Tue, 17 Oct 2000 19:21:19 +0200 (MEST)
Subject: [Python-Dev] Publicity for 2.0 release?
In-Reply-To: <E13lZtm-0001b4-00@kronos.cnri.reston.va.us> from Andrew Kuchling at "Oct 17, 2000 12:47:34 pm"
Message-ID: <m13laQR-000Dm8C@artcom0.artcom-gmbh.de>

Andrew Kuchling:
> Is BeOpen doing any publicity for the release of 2.0?  For example,
> issuing a press release and sending it to lots of different
> publications, such as DDJ, Web Development, Windows programming magazines,
> whatever that XML magazine is called, etc.?
> 
> (Hmm... www.beopen.com hasn't been updated to mention the new release
> -- nor even 2.0c1.)

Really bad marketing! ;-)  But not as bad as it could have been:
Other places hopping into my mind were:
	http://slashdot.org/  (already done, see below)
	http://freshmeat.net/ (already done by Andrew Kuchling, 3249 hits)
	http://www.newsforge.com/ (didn't see Python mentioned there yet)
and not to forget 
	http://www.python.org/ (already done)

quoting from slashdot:
     """Python 2.0 Released

        Posted by timothy on 5:34 Tuesday 17 October 2000
        from the Perl-6-times-infinity-nyeahnyeah-nyeahnyeah dept.
        atallah writes: "It would appear that the long awaited Python 2.0 was
        finally released today. The front page of the Web site has the
        announcement." According to that announcement, Python 2.0 will receive
        minor-version updates around every 6 months, even as work begins on the
        shoot-for-the-moon Python 3000. For the curious, here's the list of what's new in 2.0; the list
        includes "full XML support and several forms of new syntax," as well as the BeOpen label. 

        ( Read More... | 164 comments )
     """

Regards, Peter
-- 
Peter Funk, Oldenburger Str.86, D-27777 Ganderkesee, Germany, Fax:+49 4222950260
office: +49 421 20419-0 (ArtCom GmbH, Grazer Str.8, D-28359 Bremen)



From akuchlin at mems-exchange.org  Tue Oct 17 19:33:22 2000
From: akuchlin at mems-exchange.org (Andrew Kuchling)
Date: Tue, 17 Oct 2000 13:33:22 -0400
Subject: [Python-Dev] Publicity for 2.0 release?
In-Reply-To: <m13laQR-000Dm8C@artcom0.artcom-gmbh.de>; from pf@artcom-gmbh.de on Tue, Oct 17, 2000 at 07:21:19PM +0200
References: <E13lZtm-0001b4-00@kronos.cnri.reston.va.us> <m13laQR-000Dm8C@artcom0.artcom-gmbh.de>
Message-ID: <20001017133322.A6158@kronos.cnri.reston.va.us>

On Tue, Oct 17, 2000 at 07:21:19PM +0200, Peter Funk wrote:
>	http://freshmeat.net/ (already done by Andrew Kuchling, 3249 hits)

By Jeremy, actually.  I'm not sure why it lists my name instead --
Freshmeat bug?

--amk



From hinsen at cnrs-orleans.fr  Tue Oct 17 22:27:10 2000
From: hinsen at cnrs-orleans.fr (Konrad Hinsen)
Date: Tue, 17 Oct 2000 22:27:10 +0200
Subject: [Python-Dev] Re: [Numpy-discussion] Re: numpy,  overflow, inf, ieee, and rich comparison
In-Reply-To: <39EB3D03.A00C78B6@jps.net> (message from Chris Barker on Mon, 16
	Oct 2000 10:38:11 -0700)
References: <LNBBLJKPBEHFEDALKOLCGEFLHLAA.tim_one@email.msn.com> <39EB3D03.A00C78B6@jps.net>
Message-ID: <200010172027.WAA11907@chinon.cnrs-orleans.fr>

> Are people doing the kind of numeric programming with "complex
> algorithms" using Python that Konrad refers to? More importantly, how
> many people?

At least one: me.

> >  Guido thinks that 2/3 returning 0 was a design mistake,
> > but not that math.sqrt(-1) raising an exception is a mistake.  Most Python
> > users won't know what to do with a complex number, so it's "an error" to
> > them.
>
> Guido's philosophy is clearly that Python defaults should be geared to
> "Most Python users". I agree, and as I wrote in an earlier post, the

It's difficult to say what "most Python users" want; it's not a static
community. I'd say the basic principle is "no bad surprises".  2/3 ==
0 is a bad surprise for anyone who knows elementary math but is not
familiar with certain programming languages, especially since the
program goes on silently with a "wrong" intermediate result.

> Maybe we can have true 754 compliance in Py3k, and we can all be happy!!

Py3k forever!

Konrad.
--
-------------------------------------------------------------------------------
Konrad Hinsen                            | E-Mail: hinsen at cnrs-orleans.fr
Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24
Rue Charles Sadron                       | Fax:  +33-2.38.63.15.17
45071 Orleans Cedex 2                    | Deutsch/Esperanto/English/
France                                   | Nederlands/Francais
-------------------------------------------------------------------------------



From Nicolas.Chauvat at logilab.fr  Wed Oct 18 10:35:02 2000
From: Nicolas.Chauvat at logilab.fr (Nicolas Chauvat)
Date: Wed, 18 Oct 2000 10:35:02 +0200 (CEST)
Subject: [Python-Dev] Re: [XML-SIG] PyXML home page on SF
In-Reply-To: <200010172151.XAA00871@loewis.home.cs.tu-berlin.de>
Message-ID: <Pine.LNX.4.21.0010181025220.12124-100000@aries>

On Tue, 17 Oct 2000, Martin v. Loewis wrote:

[about my suggestion concerning a SourceForge dedicated to python]

That was only a suggestion, not a demand as someone stated. I would love
to set up a pythonforge myself if I had the resources, unfortunately I
don't... maybe in a few months? Time will tell. For now I'll just go
back to hacking and keep quiet.

Cheers, :)

-- 
Nicolas Chauvat

http://www.logilab.com - "Mais o? est donc Ornicar ?" - LOGILAB, Paris (France)




From barry at scottb.demon.co.uk  Wed Oct 18 11:57:04 2000
From: barry at scottb.demon.co.uk (Barry Scott)
Date: Wed, 18 Oct 2000 10:57:04 +0100
Subject: [Python-Dev] build problems large and small on FreeBSD
In-Reply-To: <200010171406.JAA09272@cj20424-a.reston1.va.home.com>
Message-ID: <001401c038e9$c4cabbd0$060210ac@private>

O.k. will do, hopefully this weekend.

		BArry

> -----Original Message-----
> From: guido at cj20424-a.reston1.va.home.com
> [mailto:guido at cj20424-a.reston1.va.home.com]On Behalf Of Guido van
> Rossum
> Sent: 17 October 2000 15:06
> To: Barry Scott
> Cc: jeremy at beopen.com; python-dev at python.org
> Subject: Re: [Python-Dev] build problems large and small on FreeBSD
> 
> 
> > The FreeBSD ports collection had to be updated to support
> > importing C++ extensions with Python 1.5.2. (You get things
> > like cout not defined when importing).
> > 
> > Are the nessesary compile/link changes in 2.0?
> 
> Tell you what: I have no idea. :-(
> 
> I believe there were some changes to the Makefile and/or config file
> to support C++, but I don't know if this works on FreeBSD.  I'm not a
> big C++ user myself, so I rarely try this...
> 
> Can you try it?  If it doesn't work out of the box, let's sit down
> together and figure out a fix.
> 
> --Guido van Rossum (home page: http://www.python.org/~guido/)
> 
> 



From mal at lemburg.com  Wed Oct 18 18:03:16 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Wed, 18 Oct 2000 18:03:16 +0200
Subject: [Python-Dev] Ready for Python 2.1 ?
Message-ID: <39EDC9C4.7D61454@lemburg.com>

Before starting to work on postponed patches and checking them
in: is the current CVS tree ready for new checkins (tags applied,
etc.) ?

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From fdrake at beopen.com  Wed Oct 18 18:29:45 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Wed, 18 Oct 2000 12:29:45 -0400 (EDT)
Subject: [Python-Dev] Ready for Python 2.1 ?
In-Reply-To: <39EDC9C4.7D61454@lemburg.com>
References: <39EDC9C4.7D61454@lemburg.com>
Message-ID: <14829.53241.51394.729109@cj42289-a.reston1.va.home.com>

M.-A. Lemburg writes:
 > Before starting to work on postponed patches and checking them
 > in: is the current CVS tree ready for new checkins (tags applied,
 > etc.) ?

  Yes; I posted a note re-opening the tree yesterday (or late Monday
night; I can't remember that far back).
  We've just been too tired to do a lot since the release.  ;)


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From tim_one at email.msn.com  Wed Oct 18 18:52:52 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Wed, 18 Oct 2000 12:52:52 -0400
Subject: [Python-Dev] Ready for Python 2.1 ?
In-Reply-To: <14829.53241.51394.729109@cj42289-a.reston1.va.home.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCOEMMHLAA.tim_one@email.msn.com>

[Fred L. Drake, Jr.]
> ...
>   We've just been too tired to do a lot since the release.  ;)

LOL!  You're the very soul of diplomacy, Fred -- but I guess, overall, it
really is prudent not to mention all our recent suicide attempts <wink>.

my-wrists-are-killing-me-ly y'rs  - tim





From skip at mojam.com  Wed Oct 18 19:19:25 2000
From: skip at mojam.com (Skip Montanaro)
Date: Wed, 18 Oct 2000 12:19:25 -0500 (CDT)
Subject: [Python-Dev] Ready for Python 2.1 ?
In-Reply-To: <LNBBLJKPBEHFEDALKOLCOEMMHLAA.tim_one@email.msn.com>
References: <14829.53241.51394.729109@cj42289-a.reston1.va.home.com>
	<LNBBLJKPBEHFEDALKOLCOEMMHLAA.tim_one@email.msn.com>
Message-ID: <14829.56221.303087.523464@beluga.mojam.com>

    Tim> my-wrists-are-killing-me-ly y'rs  - tim

You need my typing watcher:

    http://www.musi-cal.com/~skip/python/watch.py

Only problem is I never figured out how to make it watch keystrokes
directly.  It detects mouse movement.  Since I do most of my typing in
Emacs, I fudged the keystroke thing by having the auto-save hook jiggle the
mouse a little...

I've tried, so far unsuccessfully, to make this a SourceForge project.  I've
even asked for help from SF, but their response wasn't helpful, and the
round-trip time for a response is too long to make pursuing that path
worthwhile.  The watch project is at

    http://sourceforge.net/projects/watch/

All I have is a CVSROOT/modules file.  Nothing I've tried has successfully
imported the one project file into cvs.

If anyone has any suggestions for kickstarting this thing, it would be much
appreciated.

Thx,

Skip




From thomas at xs4all.net  Wed Oct 18 20:43:19 2000
From: thomas at xs4all.net (Thomas Wouters)
Date: Wed, 18 Oct 2000 20:43:19 +0200
Subject: [Python-Dev] Ready for Python 2.1 ?
In-Reply-To: <14829.56221.303087.523464@beluga.mojam.com>; from skip@mojam.com on Wed, Oct 18, 2000 at 12:19:25PM -0500
References: <14829.53241.51394.729109@cj42289-a.reston1.va.home.com> <LNBBLJKPBEHFEDALKOLCOEMMHLAA.tim_one@email.msn.com> <14829.56221.303087.523464@beluga.mojam.com>
Message-ID: <20001018204319.L12812@xs4all.nl>

On Wed, Oct 18, 2000 at 12:19:25PM -0500, Skip Montanaro wrote:

>     Tim> my-wrists-are-killing-me-ly y'rs  - tim

> You need my typing watcher:

Given his remark about suicide attempts, I'm not sure if Tim really meant
'RSI' when he wrote that :-)

>     http://www.musi-cal.com/~skip/python/watch.py

> Only problem is I never figured out how to make it watch keystrokes
> directly.  It detects mouse movement.  Since I do most of my typing in
> Emacs, I fudged the keystroke thing by having the auto-save hook jiggle the
> mouse a little...

Funny, a colleague of mine has a similar tool. Also written in Python, I
think, though it may have been created in his Perl Period. On a linux box,
you can determine keystrokes by using /proc/interrupts. At least, if your
keyboard has an interrupt all for itself. (Pretty likely, really :)

-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!



From skip at mojam.com  Wed Oct 18 21:11:20 2000
From: skip at mojam.com (Skip Montanaro)
Date: Wed, 18 Oct 2000 14:11:20 -0500 (CDT)
Subject: [Python-Dev] Ready for Python 2.1 ?
In-Reply-To: <20001018204319.L12812@xs4all.nl>
References: <14829.53241.51394.729109@cj42289-a.reston1.va.home.com>
	<LNBBLJKPBEHFEDALKOLCOEMMHLAA.tim_one@email.msn.com>
	<14829.56221.303087.523464@beluga.mojam.com>
	<20001018204319.L12812@xs4all.nl>
Message-ID: <14829.62936.109759.567547@beluga.mojam.com>

    Thomas> On a linux box, you can determine keystrokes by using
    Thomas> /proc/interrupts. At least, if your keyboard has an interrupt
    Thomas> all for itself. (Pretty likely, really :)

Thanks, Neil S. sent me a patch for that already.  I'll try to work it into
the code.  Anyone have any idea how to monitor keystrokes on Windows, Mac or
other Unix flavors?  I suspect I'll just have to bite the bullet and work in
platform-dependent code for this.

Skip



From esr at thyrsus.com  Wed Oct 18 21:36:01 2000
From: esr at thyrsus.com (Eric S. Raymond)
Date: Wed, 18 Oct 2000 15:36:01 -0400
Subject: [Python-Dev] Ready for Python 2.1 ?
In-Reply-To: <14829.62936.109759.567547@beluga.mojam.com>; from skip@mojam.com on Wed, Oct 18, 2000 at 02:11:20PM -0500
References: <14829.53241.51394.729109@cj42289-a.reston1.va.home.com> <LNBBLJKPBEHFEDALKOLCOEMMHLAA.tim_one@email.msn.com> <14829.56221.303087.523464@beluga.mojam.com> <20001018204319.L12812@xs4all.nl> <14829.62936.109759.567547@beluga.mojam.com>
Message-ID: <20001018153601.A18127@thyrsus.com>

Skip Montanaro <skip at mojam.com>:
> Thanks, Neil S. sent me a patch for that already.  I'll try to work it into
> the code.  Anyone have any idea how to monitor keystrokes on Windows, Mac or
> other Unix flavors?  I suspect I'll just have to bite the bullet and work in
> platform-dependent code for this.

Might this monitoring function be a candidate for the Python library when 
it's done?
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

A man with a gun is a citizen.  A man without a gun is a subject.



From cgw at fnal.gov  Wed Oct 18 21:53:09 2000
From: cgw at fnal.gov (Charles G Waldman)
Date: Wed, 18 Oct 2000 14:53:09 -0500 (CDT)
Subject: [Python-Dev] Ready for Python 2.1 ?
In-Reply-To: <14829.62936.109759.567547@beluga.mojam.com>
References: <14829.53241.51394.729109@cj42289-a.reston1.va.home.com>
	<LNBBLJKPBEHFEDALKOLCOEMMHLAA.tim_one@email.msn.com>
	<14829.56221.303087.523464@beluga.mojam.com>
	<20001018204319.L12812@xs4all.nl>
	<14829.62936.109759.567547@beluga.mojam.com>
Message-ID: <14829.65445.421622.258893@buffalo.fnal.gov>

Skip Montanaro writes:
 > 
 > Thanks, Neil S. sent me a patch for that already.  I'll try to work it into
 > the code.  Anyone have any idea how to monitor keystrokes on Windows, Mac or
 > other Unix flavors?  I suspect I'll just have to bite the bullet and work in
 > platform-dependent code for this.

Can't tell you about Windows or Mac, but for Unix I'd read the file
driver/timers.c in the XScreensaver distribution (www.jwz.org).  This
code is pretty sophisticated and runs on all the major Unix flavors.



From skip at mojam.com  Wed Oct 18 22:22:45 2000
From: skip at mojam.com (Skip Montanaro)
Date: Wed, 18 Oct 2000 15:22:45 -0500 (CDT)
Subject: [Python-Dev] Ready for Python 2.1 ?
In-Reply-To: <14829.65445.421622.258893@buffalo.fnal.gov>
References: <14829.53241.51394.729109@cj42289-a.reston1.va.home.com>
	<LNBBLJKPBEHFEDALKOLCOEMMHLAA.tim_one@email.msn.com>
	<14829.56221.303087.523464@beluga.mojam.com>
	<20001018204319.L12812@xs4all.nl>
	<14829.62936.109759.567547@beluga.mojam.com>
	<14829.65445.421622.258893@buffalo.fnal.gov>
Message-ID: <14830.1685.932659.181060@beluga.mojam.com>

    Charles> ... but for Unix I'd read the file driver/timers.c in the
    Charles> XScreensaver distribution (www.jwz.org).  This code is pretty
    Charles> sophisticated and runs on all the major Unix flavors.

Thanks, Charles.  I will check it out.

Those of you who are former (or current) od users will appreciate Jamie
Zawinski's home page even if you're not interested in this topic.  I revisit
his site periodically.  I'm never disappointed...

Skip



From est at hyperreal.org  Wed Oct 18 22:30:46 2000
From: est at hyperreal.org (est at hyperreal.org)
Date: Wed, 18 Oct 2000 13:30:46 -0700 (PDT)
Subject: [Python-Dev] Ready for Python 2.1 ?
In-Reply-To: <14830.1685.932659.181060@beluga.mojam.com> from Skip Montanaro
 at "Oct 18, 2000 03:22:45 pm"
Message-ID: <20001018203047.27215.qmail@hyperreal.org>

Skip Montanaro discourseth:
> 
> Those of you who are former (or current) od users will appreciate Jamie
> Zawinski's home page even if you're not interested in this topic.  I revisit
> his site periodically.  I'm never disappointed...

Looks more like emacs hexl-mode to me.

Hmm..I guess you got this thread off topic. :)

E



From martin at loewis.home.cs.tu-berlin.de  Wed Oct 18 23:09:36 2000
From: martin at loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Wed, 18 Oct 2000 23:09:36 +0200
Subject: [Python-Dev] This Project Has Not Released Any Files
Message-ID: <200010182109.XAA00917@loewis.home.cs.tu-berlin.de>

What is the reason for not publishing Python 2.0 on SF for download?
SF certainly wouldn't be the primary source, but I think at least the
source distribution should be available there, with the release notes
telling where to get binary distributions (BeOpen, ActiveState, who
else?)

Regards,
Martin




From tim_one at email.msn.com  Wed Oct 18 23:34:38 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Wed, 18 Oct 2000 17:34:38 -0400
Subject: [Python-Dev] This Project Has Not Released Any Files
In-Reply-To: <200010182109.XAA00917@loewis.home.cs.tu-berlin.de>
Message-ID: <LNBBLJKPBEHFEDALKOLCAENKHLAA.tim_one@email.msn.com>

[Martin v. Loewis]
> What is the reason for not publishing Python 2.0 on SF for download?


From gstein at lyra.org  Thu Oct 19 00:44:13 2000
From: gstein at lyra.org (Greg Stein)
Date: Wed, 18 Oct 2000 15:44:13 -0700
Subject: [Python-Dev] This Project Has Not Released Any Files
In-Reply-To: <LNBBLJKPBEHFEDALKOLCAENKHLAA.tim_one@email.msn.com>; from tim_one@email.msn.com on Wed, Oct 18, 2000 at 05:34:38PM -0400
References: <200010182109.XAA00917@loewis.home.cs.tu-berlin.de> <LNBBLJKPBEHFEDALKOLCAENKHLAA.tim_one@email.msn.com>
Message-ID: <20001018154413.A31010@lyra.org>

On Wed, Oct 18, 2000 at 05:34:38PM -0400, Tim Peters wrote:
> [Martin v. Loewis]
> > What is the reason for not publishing Python 2.0 on SF for download?
> 
> >From BeOpen.com's POV, so long as they were paying major bills, they would
> rather have download traffic tickle their ad banners than SF's ad banners.
> 
> >From our (PythonLabs) POV, another publishing site is more work, and one URL
> is about as good as any other.  Besides, rising to the top of SF's "most
> active" list has not been an explicit life goal for any of us <wink>.

And here is where the larger community can help. Presuming that non-admins
can publish files, then we could take on the burden of publishing the files
via SF.

> > SF certainly wouldn't be the primary source, but I think at least the
> > source distribution should be available there, with the release notes
> > telling where to get binary distributions (BeOpen, ActiveState, who
> > else?)
> 
> I didn't see any advantage claimed for publishing on SF.  Without an
> advantage, the work/benefit ratio is infinite.

Work == 0 for you guys, presuming that non-admins can publish.

[ off to take a look... ]

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/



From akuchlin at mems-exchange.org  Thu Oct 19 18:20:37 2000
From: akuchlin at mems-exchange.org (Andrew Kuchling)
Date: Thu, 19 Oct 2000 12:20:37 -0400
Subject: [Python-Dev] 2.0 articles
Message-ID: <20001019122037.C21214@kronos.cnri.reston.va.us>

Before we all become focused on new features for Python 2.1, it would
be nice to do a bit more work on raising awareness of the new features
in 2.0.  There's little point in developing software if you don't
actually tell anyone about it, after all.

I'd like to suggest that people try to write some brief articles, just
a few pages long, each covering a particular feature in some detail.

Looking through the list of new stuff, the most significant features are:

* Unicode support.  (Perl's UTF-8 support still seems incomplete, with
  developers referring to it as "unusable", so we should definitely try and
  point out that we have working Unicode support right now.)

* Distutils: an introduction to writing setup scripts for simple
  Python modules, packages, and C extensions.

* The new XML tools.

* The new gettext support.

* Maybe the linuxaudiodev module, too.

Any other suggestions?

If the story of how a particular feature was implemented is
interesting, then that would also make a fine topic for a more
developer-oriented publication such as DDJ.  SRE or Unicode may be the
best candidates for this sort of thing, as their implementation
presented various tricky technical problems along the way.

Any volunteers?

--amk



From gvwilson at nevex.com  Thu Oct 19 18:53:31 2000
From: gvwilson at nevex.com (Greg Wilson)
Date: Thu, 19 Oct 2000 12:53:31 -0400 (EDT)
Subject: [Python-Dev] 2.0 articles
In-Reply-To: <20001019122037.C21214@kronos.cnri.reston.va.us>
Message-ID: <Pine.LNX.4.10.10010191237320.8628-100000@akbar.nevex.com>

> Andrew Kuchling wrote:
> Before we all become focused on new features for Python 2.1, it would be
> nice to do a bit more work on raising awareness of the new features in 2.0.  

"Doctor Dobb's Journal" would be very interested in articles --- 3000 words
(plus or minus), plus some code examples and diagrams.

> * Unicode support.  (Perl's UTF-8 support still seems incomplete, with
>   developers referring to it as "unusable", so we should definitely try and
>   point out that we have working Unicode support right now.)

Definitely --- the practical details of implementing Unicode, and a
Unicode-aware regular expression engine, would be very interesting to our
readers.  However, please steer clear of saying, "And anyway, Perl is broken."
(I just got a review copy of Hunt and Thomas's book on Ruby.  There are three
places in the first two chapters where they say, "And Ruby has more users in
Japan than Python."  I'll finish the book anyway.)

> * Distutils: an introduction to writing setup scripts for simple
>   Python modules, packages, and C extensions.

Possibly interesting; would be more so if Distutils could be applied/was being
applied to installation problems in other languages.

> * The new XML tools.

Definitely.

> * The new gettext support.
> * Maybe the linuxaudiodev module, too.

These are both probably too specialized...

> Any other suggestions?

The garbage collector: Java and Ruby both score points by having full garbage
collection, so its availability in Python 2.0 (along with a discussion of the
things that might break or change as a result) would be very interesting.

Thanks,
Greg (a contributing editor with DDJ)





From nas at arctrix.com  Thu Oct 19 12:09:52 2000
From: nas at arctrix.com (Neil Schemenauer)
Date: Thu, 19 Oct 2000 03:09:52 -0700
Subject: [Python-Dev] 2.0 articles
In-Reply-To: <Pine.LNX.4.10.10010191237320.8628-100000@akbar.nevex.com>; from gvwilson@nevex.com on Thu, Oct 19, 2000 at 12:53:31PM -0400
References: <20001019122037.C21214@kronos.cnri.reston.va.us> <Pine.LNX.4.10.10010191237320.8628-100000@akbar.nevex.com>
Message-ID: <20001019030952.A32671@glacier.fnational.com>

On Thu, Oct 19, 2000 at 12:53:31PM -0400, Greg Wilson wrote:
> The garbage collector: Java and Ruby both score points by having full garbage
> collection, so its availability in Python 2.0 (along with a discussion of the
> things that might break or change as a result) would be very interesting.

This is on my todo list.  I think there are some interesting
implementation issues.  Also, the article would be useful
documentation for python-dev type people.

  Neil



From akuchlin at mems-exchange.org  Thu Oct 19 19:32:08 2000
From: akuchlin at mems-exchange.org (Andrew Kuchling)
Date: Thu, 19 Oct 2000 13:32:08 -0400
Subject: [Python-Dev] 2.0 articles
In-Reply-To: <Pine.LNX.4.10.10010191237320.8628-100000@akbar.nevex.com>; from gvwilson@nevex.com on Thu, Oct 19, 2000 at 12:53:31PM -0400
References: <20001019122037.C21214@kronos.cnri.reston.va.us> <Pine.LNX.4.10.10010191237320.8628-100000@akbar.nevex.com>
Message-ID: <20001019133208.D21214@kronos.cnri.reston.va.us>

On Thu, Oct 19, 2000 at 12:53:31PM -0400, Greg Wilson wrote:
>"Doctor Dobb's Journal" would be very interested in articles --- 3000 words
>(plus or minus), plus some code examples and diagrams.

I was thinking more about on-line places such as
oreillynet.com/python/, but DDJ would be better still.

>The garbage collector: Java and Ruby both score points by having full garbage
>collection, so its availability in Python 2.0 (along with a discussion of the
>things that might break or change as a result) would be very interesting.

Arising out of lunch-time discussion, a comparison of how different
FFIs (Lisp, Java, Smalltalk, others?) deal with garbage collection
would be interesting, though perhaps unsuitable for DDJ, since the
topic is a rather unfocused one.

--amk




From martin at loewis.home.cs.tu-berlin.de  Thu Oct 19 19:31:58 2000
From: martin at loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Thu, 19 Oct 2000 19:31:58 +0200
Subject: [Python-Dev] This Project Has Not Released Any Files
Message-ID: <200010191731.TAA01114@loewis.home.cs.tu-berlin.de>

[Tim Peters]
> From BeOpen.com's POV, so long as they were paying major bills, they
> would rather have download traffic tickle their ad banners than SF's
> ad banners.

Even though this should have been clear to me all the time, stating it
explicitly triggers alarms for me.

I just checked, and it appears that Python 2.0 is not available for
download via ftp. In particular, it is not available via ftp from
ftp.python.org! If it was there, mirrors all over the world would pick
it up and bring it in a location near me (ftp.fu-berlin.de would be
nearest) (*).

So while making it available on SF may indeed give no advantage,
making it available on python.org would provide users with alternative
download locations, so that I don't feel the bandwidth limitation that
Web download from pythonlabs.com produces. That would be a clear
advantage to me, at least.

Of course, having ftp mirrors would mean that many downloads do not
tickle anybody's ad banners - which would probably be in the interest
of other users as well, just not in the interest of BeOpen. So I'm
curious how this conflict of interest is resolved...

Regards,
Martin

(*) ftp://ftp.python.org/python/src/README does not even mention
Python 2.0, and ftp://ftp.python.org/python/src/README.ftp says

Note that some mirrors only collect the this directory (src), and the
doc and contrib siblings, while the ftp master site,
<URL:ftp://ftp.python.org/>, has much more.

"Much more" may be true, just nothing recent... I probably should ask
ftpmaster.python.org to put Python-2.0.tar.gz in that directory.



From akuchlin at mems-exchange.org  Thu Oct 19 19:42:19 2000
From: akuchlin at mems-exchange.org (Andrew Kuchling)
Date: Thu, 19 Oct 2000 13:42:19 -0400
Subject: [Python-Dev] This Project Has Not Released Any Files
In-Reply-To: <200010191731.TAA01114@loewis.home.cs.tu-berlin.de>; from martin@loewis.home.cs.tu-berlin.de on Thu, Oct 19, 2000 at 07:31:58PM +0200
References: <200010191731.TAA01114@loewis.home.cs.tu-berlin.de>
Message-ID: <20001019134219.A29218@kronos.cnri.reston.va.us>

On Thu, Oct 19, 2000 at 07:31:58PM +0200, Martin v. Loewis wrote:
>(*) ftp://ftp.python.org/python/src/README does not even mention
>Python 2.0, and ftp://ftp.python.org/python/src/README.ftp says

Unless one of the BeOpen Pythoneers is already going to do this, I'll
go ahead and drop the relevant files into places.  Guys?

While we're at it, how about making the filenames for the source code
consistent? 

-rw-r--r--    1 guido    psa       2533053 Apr 13  1999 py152.tgz
-rw-r--r--    1 1103     psa       2259957 Oct 31  1998 pyth151.tgz
-rw-r--r--    1 guido    psa       1907724 May 31  1995 python1.2.tar.gz
-rw-r--r--    1 guido    psa       2037062 Oct 12  1995 python1.3.tar.gz
-rw-r--r--    1 guido    psa       2252481 Oct 25  1996 python1.4.tar.gz
-rw-r--r--    1 guido    psa       2904353 Jan  3  1998 python1.5.tar.gz

I like pythonX.X.tar.gz best, and will change the filenames (leaving
bc-compat symlinks for py152.tgz and pyth151.tgz) unless vetoed.
Though isn't the standard GNU naming convention more like
python-1.5.tar.gz?

--amk



From esr at thyrsus.com  Thu Oct 19 20:05:48 2000
From: esr at thyrsus.com (Eric S. Raymond)
Date: Thu, 19 Oct 2000 14:05:48 -0400
Subject: [Python-Dev] This Project Has Not Released Any Files
In-Reply-To: <20001019134219.A29218@kronos.cnri.reston.va.us>; from akuchlin@mems-exchange.org on Thu, Oct 19, 2000 at 01:42:19PM -0400
References: <200010191731.TAA01114@loewis.home.cs.tu-berlin.de> <20001019134219.A29218@kronos.cnri.reston.va.us>
Message-ID: <20001019140548.A21315@thyrsus.com>

Andrew Kuchling <akuchlin at mems-exchange.org>:
> I like pythonX.X.tar.gz best, and will change the filenames (leaving
> bc-compat symlinks for py152.tgz and pyth151.tgz) unless vetoed.
> Though isn't the standard GNU naming convention more like
> python-1.5.tar.gz?

It is, and I wish we'd move to it as did the Perl guys.  It makes life
substantially easier to have really uniform naming conventions,
especially for programs like the Metalabs file clerk.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Don't ever think you know what's right for the other person.
He might start thinking he knows what's right for you.
	-- Paul Williams, `Das Energi'



From mwh21 at cam.ac.uk  Thu Oct 19 20:01:29 2000
From: mwh21 at cam.ac.uk (Michael Hudson)
Date: 19 Oct 2000 19:01:29 +0100
Subject: [Python-Dev] 2.0 articles
In-Reply-To: Andrew Kuchling's message of "Thu, 19 Oct 2000 12:20:37 -0400"
References: <20001019122037.C21214@kronos.cnri.reston.va.us>
Message-ID: <m3d7gwsoau.fsf@atrus.jesus.cam.ac.uk>

Andrew Kuchling <akuchlin at mems-exchange.org> writes:

> Before we all become focused on new features for Python 2.1, it would
> be nice to do a bit more work on raising awareness of the new features
> in 2.0.  There's little point in developing software if you don't
> actually tell anyone about it, after all.
> 
> I'd like to suggest that people try to write some brief articles, just
> a few pages long, each covering a particular feature in some detail.
[snip]
> Any volunteers?

It's not as exciting as Unicode or XML, but I've thrashed out a few
hundred words on the new "setdefault" dictionary method.  It's up
here:

http://starship.python.net/crew/mwh/hacks/setdefault.html

Tell me what you think!  There's the beginning of a longer example in
a comment at the bottom, but I felt it was getting a bit long-winded
to be of interest.

Cheers,
M.

-- 
  If i don't understand lisp,  it would be wise to not bray about
  how lisp is stupid or otherwise criticize, because my stupidity 
  would be archived and open for all in the know to see.
                                                -- Xah, comp.lang.lisp




From gstein at lyra.org  Thu Oct 19 20:52:53 2000
From: gstein at lyra.org (Greg Stein)
Date: Thu, 19 Oct 2000 11:52:53 -0700
Subject: [Python-Dev] This Project Has Not Released Any Files
In-Reply-To: <200010191731.TAA01114@loewis.home.cs.tu-berlin.de>; from martin@loewis.home.cs.tu-berlin.de on Thu, Oct 19, 2000 at 07:31:58PM +0200
References: <200010191731.TAA01114@loewis.home.cs.tu-berlin.de>
Message-ID: <20001019115253.W31108@lyra.org>

On Thu, Oct 19, 2000 at 07:31:58PM +0200, Martin v. Loewis wrote:
>...
> Of course, having ftp mirrors would mean that many downloads do not
> tickle anybody's ad banners - which would probably be in the interest
> of other users as well, just not in the interest of BeOpen. So I'm
> curious how this conflict of interest is resolved...

Stating that a "conflict of interest" even EXISTS is a rather sorry
statement on things.

-g

-- 
Greg Stein, http://www.lyra.org/



From gstein at lyra.org  Thu Oct 19 20:54:36 2000
From: gstein at lyra.org (Greg Stein)
Date: Thu, 19 Oct 2000 11:54:36 -0700
Subject: [Python-Dev] This Project Has Not Released Any Files
In-Reply-To: <20001019134219.A29218@kronos.cnri.reston.va.us>; from akuchlin@mems-exchange.org on Thu, Oct 19, 2000 at 01:42:19PM -0400
References: <200010191731.TAA01114@loewis.home.cs.tu-berlin.de> <20001019134219.A29218@kronos.cnri.reston.va.us>
Message-ID: <20001019115436.X31108@lyra.org>

On Thu, Oct 19, 2000 at 01:42:19PM -0400, Andrew Kuchling wrote:
> On Thu, Oct 19, 2000 at 07:31:58PM +0200, Martin v. Loewis wrote:
> >(*) ftp://ftp.python.org/python/src/README does not even mention
> >Python 2.0, and ftp://ftp.python.org/python/src/README.ftp says
> 
> Unless one of the BeOpen Pythoneers is already going to do this, I'll
> go ahead and drop the relevant files into places.  Guys?

Please... just do it.

>...
> I like pythonX.X.tar.gz best, and will change the filenames (leaving
> bc-compat symlinks for py152.tgz and pyth151.tgz) unless vetoed.
> Though isn't the standard GNU naming convention more like
> python-1.5.tar.gz?

I'm with Eric -- go for the GNU standard.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/



From akuchlin at mems-exchange.org  Thu Oct 19 21:11:42 2000
From: akuchlin at mems-exchange.org (Andrew Kuchling)
Date: Thu, 19 Oct 2000 15:11:42 -0400
Subject: [Python-Dev] This Project Has Not Released Any Files
In-Reply-To: <20001019115436.X31108@lyra.org>; from gstein@lyra.org on Thu, Oct 19, 2000 at 11:54:36AM -0700
References: <200010191731.TAA01114@loewis.home.cs.tu-berlin.de> <20001019134219.A29218@kronos.cnri.reston.va.us> <20001019115436.X31108@lyra.org>
Message-ID: <20001019151142.A29651@kronos.cnri.reston.va.us>

On Thu, Oct 19, 2000 at 11:54:36AM -0700, Greg Stein wrote:
>On Thu, Oct 19, 2000 at 01:42:19PM -0400, Andrew Kuchling wrote:
>> Unless one of the BeOpen Pythoneers is already going to do this, I'll
>> go ahead and drop the relevant files into places.  Guys?

>Please... just do it.

I charged ahead and did it anyway; the Pythoneers can spank me for it
later.  (Worse, maybe they'll do something *bad* to me...)  There were
already doc/1.6/ and doc/2.0/ directories, and binaries (Windows,
RPMs) were in /pub/python/2.0/, along with the source. 

So I only touched /pub/python/src/.  All the releases and betas are
now consistently named python-X.Y.Z.tar.gz.  I've left symlinks in
place for the original filenames of the 1.5.1, 1.5.2 and 1.6 final
releases, but didn't bother making links for releases older than 1.5.1
or for beta versions, so any FTP URLs pointing directly to those files
will be broken.

--amk



From jeremy at alum.mit.edu  Fri Oct 20 18:28:19 2000
From: jeremy at alum.mit.edu (Jeremy Hylton)
Date: Fri, 20 Oct 2000 12:28:19 -0400 (EDT)
Subject: [Python-Dev] This Project Has Not Released Any Files
In-Reply-To: <20001019115436.X31108@lyra.org>
References: <200010191731.TAA01114@loewis.home.cs.tu-berlin.de>
	<20001019134219.A29218@kronos.cnri.reston.va.us>
	<20001019115436.X31108@lyra.org>
Message-ID: <14832.29347.622325.95025@bitdiddle.concentric.net>

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

  GS> On Thu, Oct 19, 2000 at 01:42:19PM -0400, Andrew Kuchling wrote:
  >> On Thu, Oct 19, 2000 at 07:31:58PM +0200, Martin v. Loewis wrote:
  >> >(*) ftp://ftp.python.org/python/src/README does not even mention
  >> >Python 2.0, and ftp://ftp.python.org/python/src/README.ftp says
  >>
  >> Unless one of the BeOpen Pythoneers is already going to do this,
  >> I'll go ahead and drop the relevant files into places.  Guys?

  GS> Please... just do it.

In the interest of making the distribution as widely available as
possible, I've placed files on SourceForge and at
http://www.python.org/2.0/

  >> ...  I like pythonX.X.tar.gz best, and will change the filenames
  >> (leaving bc-compat symlinks for py152.tgz and pyth151.tgz) unless
  >> vetoed.  Though isn't the standard GNU naming convention more
  >> like python-1.5.tar.gz?

  GS> I'm with Eric -- go for the GNU standard.

I used the file name conventions that we used throughout the 2.0
release cycle, e.g. Python-2.0.tar.gz.  I don't know if that's the GNU
standard or not (didn't realize it was a standard; don't know where to
find said standard; or is it just a custom?)

Jeremy



From jeremy at alum.mit.edu  Fri Oct 20 18:31:47 2000
From: jeremy at alum.mit.edu (Jeremy Hylton)
Date: Fri, 20 Oct 2000 12:31:47 -0400 (EDT)
Subject: [Python-Dev] 2.0 articles
In-Reply-To: <20001019133208.D21214@kronos.cnri.reston.va.us>
References: <20001019122037.C21214@kronos.cnri.reston.va.us>
	<Pine.LNX.4.10.10010191237320.8628-100000@akbar.nevex.com>
	<20001019133208.D21214@kronos.cnri.reston.va.us>
Message-ID: <14832.29555.123226.831103@bitdiddle.concentric.net>

>>>>> "AMK" == Andrew Kuchling <akuchlin at mems-exchange.org> writes:

  AMK> On Thu, Oct 19, 2000 at 12:53:31PM -0400, Greg Wilson wrote:
  >> "Doctor Dobb's Journal" would be very interested in articles ---
  >> 3000 words (plus or minus), plus some code examples and diagrams.

  AMK> I was thinking more about on-line places such as
  AMK> oreillynet.com/python/, but DDJ would be better still.

And, of course, there's the Python conference: http://python9.org/

  >> The garbage collector: Java and Ruby both score points by having
  >> full garbage collection, so its availability in Python 2.0 (along
  >> with a discussion of the things that might break or change as a
  >> result) would be very interesting.

  AMK> Arising out of lunch-time discussion, a comparison of how
  AMK> different FFIs (Lisp, Java, Smalltalk, others?) deal with
  AMK> garbage collection would be interesting, though perhaps
  AMK> unsuitable for DDJ, since the topic is a rather unfocused one.

A comparison of different FFIs with respect to garbage collection
might be interesting; hard to say without seeing what the conclusions
are.

Jeremy



From akuchlin at mems-exchange.org  Fri Oct 20 18:26:56 2000
From: akuchlin at mems-exchange.org (Andrew Kuchling)
Date: Fri, 20 Oct 2000 12:26:56 -0400
Subject: [Python-Dev] This Project Has Not Released Any Files
In-Reply-To: <14832.29347.622325.95025@bitdiddle.concentric.net>; from jeremy@alum.mit.edu on Fri, Oct 20, 2000 at 12:28:19PM -0400
References: <200010191731.TAA01114@loewis.home.cs.tu-berlin.de> <20001019134219.A29218@kronos.cnri.reston.va.us> <20001019115436.X31108@lyra.org> <14832.29347.622325.95025@bitdiddle.concentric.net>
Message-ID: <20001020122656.A9679@kronos.cnri.reston.va.us>

On Fri, Oct 20, 2000 at 12:28:19PM -0400, Jeremy Hylton wrote:
>release cycle, e.g. Python-2.0.tar.gz.  I don't know if that's the GNU
>standard or not (didn't realize it was a standard; don't know where to
>find said standard; or is it just a custom?)

See http://www.cs.utah.edu/dept/old/texinfo/standards/standards.html#SEC24
Though I think here the standard is just codifying an existing custom
that's proved convenient.

www.fsf.org seems unresponsive at the moment, hence the strange link;
is *every* Web site in the world breaking today for some reason?

--amk





From akuchlin at mems-exchange.org  Fri Oct 20 18:28:10 2000
From: akuchlin at mems-exchange.org (Andrew Kuchling)
Date: Fri, 20 Oct 2000 12:28:10 -0400
Subject: [Python-Dev] 2.0 articles
In-Reply-To: <14832.29555.123226.831103@bitdiddle.concentric.net>; from jeremy@alum.mit.edu on Fri, Oct 20, 2000 at 12:31:47PM -0400
References: <20001019122037.C21214@kronos.cnri.reston.va.us> <Pine.LNX.4.10.10010191237320.8628-100000@akbar.nevex.com> <20001019133208.D21214@kronos.cnri.reston.va.us> <14832.29555.123226.831103@bitdiddle.concentric.net>
Message-ID: <20001020122810.B9679@kronos.cnri.reston.va.us>

On Fri, Oct 20, 2000 at 12:31:47PM -0400, Jeremy Hylton wrote:
>And, of course, there's the Python conference: http://python9.org/

That's preaching to the converted, though.  

--amk



From fdrake at acm.org  Fri Oct 20 18:51:44 2000
From: fdrake at acm.org (Fred L. Drake, Jr.)
Date: Fri, 20 Oct 2000 12:51:44 -0400 (EDT)
Subject: [Python-Dev] This Project Has Not Released Any Files
In-Reply-To: <14832.29347.622325.95025@bitdiddle.concentric.net>
References: <200010191731.TAA01114@loewis.home.cs.tu-berlin.de>
	<20001019134219.A29218@kronos.cnri.reston.va.us>
	<20001019115436.X31108@lyra.org>
	<14832.29347.622325.95025@bitdiddle.concentric.net>
Message-ID: <14832.30752.210553.712758@cj42289-a.reston1.va.home.com>

Jeremy Hylton writes:
 > In the interest of making the distribution as widely available as
 > possible, I've placed files on SourceForge and at
 > http://www.python.org/2.0/

  There's a separate python-rpms "Package"; the RPM files should go
there (I think).


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at acm.org>
PythonLabs Team Member




From thomas at xs4all.net  Fri Oct 20 22:21:18 2000
From: thomas at xs4all.net (Thomas Wouters)
Date: Fri, 20 Oct 2000 22:21:18 +0200
Subject: [Python-Dev] Re: Compiling python 2.0
In-Reply-To: <m37l73s8r3.fsf@atrus.jesus.cam.ac.uk>; from mwh21@cam.ac.uk on Fri, Oct 20, 2000 at 06:49:36PM +0100
References: <L3JH5.990$yK.3812548@nnrp3.proxad.net> <m37l73s8r3.fsf@atrus.jesus.cam.ac.uk>
Message-ID: <20001020222118.M12812@xs4all.nl>

On Fri, Oct 20, 2000 at 06:49:36PM +0100, Michael Hudson wrote:
> "Jean-Claude Levieux" <jclevieux at sud2000.com> writes:

> > I just tried to compile Python 2.0.
> > on BSDI BSD/OS 4.0.1

[ Sorry, missed the original message. Used the Archive to find it, tho ]

> Random guess, but you are using a ANSI C compiler, aren't you?  Python
> 2.0 now demands that.

BSDI uses gcc, so that's not the problem. Neither are these three warnings:

/usr/include/math.h:177: warning: function declaration isn't a prototype
/usr/include/math.h:257: warning: function declaration isn't a prototype
/usr/include/wchar.h:17: warning: function declaration isn't a prototype

(or any other warnings regarding 'function decl isn't a prototype)

They are a result of Python using '-Wstrict-prototypes' by default, if the
compiler is gcc. It just means BSDI declares a few functions without
specifying argument lists (prototypes) and has nothing to do with Python
(other than that Python always defines CFLAGS to contain
-Wstrict-prototypes.) There isn't an easy way to get this 'fixed',
unfortunately. If you want to quench the warnings, you'll have to edit
./Makefile, Objects/Makefile, Parser/Makefile, Python/Makefile,
and ./Modules/Makefile.pre. (Do not edit ./Modules/Makefile directly,
because it's overwritten by the 'makesetup' script, which parses the Setup
file.)

As for the other error, that's really an error :(

../libpython2.0.a(fileobject.o): In function portable_fseek':
/usr/home/thomas/Python-2.0/Objects/fileobject.c:274: undefined
reference to `TELL64'

The problem is that BSDI has an 'off_t' type that is larger than the 'long'
type, and Python's configure makes the flawed assumption that this means
BSDI supports large files (larger than 2Gb.) However, BSDI doesn't. This bug
is even present with BSDI 4.1, and probably more platforms. You can fix this
by editing './config.h' after running './configure', and commenting out the
HAVE_LARGEFILE_SUPPORT line; changing this:

#define HAVE_LARGEFILE_SUPPORT 1

into something like this:

/* #define HAVE_LARGEFILE_SUPPORT 1 */

(You can just remove the line as well.) The downside of both these 'hacks'
(excuse me, 'hotfixes'), is that you'll have to reedit the files again after
running configure again (or something that runs configure, like
'config.status'.)

I see a total of three bugs here: Python adds -Wstrict-prototypes even
though it can generate a lot of warnings that aren't related to Python;
there is no way to override the CFLAGS variable (you can pass it to
configure, and it uses it at first, but then just overwrites it); and
mis-detecting large file support. I can't decide which of the last two is
the biggest bug :-)

I would write a patch for the lot of 'm, but I'm in the middle of getting
ready to head to London for the Apache conference (any other Pythonistas
going ? :) and Have I Got News For You is about to start on BBC1. If you
don't do it, Jean-Claude, I'll submit bugreports on these when I'm back,
next Thursday.

(Oh, another hint: *disable threads* when compiling Python for BSDI 4.0.1.
You can leave them on for 4.1, but 4.0.1 has very broken threads, and it
will cause lots of problems in the signal module if you leave them on. You
can disable them by using '--with-threads=no' -- this is also listed in the
README, by the way. And note that BSDI 4.1 only has the large file support
problem, none of the others, and I strongly suggest upgrading for other
reasons as well.)

Python-dev: CC'd because this is material for a bugfix-release. There are
likely to be other platforms hit by the large filesupport misdetection.
Don't think this is enough to warrant a bugfix release (it's not *that*
brownbaggy) but it should definately go in if there is one ;P If I or
someone else didn't fix it by the time a bugfix release is considered,
please hit me. I also appologize for not properly testing Python 2.0 on BSDI
4.0.1 or 4.1... We still have those machines, but we are using less and less
of them. Out of sight, out of mind, and I'm happier using FreeBSD and Linux
:)

BSDI-isn't-all-bad--it's-just-that-by-now-Linux-and-FreeBSD-have-all-
	-those-good-sides-too-ly y'rs,

-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!



From trentm at ActiveState.com  Fri Oct 20 22:54:59 2000
From: trentm at ActiveState.com (Trent Mick)
Date: Fri, 20 Oct 2000 13:54:59 -0700
Subject: [Python-Dev] Re: Compiling python 2.0
In-Reply-To: <20001020222118.M12812@xs4all.nl>; from thomas@xs4all.net on Fri, Oct 20, 2000 at 10:21:18PM +0200
References: <L3JH5.990$yK.3812548@nnrp3.proxad.net> <m37l73s8r3.fsf@atrus.jesus.cam.ac.uk> <20001020222118.M12812@xs4all.nl>
Message-ID: <20001020135459.C1562@ActiveState.com>

On Fri, Oct 20, 2000 at 10:21:18PM +0200, Thomas Wouters wrote:
> As for the other error, that's really an error :(
> 
> ../libpython2.0.a(fileobject.o): In function portable_fseek':
> /usr/home/thomas/Python-2.0/Objects/fileobject.c:274: undefined
> reference to `TELL64'
> 
> The problem is that BSDI has an 'off_t' type that is larger than the 'long'
> type, and Python's configure makes the flawed assumption that this means
> BSDI supports large files (larger than 2Gb.) However, BSDI doesn't. This bug
> is even present with BSDI 4.1, and probably more platforms. You can fix this
> by editing './config.h' after running './configure', and commenting out the
> HAVE_LARGEFILE_SUPPORT line; changing this:
> 
> #define HAVE_LARGEFILE_SUPPORT 1
> 
> into something like this:
> 
> /* #define HAVE_LARGEFILE_SUPPORT 1 */
> 
> (You can just remove the line as well.) The downside of both these 'hacks'
> (excuse me, 'hotfixes'), is that you'll have to reedit the files again after
> running configure again (or something that runs configure, like
> 'config.status'.)

This one isthe saem problem that showed up for NetBSD1.4.2 and OpenBSD (I see
a pattern)
http://sourceforge.net/bugs/?func=detailbug&bug_id=112289&group_id=5470

It was fixed by adding a hack in fileobject.c to *define* TELL64.
http://sourceforge.net/patch/index.php?func=detailpatch&patch_id=101558&group_id=5470

For the quickfix, the same hack could be used for BSDI.

As you suggest Thomas, the proper fix is to patch configure.in such that it
does not report that these system support largefiles.

I don't have the time to do this right away, nor do I have one of these boxes
on which to test it. I can try to make a patch though. We don't you file a
bug and assign it to me.

Trent


-- 
Trent Mick
TrentM at ActiveState.com



From martin at loewis.home.cs.tu-berlin.de  Fri Oct 20 22:54:02 2000
From: martin at loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Fri, 20 Oct 2000 22:54:02 +0200
Subject: [Python-Dev] This Project Has Released Files
Message-ID: <200010202054.WAA01567@loewis.home.cs.tu-berlin.de>

> In the interest of making the distribution as widely available as
> possible, I've placed files on SourceForge and at
> http://www.python.org/2.0/

Thanks! also to anybody else contributing to the release process, in
particular to amk for his ongoing maintainance of various pieces on
python.org, and his efforts in getting the word out.

Regards,
Martin



From cgw at fnal.gov  Fri Oct 13 17:11:03 2000
From: cgw at fnal.gov (Charles G Waldman)
Date: Fri, 13 Oct 2000 10:11:03 -0500 (CDT)
Subject: [Python-Dev] can't build with threads on OSF/1
Message-ID: <14823.9735.525711.927269@buffalo.fnal.gov>

Sorry, I don't have time to investigate this fully right now.  Maybe
this weekend.  For now this is just a heads-up.  Hopefully, something
is just misconfigured on this system.

The machine in question is running OSF1 V4.0 878 alpha

I can only build Python from current CVS sources on OSF/1 if I specify
--without-thread.   If I don't specify this I get the following errors
at link time:

Unresolved:
__pthread_mutex_init
__pthread_mutex_destroy
__pthread_mutex_lock
__pthread_mutex_unlock
__pthread_cond_init
__pthread_cond_destroy
__pthread_cond_signal
__pthread_cond_wait
__pthread_create
__pthread_detach


Below find the output of cc -V as well as the output of ./configure
and make (sorry for the flood,  I assume too much detail is better
than not enough)

creating cache ./config.cache
checking MACHDEP... osf1V4
checking for --without-gcc... 
checking for --with-cxx=<compiler>... no
checking for gcc... cc
checking whether the C compiler (cc   ) works... yes
checking whether the C compiler (cc   ) is a cross-compiler... no
checking whether we are using GNU C... no
checking whether cc accepts -g... yes
checking for --with-suffix... 
checking LINKCC... $(PURIFY) $(CC)
checking LDLIBRARY... 
checking for ranlib... ranlib
checking for ar... ar
checking how to run the C preprocessor... cc -E
checking for AIX... no
checking for minix/config.h... no
checking whether cc accepts -OPT:Olimit=0... no
checking whether cc accepts -Olimit 1500... yes
checking for ANSI C header files... yes
checking for dlfcn.h... yes
checking for fcntl.h... yes
checking for limits.h... yes
checking for locale.h... yes
checking for ncurses.h... no
checking for poll.h... yes
checking for pthread.h... yes
checking for signal.h... yes
checking for stdarg.h... yes
checking for stddef.h... yes
checking for stdlib.h... yes
checking for thread.h... no
checking for unistd.h... yes
checking for utime.h... yes
checking for sys/audioio.h... no
checking for sys/file.h... yes
checking for sys/lock.h... yes
checking for db_185.h... no
checking for db.h... yes
checking for sys/param.h... yes
checking for sys/select.h... yes
checking for sys/socket.h... yes
checking for sys/time.h... yes
checking for sys/times.h... yes
checking for sys/un.h... yes
checking for sys/utsname.h... yes
checking for sys/wait.h... yes
checking for pty.h... yes
checking for libutil.h... no
checking for ndbm.h... yes
checking for db1/ndbm.h... no
checking for gdbm/ndbm.h... no
checking for dirent.h that defines DIR... yes
checking for opendir in -ldir... no
checking for clock_t in time.h... yes
checking for mode_t... yes
checking for off_t... yes
checking for pid_t... yes
checking return type of signal handlers... void
checking for size_t... yes
checking for uid_t in sys/types.h... yes
checking size of int... 4
checking size of long... 8
checking size of void *... 8
checking size of char... 1
checking size of short... 2
checking size of float... 4
checking size of double... 8
checking size of fpos_t... 8
checking for long long support... yes
checking size of long long... 8
checking for uintptr_t support... no
checking size of off_t... 8
checking whether to enable large file support... no
checking size of time_t... 4
checking for pthread_t... yes
checking size of pthread_t... 8
checking for --with-next-framework... no
checking for --with-dyld... no
checking SO... .so
checking LDSHARED... ld -shared -expect_unresolved "*"
checking CCSHARED... 
checking LINKFORSHARED... 
checking for dlopen in -ldl... no
checking for shl_load in -ldld... no
checking for --with-pydebug... no
checking for t_open in -lnsl... no
checking for socket in -lsocket... no
checking for --with-libs... no
checking for --with-dec-threads... no
checking for --with-threads... yes
checking for mach/cthreads.h... no
checking for --with-pth... no
checking for pthread_create in -lpthread... no
checking for pthread_detach... no
checking for kernel/OS.h... no
checking for pthread_create in -lpthreads... yes
checking for usconfig in -lmpc... no
checking for thr_create in -lthread... no
checking for --with-cycle-gc... yes
checking for --with-libdb... yes
checking for dbopen... no
checking for --with-wctype-functions... no
checking for --with-sgi-dl... no
checking for --with-dl-dld... no
checking for dlopen... yes
checking DYNLOADFILE... dynload_shlib.o
checking for alarm... yes
checking for chown... yes
checking for clock... yes
checking for confstr... yes
checking for ctermid... yes
checking for ctermid_r... no
checking for execv... yes
checking for flock... yes
checking for fork... yes
checking for fsync... yes
checking for fdatasync... yes
checking for fpathconf... yes
checking for ftime... yes
checking for ftruncate... yes
checking for getgroups... yes
checking for getlogin... yes
checking for getpeername... yes
checking for getpid... yes
checking for getpwent... yes
checking for getwd... yes
checking for kill... yes
checking for link... yes
checking for lstat... yes
checking for mkfifo... yes
checking for mktime... yes
checking for mremap... no
checking for nice... yes
checking for pathconf... yes
checking for pause... yes
checking for plock... yes
checking for poll... yes
checking for pthread_init... no
checking for putenv... yes
checking for readlink... yes
checking for select... yes
checking for setegid... yes
checking for seteuid... yes
checking for setgid... yes
checking for setlocale... yes
checking for setregid... yes
checking for setreuid... yes
checking for setsid... yes
checking for setpgid... yes
checking for setuid... yes
checking for setvbuf... yes
checking for sigaction... yes
checking for siginterrupt... yes
checking for sigrelse... yes
checking for strftime... yes
checking for strptime... yes
checking for symlink... yes
checking for sysconf... yes
checking for tcgetpgrp... yes
checking for tcsetpgrp... yes
checking for tempnam... yes
checking for timegm... no
checking for times... yes
checking for tmpfile... yes
checking for tmpnam... yes
checking for tmpnam_r... no
checking for truncate... yes
checking for uname... yes
checking for waitpid... yes
checking for _getpty... no
checking for openpty... yes
checking for forkpty... yes
checking for fseek64... no
checking for fseeko... no
checking for fstatvfs... yes
checking for ftell64... no
checking for ftello... no
checking for statvfs... yes
checking for dup2... yes
checking for getcwd... yes
checking for strdup... yes
checking for strerror... yes
checking for memmove... yes
checking for getpgrp... yes
checking for setpgrp... yes
checking for gettimeofday... yes
checking whether time.h and sys/time.h may both be included... yes
checking whether struct tm is in sys/time.h or time.h... time.h
checking for member tm_zone in aggregate type struct tm... yes
checking for time.h that defines altzone... no
checking whether sys/select.h and sys/time.h may both be included... yes
checking whether char is unsigned... no
checking for working const... yes
checking for inline... __inline
checking for working volatile... yes
checking for working signed char... yes
checking for prototypes... yes
checking for variable length prototypes and stdarg.h... yes
checking for bad exec* prototypes... no
checking for bad static forward... no
checking whether va_list is an array... no
checking for gethostbyname_r... yes
checking gethostbyname_r with 6 args... yes
checking for __fpu_control... no
checking for __fpu_control in -lieee... no
checking for --with-fpectl... no
checking for --with-libm=STRING... default LIBM="-lm"
checking for --with-libc=STRING... default LIBC=""
checking for hypot... yes
checking for genuine getopt... yes
checking what malloc(0) returns... null
checking for wchar.h... yes
checking for usable wchar_t... no
checking whether byte ordering is bigendian... no
checking whether right shift extends the sign bit... yes
checking for socklen_t... no
updating cache ./config.cache
creating ./config.status
creating Makefile
creating Objects/Makefile
creating Parser/Makefile
creating Grammar/Makefile
creating Python/Makefile
creating Modules/Makefile.pre
creating Modules/Setup.config
creating config.h


(cd Modules; make -f Makefile.pre Makefile)
+ cp ./Setup.in Setup 
rm -rf ../libpython2.0.a
/bin/sh ./makesetup Setup.config Setup.local Setup
making Makefile in subdirectory .
`Makefile' is up to date.
making Makefile in subdirectory Parser
`Makefile' is up to date.
making Makefile in subdirectory Grammar
`Makefile' is up to date.
making Makefile in subdirectory Objects
`Makefile' is up to date.
making Makefile in subdirectory Python
`Makefile' is up to date.
making Makefile in subdirectory Modules
`Makefile' is up to date.
(rm -f Modules/hassignal; cd Modules; make hassignal)
rm -f hassignal
for i in threadmodule.o  gcmodule.o  bsddbmodule.o  regexmodule.o regexpr.o  pcremodule.o pypcre.o  posixmodule.o  signalmodule.o  _sre.o  arraymodule.o  cmathmodule.o  mathmodule.o  stropmodule.o  structmodule.o  timemodule.o  operator.o  _codecsmodule.o  unicodedata.o unicodedatabase.o  ucnhash.o  _localemodule.o  fcntlmodule.o  pwdmodule.o  grpmodule.o  errnomodule.o  selectmodule.o  socketmodule.o  mmapmodule.o  md5module.o md5c.o  shamodule.o  rotormodule.o  newmodule.o  binascii.o  parsermodule.o  cStringIO.o  cPickle.o config.o getpath.o main.o getbuildinfo.o; do  if test "$i" = "signalmodule.o"; then  echo yes >hassignal; break;  fi;  done
cd Parser ; make OPT="-O -Olimit 1500" VERSION="2.0"  prefix="/usr/local" exec_prefix="/usr/local" all
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c pgenmain.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c acceler.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c grammar1.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c listnode.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c node.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c parser.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c parsetok.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c tokenizer.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c bitset.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c metagrammar.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c firstsets.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c grammar.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c pgen.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c printgrammar.c
cc -O -Olimit 1500 pgenmain.o acceler.o grammar1.o  listnode.o node.o parser.o  parsetok.o tokenizer.o bitset.o  metagrammar.o firstsets.o grammar.o pgen.o printgrammar.o -lpthreads -o pgen
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c myreadline.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c intrcheck.c
cc: Warning: /usr/include/unistd.h, line 243: The redefinition of the macro "_POSIX_THREADS" conflicts with a current definition because the replacement lists differ.  The redefinition is now in effect.
#define	_POSIX_THREADS		/* 1003.1c (pthreads) comformant */
-------------------------------------------------------------------^
cd Grammar ; make OPT="-O -Olimit 1500" VERSION="2.0"  prefix="/usr/local" exec_prefix="/usr/local" all
../Parser/pgen ./Grammar
Compiling (meta-) parse tree into NFA grammar
Making DFA for 'single_input' ...
Making DFA for 'file_input' ...
Making DFA for 'eval_input' ...
Making DFA for 'funcdef' ...
Making DFA for 'parameters' ...
Making DFA for 'varargslist' ...
Making DFA for 'fpdef' ...
Making DFA for 'fplist' ...
Making DFA for 'stmt' ...
Making DFA for 'simple_stmt' ...
Making DFA for 'small_stmt' ...
Making DFA for 'expr_stmt' ...
Making DFA for 'augassign' ...
Making DFA for 'print_stmt' ...
Making DFA for 'del_stmt' ...
Making DFA for 'pass_stmt' ...
Making DFA for 'flow_stmt' ...
Making DFA for 'break_stmt' ...
Making DFA for 'continue_stmt' ...
Making DFA for 'return_stmt' ...
Making DFA for 'raise_stmt' ...
Making DFA for 'import_stmt' ...
Making DFA for 'import_as_name' ...
Making DFA for 'dotted_as_name' ...
Making DFA for 'dotted_name' ...
Making DFA for 'global_stmt' ...
Making DFA for 'exec_stmt' ...
Making DFA for 'assert_stmt' ...
Making DFA for 'compound_stmt' ...
Making DFA for 'if_stmt' ...
Making DFA for 'while_stmt' ...
Making DFA for 'for_stmt' ...
Making DFA for 'try_stmt' ...
Making DFA for 'except_clause' ...
Making DFA for 'suite' ...
Making DFA for 'test' ...
Making DFA for 'and_test' ...
Making DFA for 'not_test' ...
Making DFA for 'comparison' ...
Making DFA for 'comp_op' ...
Making DFA for 'expr' ...
Making DFA for 'xor_expr' ...
Making DFA for 'and_expr' ...
Making DFA for 'shift_expr' ...
Making DFA for 'arith_expr' ...
Making DFA for 'term' ...
Making DFA for 'factor' ...
Making DFA for 'power' ...
Making DFA for 'atom' ...
Making DFA for 'listmaker' ...
Making DFA for 'lambdef' ...
Making DFA for 'trailer' ...
Making DFA for 'subscriptlist' ...
Making DFA for 'subscript' ...
Making DFA for 'sliceop' ...
Making DFA for 'exprlist' ...
Making DFA for 'testlist' ...
Making DFA for 'dictmaker' ...
Making DFA for 'classdef' ...
Making DFA for 'arglist' ...
Making DFA for 'argument' ...
Making DFA for 'list_iter' ...
Making DFA for 'list_for' ...
Making DFA for 'list_if' ...
Adding FIRST sets ...
Writing graminit.c ...
Writing graminit.h ...
cp graminit.h ./../Include/graminit.h
cp graminit.c ./../Python/graminit.c
cd Objects ; make OPT="-O -Olimit 1500" VERSION="2.0"  prefix="/usr/local" exec_prefix="/usr/local" all
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c abstract.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c bufferobject.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c classobject.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c cobject.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c complexobject.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c fileobject.c
cc: Warning: /usr/include/unistd.h, line 243: The redefinition of the macro "_POSIX_THREADS" conflicts with a current definition because the replacement lists differ.  The redefinition is now in effect.
#define	_POSIX_THREADS		/* 1003.1c (pthreads) comformant */
-------------------------------------------------------------------^
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c floatobject.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c frameobject.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c funcobject.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c intobject.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c listobject.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c longobject.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c dictobject.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c methodobject.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c moduleobject.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c object.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c rangeobject.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c sliceobject.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c stringobject.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c tupleobject.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c typeobject.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c unicodeobject.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c unicodectype.c
cd Python ; make OPT="-O -Olimit 1500" VERSION="2.0"  prefix="/usr/local" exec_prefix="/usr/local" all
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c bltinmodule.c
cc: Warning: /usr/include/unistd.h, line 243: The redefinition of the macro "_POSIX_THREADS" conflicts with a current definition because the replacement lists differ.  The redefinition is now in effect.
#define	_POSIX_THREADS		/* 1003.1c (pthreads) comformant */
-------------------------------------------------------------------^
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c exceptions.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ceval.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c compile.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c codecs.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c errors.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c frozen.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c frozenmain.c
cc: Warning: /usr/include/unistd.h, line 243: The redefinition of the macro "_POSIX_THREADS" conflicts with a current definition because the replacement lists differ.  The redefinition is now in effect.
#define	_POSIX_THREADS		/* 1003.1c (pthreads) comformant */
-------------------------------------------------------------------^
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c getargs.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c getcompiler.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c getcopyright.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c getmtime.c
cc -c -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -DPLATFORM='"osf1V4"'  ./getplatform.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c getversion.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c graminit.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c import.c
cc: Warning: /usr/include/unistd.h, line 243: The redefinition of the macro "_POSIX_THREADS" conflicts with a current definition because the replacement lists differ.  The redefinition is now in effect.
#define	_POSIX_THREADS		/* 1003.1c (pthreads) comformant */
-------------------------------------------------------------------^
cc -c -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -I/ ./importdl.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c marshal.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c modsupport.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c mystrtoul.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c pyfpe.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c pystate.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c pythonrun.c
cc: Warning: /usr/include/unistd.h, line 243: The redefinition of the macro "_POSIX_THREADS" conflicts with a current definition because the replacement lists differ.  The redefinition is now in effect.
#define	_POSIX_THREADS		/* 1003.1c (pthreads) comformant */
-------------------------------------------------------------------^
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c structmember.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c sysmodule.c
cc: Warning: /usr/include/unistd.h, line 243: The redefinition of the macro "_POSIX_THREADS" conflicts with a current definition because the replacement lists differ.  The redefinition is now in effect.
#define	_POSIX_THREADS		/* 1003.1c (pthreads) comformant */
-------------------------------------------------------------------^
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c traceback.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c dynload_shlib.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c thread.c
cc: Warning: /usr/include/unistd.h, line 243: The redefinition of the macro "_POSIX_THREADS" conflicts with a current definition because the replacement lists differ.  The redefinition is now in effect.
#define	_POSIX_THREADS		/* 1003.1c (pthreads) comformant */
-------------------------------------------------------------------^
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c sigcheck.c
cd Modules ; make OPT="-O -Olimit 1500" VERSION="2.0"  prefix="/usr/local" exec_prefix="/usr/local" all
cc  -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./threadmodule.c
cc  -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./gcmodule.c
cc  -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./bsddbmodule.c
cc  -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./regexmodule.c
cc  -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./regexpr.c
cc  -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./pcremodule.c
cc  -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./pypcre.c
cc  -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./posixmodule.c
cc: Warning: /usr/include/unistd.h, line 243: The redefinition of the macro "_POSIX_THREADS" conflicts with a current definition because the replacement lists differ.  The redefinition is now in effect.
#define	_POSIX_THREADS		/* 1003.1c (pthreads) comformant */
-------------------------------------------------------------------^
cc  -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./signalmodule.c
cc: Warning: /usr/include/unistd.h, line 243: The redefinition of the macro "_POSIX_THREADS" conflicts with a current definition because the replacement lists differ.  The redefinition is now in effect.
#define	_POSIX_THREADS		/* 1003.1c (pthreads) comformant */
-------------------------------------------------------------------^
cc  -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./_sre.c
cc  -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./arraymodule.c
cc  -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./cmathmodule.c
cc  -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./mathmodule.c
cc  -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./stropmodule.c
cc  -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./structmodule.c
cc  -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./timemodule.c
cc: Warning: /usr/include/unistd.h, line 243: The redefinition of the macro "_POSIX_THREADS" conflicts with a current definition because the replacement lists differ.  The redefinition is now in effect.
#define	_POSIX_THREADS		/* 1003.1c (pthreads) comformant */
-------------------------------------------------------------------^
cc  -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./operator.c
cc  -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./_codecsmodule.c
cc  -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./unicodedatabase.c
cc  -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./unicodedata.c
cc  -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./ucnhash.c
cc  -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./_localemodule.c
cc  -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./fcntlmodule.c
cc: Warning: /usr/include/unistd.h, line 243: The redefinition of the macro "_POSIX_THREADS" conflicts with a current definition because the replacement lists differ.  The redefinition is now in effect.
#define	_POSIX_THREADS		/* 1003.1c (pthreads) comformant */
-------------------------------------------------------------------^
cc  -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./pwdmodule.c
cc  -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./grpmodule.c
cc  -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./errnomodule.c
cc  -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./selectmodule.c
cc: Warning: /usr/include/unistd.h, line 243: The redefinition of the macro "_POSIX_THREADS" conflicts with a current definition because the replacement lists differ.  The redefinition is now in effect.
#define	_POSIX_THREADS		/* 1003.1c (pthreads) comformant */
-------------------------------------------------------------------^
cc  -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./socketmodule.c
cc: Warning: /usr/include/unistd.h, line 243: The redefinition of the macro "_POSIX_THREADS" conflicts with a current definition because the replacement lists differ.  The redefinition is now in effect.
#define	_POSIX_THREADS		/* 1003.1c (pthreads) comformant */
-------------------------------------------------------------------^
cc  -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./mmapmodule.c
cc: Warning: /usr/include/unistd.h, line 243: The redefinition of the macro "_POSIX_THREADS" conflicts with a current definition because the replacement lists differ.  The redefinition is now in effect.
#define	_POSIX_THREADS		/* 1003.1c (pthreads) comformant */
-------------------------------------------------------------------^
cc  -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./md5module.c
cc  -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./md5c.c
cc  -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./shamodule.c
cc  -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./rotormodule.c
cc  -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./newmodule.c
cc  -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./binascii.c
cc  -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./parsermodule.c
cc  -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./cStringIO.c
cc  -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./cPickle.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c config.c
cc -c -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -DPYTHONPATH='":plat-osf1V4:lib-tk"'  -DPREFIX='"/usr/local"'  -DEXEC_PREFIX='"/usr/local"'  -DVERSION='"2.0"'  -DVPATH='""'  ./getpath.c
cc: Warning: /usr/include/unistd.h, line 243: The redefinition of the macro "_POSIX_THREADS" conflicts with a current definition because the replacement lists differ.  The redefinition is now in effect.
#define	_POSIX_THREADS		/* 1003.1c (pthreads) comformant */
-------------------------------------------------------------------^
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c main.c
cc: Warning: /usr/include/unistd.h, line 243: The redefinition of the macro "_POSIX_THREADS" conflicts with a current definition because the replacement lists differ.  The redefinition is now in effect.
#define	_POSIX_THREADS		/* 1003.1c (pthreads) comformant */
-------------------------------------------------------------------^
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c getbuildinfo.c
if test ! -f libpython2.0.a;  then for i in Parser Grammar Objects Python Modules; do rm -f $i/add2lib; done; true;  else true; fi
for i in Parser Grammar Objects Python Modules; do  (cd $i; make VERSION="2.0" add2lib); done
ar cr ../libpython2.0.a acceler.o grammar1.o  listnode.o node.o parser.o  parsetok.o tokenizer.o bitset.o  metagrammar.o myreadline.o
if test ! -f ../Modules/hassignal;  then echo adding intrcheck.o; ar r ../libpython2.0.a intrcheck.o;  else echo leaving intrcheck.o out; fi
leaving intrcheck.o out
touch add2lib
ar cr ../libpython2.0.a abstract.o bufferobject.o  classobject.o cobject.o complexobject.o  fileobject.o floatobject.o  frameobject.o funcobject.o intobject.o listobject.o  longobject.o dictobject.o methodobject.o  moduleobject.o object.o rangeobject.o  sliceobject.o stringobject.o  tupleobject.o typeobject.o  unicodeobject.o unicodectype.o
touch add2lib
ar cr ../libpython2.0.a bltinmodule.o exceptions.o  ceval.o compile.o codecs.o  errors.o  frozen.o frozenmain.o  getargs.o getcompiler.o getcopyright.o getmtime.o  getplatform.o getversion.o graminit.o  import.o importdl.o  marshal.o modsupport.o mystrtoul.o  pyfpe.o pystate.o pythonrun.o  structmember.o sysmodule.o  traceback.o  dynload_shlib.o  thread.o
if test ! -f ../Modules/hassignal;  then echo adding sigcheck.o; ar r ../libpython2.0.a sigcheck.o;  else echo leaving sigcheck.o out; fi
leaving sigcheck.o out
touch add2lib
if test -f hassignal;  then echo removing sigcheck.o intrcheck.o;  ar d ../libpython2.0.a sigcheck.o intrcheck.o 2>/dev/null;  else echo leaving sigcheck.o intrcheck.o in; fi
removing sigcheck.o intrcheck.o
*** Exit 2 (ignored)
ar cr ../libpython2.0.a threadmodule.o  gcmodule.o  bsddbmodule.o  regexmodule.o regexpr.o  pcremodule.o pypcre.o  posixmodule.o  signalmodule.o  _sre.o  arraymodule.o  cmathmodule.o  mathmodule.o  stropmodule.o  structmodule.o  timemodule.o  operator.o  _codecsmodule.o  unicodedata.o unicodedatabase.o  ucnhash.o  _localemodule.o  fcntlmodule.o  pwdmodule.o  grpmodule.o  errnomodule.o  selectmodule.o  socketmodule.o  mmapmodule.o  md5module.o md5c.o  shamodule.o  rotormodule.o  newmodule.o  binascii.o  parsermodule.o  cStringIO.o  cPickle.o config.o getpath.o main.o getbuildinfo.o
touch add2lib
echo 0 >buildno
cd Modules; make OPT="-O -Olimit 1500" python.o
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c python.c
expr `cat buildno` + 1 >buildno1
mv -f buildno1 buildno
cc -c -O -Olimit 1500 -I. -DHAVE_CONFIG_H -DBUILD=`cat buildno`  ./Modules/getbuildinfo.c
ar cr libpython2.0.a getbuildinfo.o
ranlib libpython2.0.a
true
cd Modules;  make OPT="-O -Olimit 1500" VERSION="2.0"  prefix="/usr/local" exec_prefix="/usr/local"  LIBRARY=../libpython2.0.a link
 cc   python.o  ../libpython2.0.a -ldb                                 -lpthreads -lm  -o python 
ld:
Unresolved:
__pthread_mutex_init
__pthread_mutex_destroy
__pthread_mutex_lock
__pthread_mutex_unlock
__pthread_cond_init
__pthread_cond_destroy
__pthread_cond_signal
__pthread_cond_wait
__pthread_create
__pthread_detach
*** Exit 1
Stop.
*** Exit 1
Stop.


DEC C V5.6-079 on Digital UNIX V4.0 (Rev. 878)
/usr/lib/cmplrs/cc/ld:
	$RCSfile: crt0.s,v $ $Revision: 1.1.21.11 $ (DEC) $Date: 1995/09/06 19:54:27 $
	$RCSfile: ld.c,v $ $Revision: 4.3.123.2 $ (DEC) $Date: 1998/10/06 19:53:55 $
	$RCSfile: doup.c,v $ $Revision: 1.1.3.2 $ (DEC) $Date: 1994/10/20 14:19:31 $
	$RCSfile: pass1.c,v $ $Revision: 4.3.59.5 $ (DEC) $Date: 1997/06/27 15:58:18 $
	$RCSfile: obj_file.c,v $ $Revision: 4.2.38.3 $ (DEC) $Date: 1997/05/06 13:00:05 $
	$RCSfile: file_tbl.c,v $ $Revision: 4.2.38.2 $ (DEC) $Date: 1996/07/08 14:08:20 $
	$RCSfile: fdmap.c,v $ $Revision: 4.2.18.2 $ (DEC) $Date: 1996/07/08 14:08:13 $
	$RCSfile: ext_tbl.c,v $ $Revision: 4.2.80.3 $ (DEC) $Date: 1997/03/17 15:01:44 $
	$RCSfile: extmap.c,v $ $Revision: 4.2.28.2 $ (DEC) $Date: 1996/07/08 14:08:07 $
	$RCSfile: read.c,v $ $Revision: 4.2.64.4 $ (DEC) $Date: 1997/09/30 18:52:59 $
	$RCSfile: read_malloc.c,v $ $Revision: 1.1.44.4 $ (DEC) $Date: 1997/09/30 18:53:01 $
	$RCSfile: layout.c,v $ $Revision: 4.2.111.9 $ (DEC) $Date: 1997/09/12 17:35:22 $
	$RCSfile: relocsym.c,v $ $Revision: 4.2.20.2 $ (DEC) $Date: 1997/02/26 20:47:45 $
	$RCSfile: write.c,v $ $Revision: 4.3.51.3 $ (DEC) $Date: 1996/09/18 17:56:40 $
	$RCSfile: pass2.c,v $ $Revision: 4.3.90.3 $ (DEC) $Date: 1997/03/17 15:03:09 $
	$RCSfile: extlink.c,v $ $Revision: 4.2.7.3 $ (DEC) $Date: 1994/08/05 17:55:56 $
	$RCSfile: tracesym.c,v $ $Revision: 4.2.7.3 $ (DEC) $Date: 1994/08/05 17:59:20 $
	$RCSfile: dn_tbl.c,v $ $Revision: 4.2.7.3 $ (DEC) $Date: 1994/08/05 17:54:50 $
	$RCSfile: dnmap.c,v $ $Revision: 4.2.6.3 $ (DEC) $Date: 1994/09/02 16:10:47 $
	$RCSfile: dynutil.c,v $ $Revision: 4.2.97.2 $ (DEC) $Date: 1998/10/06 19:53:44 $
	$RCSfile: mipscoff.c,v $ $Revision: 4.3.62.3 $ (DEC) $Date: 1997/03/17 15:02:52 $
	$RCSfile: dsoindirect.c,v $ $Revision: 4.2.15.2 $ (DEC) $Date: 1995/02/08 15:21:38 $
	$RCSfile: dsosymbol_table.c,v $ $Revision: 4.3.29.2 $ (DEC) $Date: 1995/10/26 17:16:39 $
	$RCSfile: dsomisc.c,v $ $Revision: 4.2.6.2 $ (DEC) $Date: 1994/08/05 17:55:23 $
	$RCSfile: dsomain.c,v $ $Revision: 4.2.16.3 $ (DEC) $Date: 1994/09/02 16:10:46 $
	$RCSfile: literal.c,v $ $Revision: 4.2.19.2 $ (DEC) $Date: 1995/08/31 18:10:41 $
	$RCSfile: elfhash.c,v $ $Revision: 4.1.25.2 $ (DEC) $Date: 1996/07/08 14:07:40 $
	$RCSfile: register.c,v $ $Revision: 4.2.22.5 $ (DEC) $Date: 1995/05/23 18:46:26 $
	$RCSfile: elf.c,v $ $Revision: 4.3.51.4 $ (DEC) $Date: 1997/05/06 13:00:03 $
	$RCSfile: uldgnum.c,v $ $Revision: 1.1.13.2 $ (DEC) $Date: 1994/10/20 16:22:50 $
	$RCSfile: op.c,v $ $Revision: 1.1.10.2 $ (DEC) $Date: 1994/08/05 17:57:05 $
	$RCSfile: dsoalphainst.c,v $ $Revision: 1.1.13.2 $ (DEC) $Date: 1996/02/02 21:50:45 $
	$RCSfile: alphaop_utils.c,v $ $Revision: 1.1.6.2 $ (DEC) $Date: 1994/08/05 17:54:48 $
	$RCSfile: smap.c,v $ $Revision: 1.1.4.2 $ (DEC) $Date: 1994/08/05 17:59:15 $
	$RCSfile: match.c,v $ $Revision: 4.2.29.3 $ (DEC) $Date: 1997/09/23 18:58:00 $
	$RCSfile: relocate.c,v $ $Revision: 1.1.82.6 $ (DEC) $Date: 1997/09/23 18:58:07 $
	$RCSfile: mgot.c,v $ $Revision: 1.1.46.2 $ (DEC) $Date: 1996/07/08 14:09:29 $
	$RCSfile: gprof.c,v $ $Revision: 1.1.21.2 $ (DEC) $Date: 1996/07/08 14:08:30 $
	$RCSfile: trampoline.c,v $ $Revision: 1.1.23.3 $ (DEC) $Date: 1997/06/20 18:46:07 $
	$RCSfile: gpinfo.c,v $ $Revision: 1.1.11.2 $ (DEC) $Date: 1996/07/08 14:08:23 $
	$RCSfile: stats.c,v $ $Revision: 1.1.8.2 $ (DEC) $Date: 1996/07/08 14:11:02 $
	$RCSfile: obj.c,v $ $Revision: 4.3.48.4 $ (DEC) $Date: 1997/05/29 19:26:42 $
	$RCSfile: wh1.c,v $ $Revision: 1.1.5.5 $ (DEC) $Date: 1995/11/03 18:57:55 $
	$RCSfile: cmrlc_produce.c,v $ $Revision: 1.1.17.3 $ (DEC) $Date: 1997/02/07 20:42:03 $
	$RCSfile: cmrlc_basic.c,v $ $Revision: 1.1.5.2 $ (DEC) $Date: 1995/02/15 16:45:57 $
	$RCSfile: decompresswh1.alpha.s,v $ $Revision: 1.1.2.3 $ (DEC) $Date: 1994/11/15 16:30:26 $
	$RCSfile: allocate.c,v $ $Revision: 1.1.3.3 $ (DEC) $Date: 1994/05/25 19:19:04 $
	$RCSfile: cmrlc_heur.c,v $ $Revision: 1.1.6.2 $ (DEC) $Date: 1995/09/07 17:18:18 $
	$RCSfile: ldgetname.c,v $ $Revision: 4.3.5.2 $ (DEC) $Date: 1994/05/26 18:09:48 $
	$RCSfile: scncomment.c,v $ $Revision: 4.1.12.2 $ (DEC) $Date: 1994/05/04 20:03:47 $
	$RCSfile: lderr.c,v $ $Revision: 1.1.2.2 $ (DEC) $Date: 1995/11/29 19:43:44 $
	$RCSfile: exit.c,v $ $Revision: 4.2.13.8 $ (DEC) $Date: 1996/04/22 20:54:54 $
	$RCSfile: signal.c,v $ $Revision: 4.3.9.2 $ (DEC) $Date: 1995/09/12 17:44:41 $
	$RCSfile: flsbuf.c,v $ $Revision: 4.2.15.2 $ (DEC) $Date: 1996/09/18 19:45:36 $
	$RCSfile: fopen.c,v $ $Revision: 4.2.11.3 $ (DEC) $Date: 1995/06/12 20:40:14 $
	$RCSfile: fprintf.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/04/04 21:28:13 $
	$RCSfile: scanf.c,v $ $Revision: 4.2.10.2 $ (DEC) $Date: 1994/04/05 15:45:13 $
	$RCSfile: printf.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/04/05 15:26:18 $
	$RCSfile: sprintf.c,v $ $Revision: 4.2.13.3 $ (DEC) $Date: 1995/12/14 23:46:41 $
	$RCSfile: fgets.c,v $ $Revision: 4.2.10.2 $ (DEC) $Date: 1994/11/23 20:11:27 $
	$RCSfile: NLSsetup.c,v $ $Revision: 1.1.13.7 $ (DEC) $Date: 1996/01/15 23:46:55 $
	$RCSfile: atoi.c,v $ $Revision: 4.2.10.2 $ (DEC) $Date: 1994/11/07 19:18:55 $
	$RCSfile: atol.c,v $ $Revision: 4.2.10.2 $ (DEC) $Date: 1994/11/07 19:19:01 $
	$RCSfile: malloc.c,v $ $Revision: 4.2.59.2 $ (DEC) $Date: 1998/04/09 14:55:23 $
	$RCSfile: system.c,v $ $Revision: 4.3.13.2 $ (DEC) $Date: 1994/08/03 14:34:15 $
	$RCSfile: strncmp.c,v $ $Revision: 4.2.11.4 $ (DEC) $Date: 1994/04/20 16:56:44 $
	$RCSfile: errlst.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/11/23 19:19:49 $
	$RCSfile: calloc.c,v $ $Revision: 4.2.8.3 $ (DEC) $Date: 1994/04/05 21:09:32 $
	$RCSfile: strncpy.c,v $ $Revision: 4.2.7.2 $ (DEC) $Date: 1994/04/05 15:48:58 $
	$RCSfile: abort.c,v $ $Revision: 4.2.11.3 $ (DEC) $Date: 1995/06/12 20:38:42 $
	$RCSfile: vfprintf.c,v $ $Revision: 4.2.7.2 $ (DEC) $Date: 1994/04/05 16:15:00 $
	$RCSfile: sysconf.c,v $ $Revision: 4.3.27.2 $ (DEC) $Date: 1996/12/03 21:50:05 $
	$RCSfile: qsort.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/11/23 19:23:30 $
	$RCSfile: filbuf.c,v $ $Revision: 4.2.13.3 $ (DEC) $Date: 1995/06/12 20:39:59 $
	$RCSfile: isspace.c,v $ $Revision: 4.2.8.3 $ (DEC) $Date: 1994/05/31 18:13:48 $
	$RCSfile: time.c,v $ $Revision: 4.2.7.2 $ (DEC) $Date: 1994/04/05 16:12:12 $
	$RCSfile: strncat.c,v $ $Revision: 4.2.10.2 $ (DEC) $Date: 1996/02/16 21:06:27 $
	$RCSfile: Ustrtok.c,v $ $Revision: 1.1.2.2 $ (DEC) $Date: 1994/11/23 19:18:34 $
	$RCSfile: strtok.c,v $ $Revision: 4.2.7.2 $ (DEC) $Date: 1994/04/05 15:49:33 $
	$RCSfile: strtol.c,v $ $Revision: 4.3.13.2 $ (DEC) $Date: 1994/08/03 14:33:56 $
	$RCSfile: fseek.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/04/04 21:28:42 $
	$RCSfile: ftell.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/04/04 21:28:58 $
	$RCSfile: strcspn.c,v $ $Revision: 4.2.7.2 $ (DEC) $Date: 1994/04/05 15:48:25 $
	$RCSfile: cfork.c,v $ $Revision: 1.1.3.7 $ (DEC) $Date: 1996/01/24 16:16:02 $
	$RCSfile: brks.c,v $ $Revision: 1.1.2.4 $ (DEC) $Date: 1995/08/30 19:21:18 $
	$RCSfile: nano_timers.c,v $ $Revision: 4.3.14.3 $ (DEC) $Date: 1995/06/12 20:42:02 $
	$RCSfile: assert.c,v $ $Revision: 4.2.9.3 $ (DEC) $Date: 1994/04/05 21:09:04 $
	$RCSfile: mktemp.c,v $ $Revision: 4.2.10.2 $ (DEC) $Date: 1995/08/29 17:56:51 $
	$RCSfile: fread.c,v $ $Revision: 4.3.12.3 $ (DEC) $Date: 1995/07/28 14:53:14 $
	$RCSfile: strdup.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/11/23 19:24:39 $
	$RCSfile: strcasecmp.c,v $ $Revision: 4.2.11.2 $ (DEC) $Date: 1994/11/10 14:57:27 $
	$RCSfile: a64l.c,v $ $Revision: 4.2.9.6 $ (DEC) $Date: 1995/06/28 16:00:16 $
	$RCSfile: sigops.c,v $ $Revision: 4.2.10.2 $ (DEC) $Date: 1994/04/05 15:47:12 $
	$RCSfile: tis.c,v $ $Revision: 1.1.14.5 $ (DEC) $Date: 1997/05/02 19:32:15 $
	$RCSfile: init_libc.c,v $ $Revision: 1.1.32.2 $ (DEC) $Date: 1998/08/06 21:11:39 $
	$RCSfile: ldr_atexit.c,v $ $Revision: 4.2.17.2 $ (DEC) $Date: 1998/03/23 20:01:58 $
	$RCSfile: write_nc.c,v $ $Revision: 1.1.7.2 $ (DEC) $Date: 1997/09/23 14:15:37 $
	$RCSfile: close_nc.c,v $ $Revision: 1.1.7.2 $ (DEC) $Date: 1997/09/23 14:15:32 $
	$RCSfile: isatty.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/04/04 21:44:10 $
	$RCSfile: tis_pthread.c,v $ $Revision: 1.1.5.3 $ (DEC) $Date: 1996/12/18 20:37:50 $
	$RCSfile: open_nc.c,v $ $Revision: 1.1.7.2 $ (DEC) $Date: 1997/09/23 14:15:33 $
	$RCSfile: findiop.c,v $ $Revision: 4.2.12.4 $ (DEC) $Date: 1995/06/12 20:40:02 $
	$RCSfile: doprnt.c,v $ $Revision: 4.2.58.2 $ (DEC) $Date: 1998/07/29 16:22:47 $
	$RCSfile: doscan.c,v $ $Revision: 4.3.40.2 $ (DEC) $Date: 1998/06/15 20:58:58 $
	$RCSfile: ecvt.c,v $ $Revision: 4.2.19.2 $ (DEC) $Date: 1996/04/17 17:50:54 $
	$RCSfile: errno.c,v $ $Revision: 1.1.8.4 $ (DEC) $Date: 1994/04/05 22:09:26 $
	$RCSfile: mallocdata.c,v $ $Revision: 1.1.4.4 $ (DEC) $Date: 1996/02/08 19:08:30 $
	$RCSfile: waitpid.c,v $ $Revision: 4.2.9.3 $ (DEC) $Date: 1995/10/30 21:48:36 $
	$RCSfile: raise.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1995/10/27 19:40:45 $
	$RCSfile: siglist.c,v $ $Revision: 4.2.9.3 $ (DEC) $Date: 1995/02/08 22:02:42 $
	$RCSfile: read_nc.c,v $ $Revision: 1.1.7.2 $ (DEC) $Date: 1997/09/23 14:15:35 $
	$RCSfile: iswctype.c,v $ $Revision: 1.1.12.2 $ (DEC) $Date: 1994/11/23 19:21:20 $
	$RCSfile: strspn.c,v $ $Revision: 4.2.7.2 $ (DEC) $Date: 1994/04/05 15:49:15 $
	$RCSfile: strpbrk.c,v $ $Revision: 4.2.7.2 $ (DEC) $Date: 1994/04/05 15:49:04 $
	$RCSfile: atfork.c,v $ $Revision: 1.1.2.4 $ (DEC) $Date: 1995/08/25 20:52:45 $
	$RCSfile: catopen.c,v $ $Revision: 4.3.18.5 $ (DEC) $Date: 1995/09/25 21:03:54 $
	$RCSfile: catgets.c,v $ $Revision: 4.2.10.3 $ (DEC) $Date: 1994/04/05 21:09:37 $
	$RCSfile: rec_mutex.c,v $ $Revision: 1.1.8.2 $ (DEC) $Date: 1997/06/24 19:15:05 $
	$RCSfile: sleep.c,v $ $Revision: 4.2.9.5 $ (DEC) $Date: 1995/10/31 15:54:41 $
	$RCSfile: schyield.s,v $ $Revision: 1.1.2.2 $ (DEC) $Date: 1995/09/27 17:08:25 $
	$RCSfile: tis_rwlock.c,v $ $Revision: 1.1.5.2 $ (DEC) $Date: 1996/12/03 20:38:25 $
	$RCSfile: ldr_dummy.c,v $ $Revision: 4.2.15.2 $ (DEC) $Date: 1997/10/13 21:06:11 $
	$RCSfile: ldr_status.c,v $ $Revision: 4.2.8.3 $ (DEC) $Date: 1994/04/05 15:05:50 $
	$RCSfile: sched_yield.c,v $ $Revision: 1.1.2.2 $ (DEC) $Date: 1995/11/16 21:59:12 $
	$RCSfile: Ufwrite.c,v $ $Revision: 1.1.2.2 $ (DEC) $Date: 1994/11/23 20:11:24 $
	$RCSfile: fwrite.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/11/23 20:11:38 $
	$RCSfile: __getmbcurmax.c,v $ $Revision: 1.1.7.2 $ (DEC) $Date: 1994/04/05 16:51:10 $
	$RCSfile: wcstombs.c,v $ $Revision: 4.2.7.3 $ (DEC) $Date: 1994/05/31 18:15:14 $
	$RCSfile: wctomb.c,v $ $Revision: 4.2.11.2 $ (DEC) $Date: 1997/07/15 17:35:42 $
	$RCSfile: localeconv.c,v $ $Revision: 4.2.7.3 $ (DEC) $Date: 1994/05/31 18:14:20 $
	$RCSfile: wcslen.c,v $ $Revision: 4.2.9.3 $ (DEC) $Date: 1995/03/09 18:40:34 $
	$RCSfile: mblen.c,v $ $Revision: 4.2.7.3 $ (DEC) $Date: 1994/05/31 18:14:22 $
	$RCSfile: mbtowc.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1995/02/09 15:37:35 $
	$RCSfile: strtod.c,v $ $Revision: 4.2.15.3 $ (DEC) $Date: 1994/08/16 20:01:29 $
	$RCSfile: strtoul.c,v $ $Revision: 4.2.12.2 $ (DEC) $Date: 1994/08/03 14:34:11 $
	$RCSfile: strstr.c,v $ $Revision: 4.2.7.2 $ (DEC) $Date: 1994/04/05 15:49:20 $
	$RCSfile: ungetwc.c,v $ $Revision: 4.2.12.3 $ (DEC) $Date: 1995/05/04 20:48:07 $
	$RCSfile: setlocale.c,v $ $Revision: 4.4.18.4 $ (DEC) $Date: 1995/04/27 20:15:29 $
	$RCSfile: getenv.c,v $ $Revision: 4.2.11.4 $ (DEC) $Date: 1995/06/12 20:40:24 $
	$RCSfile: basename.c,v $ $Revision: 4.2.12.2 $ (DEC) $Date: 1996/09/16 19:39:28 $
	$RCSfile: __ispriv.c,v $ $Revision: 1.1.9.2 $ (DEC) $Date: 1995/09/25 21:03:53 $
	$RCSfile: bsearch.c,v $ $Revision: 4.2.6.3 $ (DEC) $Date: 1994/04/05 21:09:30 $
	$RCSfile: __mbtopc.c,v $ $Revision: 1.1.7.4 $ (DEC) $Date: 1994/05/31 18:12:22 $
	$RCSfile: __lc_load.c,v $ $Revision: 1.1.9.2 $ (DEC) $Date: 1994/11/10 14:56:05 $
	$RCSfile: __lc_dlopen.c,v $ $Revision: 1.1.2.6 $ (DEC) $Date: 1995/06/12 20:38:38 $
	$RCSfile: __lc_dlsym.c,v $ $Revision: 1.1.2.5 $ (DEC) $Date: 1995/06/12 20:38:40 $
	$RCSfile: setjmp_incl.s,v $ $Revision: 1.1.4.5 $ (DEC) $Date: 1994/05/13 18:07:02 $
	$RCSfile: alpha_unwind.c,v $ $Revision: 1.1.19.6 $ (DEC) $Date: 1997/08/04 17:50:22 $
	$RCSfile: ldr_load.c,v $ $Revision: 1.1.3.5 $ (DEC) $Date: 1995/04/28 14:20:17 $
	$RCSfile: tzset.c,v $ $Revision: 1.1.24.2 $ (DEC) $Date: 1997/08/04 17:11:53 $
	$RCSfile: perror.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/04/05 15:25:26 $
	$RCSfile: fputs.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/11/23 20:11:33 $
	 habitat_id = realtime_12:1991
	$RCSfile: allocator.c,v $ $Revision: 1.1.2.2 $ (DEC) $Date: 1992/12/03 19:08:59 $
	$RCSfile: nmach_user.c,v $ $Revision: 4.2.2.2 $ (DEC) $Date: 1993/01/15 18:03:56 $
	$RCSfile: mach_error.c,v $ $Revision: 4.2 $ (DEC) $Date: 1991/09/20 04:10:59 $
	$RCSfile: msg.c,v $ $Revision: 4.2.2.2 $ (DEC) $Date: 93/03/02 16:10:03 $
	$RCSfile: mig_support.c,v $ $Revision: 4.2 $ (DEC) $Date: 1991/09/20 04:11:14 $
	$RCSfile: mach_init.c,v $ $Revision: 4.2.6.2 $ (DEC) $Date: 1995/07/11 20:50:08 $
/usr/lib/cmplrs/cc/ftoc:
	$RCSfile: crt0.s,v $ $Revision: 1.1.21.11 $ (DEC) $Date: 1995/09/06 19:54:27 $
	$RCSfile: exit.c,v $ $Revision: 4.2.13.8 $ (DEC) $Date: 1996/04/22 20:54:54 $
	$RCSfile: fread.c,v $ $Revision: 4.3.12.3 $ (DEC) $Date: 1995/07/28 14:53:14 $
	$RCSfile: flsbuf.c,v $ $Revision: 4.2.17.2 $ (DEC) $Date: 1996/10/07 18:02:48 $
	$RCSfile: fopen.c,v $ $Revision: 4.2.11.3 $ (DEC) $Date: 1995/06/12 20:40:14 $
	$RCSfile: fprintf.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/04/04 21:28:13 $
	$RCSfile: printf.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/04/05 15:26:18 $
	$RCSfile: perror.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/04/05 15:25:26 $
	$RCSfile: qsort.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/11/23 19:23:30 $
	$RCSfile: malloc.c,v $ $Revision: 4.2.47.3 $ (DEC) $Date: 1997/06/17 14:20:56 $
	$RCSfile: sigops.c,v $ $Revision: 4.2.10.2 $ (DEC) $Date: 1994/04/05 15:47:12 $
	$RCSfile: tis.c,v $ $Revision: 1.1.14.5 $ (DEC) $Date: 1997/05/02 19:32:15 $
	$RCSfile: init_libc.c,v $ $Revision: 1.1.21.3 $ (DEC) $Date: 1997/03/06 18:54:43 $
	$RCSfile: ldr_atexit.c,v $ $Revision: 4.2.11.4 $ (DEC) $Date: 1995/06/12 20:41:35 $
	$RCSfile: filbuf.c,v $ $Revision: 4.2.13.3 $ (DEC) $Date: 1995/06/12 20:39:59 $
	$RCSfile: tis_pthread.c,v $ $Revision: 1.1.5.3 $ (DEC) $Date: 1996/12/18 20:37:50 $
	$RCSfile: write_nc.c,v $ $Revision: 1.1.7.2 $ (DEC) $Date: 1997/09/23 14:15:37 $
	$RCSfile: close_nc.c,v $ $Revision: 1.1.7.2 $ (DEC) $Date: 1997/09/23 14:15:32 $
	$RCSfile: isatty.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/04/04 21:44:10 $
	$RCSfile: open_nc.c,v $ $Revision: 1.1.7.2 $ (DEC) $Date: 1997/09/23 14:15:33 $
	$RCSfile: findiop.c,v $ $Revision: 4.2.12.4 $ (DEC) $Date: 1995/06/12 20:40:02 $
	$RCSfile: doprnt.c,v $ $Revision: 4.2.43.3 $ (DEC) $Date: 1997/09/26 15:41:30 $
	$RCSfile: errlst.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/11/23 19:19:49 $
	$RCSfile: catopen.c,v $ $Revision: 4.3.18.5 $ (DEC) $Date: 1995/09/25 21:03:54 $
	$RCSfile: catgets.c,v $ $Revision: 4.2.10.3 $ (DEC) $Date: 1994/04/05 21:09:37 $
	$RCSfile: sprintf.c,v $ $Revision: 4.2.13.3 $ (DEC) $Date: 1995/12/14 23:46:41 $
	$RCSfile: abort.c,v $ $Revision: 4.2.11.3 $ (DEC) $Date: 1995/06/12 20:38:42 $
	$RCSfile: brks.c,v $ $Revision: 1.1.2.4 $ (DEC) $Date: 1995/08/30 19:21:18 $
	$RCSfile: mallocdata.c,v $ $Revision: 1.1.4.4 $ (DEC) $Date: 1996/02/08 19:08:30 $
	$RCSfile: sleep.c,v $ $Revision: 4.2.9.5 $ (DEC) $Date: 1995/10/31 15:54:41 $
	$RCSfile: schyield.s,v $ $Revision: 1.1.2.2 $ (DEC) $Date: 1995/09/27 17:08:25 $
	$RCSfile: calloc.c,v $ $Revision: 4.2.8.3 $ (DEC) $Date: 1994/04/05 21:09:32 $
	$RCSfile: tis_rwlock.c,v $ $Revision: 1.1.5.2 $ (DEC) $Date: 1996/12/03 20:38:25 $
	$RCSfile: ldr_dummy.c,v $ $Revision: 4.2.15.2 $ (DEC) $Date: 1997/10/13 21:06:11 $
	$RCSfile: ldr_status.c,v $ $Revision: 4.2.8.3 $ (DEC) $Date: 1994/04/05 15:05:50 $
	$RCSfile: read_nc.c,v $ $Revision: 1.1.7.2 $ (DEC) $Date: 1997/09/23 14:15:35 $
	$RCSfile: Ufwrite.c,v $ $Revision: 1.1.2.2 $ (DEC) $Date: 1994/11/23 20:11:24 $
	$RCSfile: fwrite.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/11/23 20:11:38 $
	$RCSfile: __getmbcurmax.c,v $ $Revision: 1.1.7.2 $ (DEC) $Date: 1994/04/05 16:51:10 $
	$RCSfile: wcstombs.c,v $ $Revision: 4.2.7.3 $ (DEC) $Date: 1994/05/31 18:15:14 $
	$RCSfile: wctomb.c,v $ $Revision: 4.2.11.2 $ (DEC) $Date: 1997/07/15 17:35:42 $
	$RCSfile: ecvt.c,v $ $Revision: 4.2.21.2 $ (DEC) $Date: 1996/06/28 16:44:57 $
	$RCSfile: localeconv.c,v $ $Revision: 4.2.7.3 $ (DEC) $Date: 1994/05/31 18:14:20 $
	$RCSfile: NLSsetup.c,v $ $Revision: 1.1.13.7 $ (DEC) $Date: 1996/01/15 23:46:55 $
	$RCSfile: wcslen.c,v $ $Revision: 4.2.9.3 $ (DEC) $Date: 1995/03/09 18:40:34 $
	$RCSfile: setlocale.c,v $ $Revision: 4.4.18.4 $ (DEC) $Date: 1995/04/27 20:15:29 $
	$RCSfile: getenv.c,v $ $Revision: 4.2.11.4 $ (DEC) $Date: 1995/06/12 20:40:24 $
	$RCSfile: errno.c,v $ $Revision: 1.1.8.4 $ (DEC) $Date: 1994/04/05 22:09:26 $
	$RCSfile: strdup.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/11/23 19:24:39 $
	$RCSfile: basename.c,v $ $Revision: 4.2.12.2 $ (DEC) $Date: 1996/09/16 19:39:28 $
	$RCSfile: __ispriv.c,v $ $Revision: 1.1.9.2 $ (DEC) $Date: 1995/09/25 21:03:53 $
	$RCSfile: bsearch.c,v $ $Revision: 4.2.6.3 $ (DEC) $Date: 1994/04/05 21:09:30 $
	$RCSfile: raise.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1995/10/27 19:40:45 $
	$RCSfile: time.c,v $ $Revision: 4.2.7.2 $ (DEC) $Date: 1994/04/05 16:12:12 $
	$RCSfile: strncpy.c,v $ $Revision: 4.2.7.2 $ (DEC) $Date: 1994/04/05 15:48:58 $
	$RCSfile: strncat.c,v $ $Revision: 4.2.10.2 $ (DEC) $Date: 1996/02/16 21:06:27 $
	$RCSfile: __lc_load.c,v $ $Revision: 1.1.9.2 $ (DEC) $Date: 1994/11/10 14:56:05 $
	$RCSfile: __lc_dlopen.c,v $ $Revision: 1.1.2.6 $ (DEC) $Date: 1995/06/12 20:38:38 $
	$RCSfile: __lc_dlsym.c,v $ $Revision: 1.1.2.5 $ (DEC) $Date: 1995/06/12 20:38:40 $
	$RCSfile: ldr_load.c,v $ $Revision: 1.1.3.5 $ (DEC) $Date: 1995/04/28 14:20:17 $
	$RCSfile: tzset.c,v $ $Revision: 1.1.24.2 $ (DEC) $Date: 1997/08/04 17:11:53 $
	$RCSfile: assert.c,v $ $Revision: 4.2.9.3 $ (DEC) $Date: 1994/04/05 21:09:04 $
/usr/lib/cmplrs/cc/cord:
	$RCSfile: crt0.s,v $ $Revision: 1.1.21.11 $ (DEC) $Date: 1995/09/06 19:54:27 $
	$RCSfile: ldgetpd.c,v $ $Revision: 4.3.6.2 $ (DEC) $Date: 1995/01/25 20:38:36 $
	$RCSfile: cmrlc_produce.c,v $ $Revision: 1.1.17.3 $ (DEC) $Date: 1997/02/07 20:42:03 $
	$RCSfile: cmrlc_basic.c,v $ $Revision: 1.1.5.2 $ (DEC) $Date: 1995/02/15 16:45:57 $
	$RCSfile: cmrlc_consume.c,v $ $Revision: 1.1.11.2 $ (DEC) $Date: 1995/06/21 19:46:04 $
	$RCSfile: lderr.c,v $ $Revision: 1.1.2.2 $ (DEC) $Date: 1995/11/29 19:43:44 $
	$RCSfile: obj.c,v $ $Revision: 4.3.48.4 $ (DEC) $Date: 1997/05/29 19:26:42 $
	$RCSfile: allocate.c,v $ $Revision: 1.1.3.3 $ (DEC) $Date: 1994/05/25 19:19:04 $
	$RCSfile: ldgetname.c,v $ $Revision: 4.3.5.2 $ (DEC) $Date: 1994/05/26 18:09:48 $
	$RCSfile: cmrlc_heur.c,v $ $Revision: 1.1.6.2 $ (DEC) $Date: 1995/09/07 17:18:18 $
	$RCSfile: scncomment.c,v $ $Revision: 4.1.12.2 $ (DEC) $Date: 1994/05/04 20:03:47 $
	$RCSfile: wh1.c,v $ $Revision: 1.1.5.5 $ (DEC) $Date: 1995/11/03 18:57:55 $
	$RCSfile: decompresswh1.alpha.s,v $ $Revision: 1.1.2.3 $ (DEC) $Date: 1994/11/15 16:30:26 $
	$RCSfile: exit.c,v $ $Revision: 4.2.13.8 $ (DEC) $Date: 1996/04/22 20:54:54 $
	$RCSfile: assert.c,v $ $Revision: 4.2.9.3 $ (DEC) $Date: 1994/04/05 21:09:04 $
	$RCSfile: strncmp.c,v $ $Revision: 4.2.11.4 $ (DEC) $Date: 1994/04/20 16:56:44 $
	$RCSfile: strdup.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/11/23 19:24:39 $
	$RCSfile: fread.c,v $ $Revision: 4.3.12.3 $ (DEC) $Date: 1995/07/28 14:53:14 $
	$RCSfile: fwrite.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/11/23 20:11:38 $
	$RCSfile: flsbuf.c,v $ $Revision: 4.2.17.2 $ (DEC) $Date: 1996/10/07 18:02:48 $
	$RCSfile: fopen.c,v $ $Revision: 4.2.11.3 $ (DEC) $Date: 1995/06/12 20:40:14 $
	$RCSfile: fprintf.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/04/04 21:28:13 $
	$RCSfile: printf.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/04/05 15:26:18 $
	$RCSfile: sprintf.c,v $ $Revision: 4.2.13.3 $ (DEC) $Date: 1995/12/14 23:46:41 $
	$RCSfile: vfprintf.c,v $ $Revision: 4.2.7.2 $ (DEC) $Date: 1994/04/05 16:15:00 $
	$RCSfile: fgets.c,v $ $Revision: 4.2.10.2 $ (DEC) $Date: 1994/11/23 20:11:27 $
	$RCSfile: fseek.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/04/04 21:28:42 $
	$RCSfile: ftell.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/04/04 21:28:58 $
	$RCSfile: fdopen.c,v $ $Revision: 4.2.9.3 $ (DEC) $Date: 1994/04/05 22:09:55 $
	$RCSfile: atoi.c,v $ $Revision: 4.2.10.2 $ (DEC) $Date: 1994/11/07 19:18:55 $
	$RCSfile: malloc.c,v $ $Revision: 4.2.47.3 $ (DEC) $Date: 1997/06/17 14:20:56 $
	$RCSfile: calloc.c,v $ $Revision: 4.2.8.3 $ (DEC) $Date: 1994/04/05 21:09:32 $
	$RCSfile: qsort.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/11/23 19:23:30 $
	$RCSfile: abort.c,v $ $Revision: 4.2.11.3 $ (DEC) $Date: 1995/06/12 20:38:42 $
	$RCSfile: time.c,v $ $Revision: 4.2.7.2 $ (DEC) $Date: 1994/04/05 16:12:12 $
	$RCSfile: atol.c,v $ $Revision: 4.2.10.2 $ (DEC) $Date: 1994/11/07 19:19:01 $
	$RCSfile: strcspn.c,v $ $Revision: 4.2.7.2 $ (DEC) $Date: 1994/04/05 15:48:25 $
	$RCSfile: strncpy.c,v $ $Revision: 4.2.7.2 $ (DEC) $Date: 1994/04/05 15:48:58 $
	$RCSfile: a64l.c,v $ $Revision: 4.2.9.6 $ (DEC) $Date: 1995/06/28 16:00:16 $
	$RCSfile: signal.c,v $ $Revision: 4.3.9.2 $ (DEC) $Date: 1995/09/12 17:44:41 $
	$RCSfile: mktemp.c,v $ $Revision: 4.2.10.2 $ (DEC) $Date: 1995/08/29 17:56:51 $
	$RCSfile: brks.c,v $ $Revision: 1.1.2.4 $ (DEC) $Date: 1995/08/30 19:21:18 $
	$RCSfile: NLSsetup.c,v $ $Revision: 1.1.13.7 $ (DEC) $Date: 1996/01/15 23:46:55 $
	$RCSfile: strcasecmp.c,v $ $Revision: 4.2.11.2 $ (DEC) $Date: 1994/11/10 14:57:27 $
	$RCSfile: sigops.c,v $ $Revision: 4.2.10.2 $ (DEC) $Date: 1994/04/05 15:47:12 $
	$RCSfile: tis.c,v $ $Revision: 1.1.14.5 $ (DEC) $Date: 1997/05/02 19:32:15 $
	$RCSfile: init_libc.c,v $ $Revision: 1.1.21.3 $ (DEC) $Date: 1997/03/06 18:54:43 $
	$RCSfile: ldr_atexit.c,v $ $Revision: 4.2.11.4 $ (DEC) $Date: 1995/06/12 20:41:35 $
	$RCSfile: catopen.c,v $ $Revision: 4.3.18.5 $ (DEC) $Date: 1995/09/25 21:03:54 $
	$RCSfile: catgets.c,v $ $Revision: 4.2.10.3 $ (DEC) $Date: 1994/04/05 21:09:37 $
	$RCSfile: write_nc.c,v $ $Revision: 1.1.7.2 $ (DEC) $Date: 1997/09/23 14:15:37 $
	$RCSfile: filbuf.c,v $ $Revision: 4.2.13.3 $ (DEC) $Date: 1995/06/12 20:39:59 $
	$RCSfile: tis_pthread.c,v $ $Revision: 1.1.5.3 $ (DEC) $Date: 1996/12/18 20:37:50 $
	$RCSfile: close_nc.c,v $ $Revision: 1.1.7.2 $ (DEC) $Date: 1997/09/23 14:15:32 $
	$RCSfile: isatty.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/04/04 21:44:10 $
	$RCSfile: open_nc.c,v $ $Revision: 1.1.7.2 $ (DEC) $Date: 1997/09/23 14:15:33 $
	$RCSfile: findiop.c,v $ $Revision: 4.2.12.4 $ (DEC) $Date: 1995/06/12 20:40:02 $
	$RCSfile: doprnt.c,v $ $Revision: 4.2.43.3 $ (DEC) $Date: 1997/09/26 15:41:30 $
	$RCSfile: ecvt.c,v $ $Revision: 4.2.21.2 $ (DEC) $Date: 1996/06/28 16:44:57 $
	$RCSfile: errno.c,v $ $Revision: 1.1.8.4 $ (DEC) $Date: 1994/04/05 22:09:26 $
	$RCSfile: fcntl_nc.c,v $ $Revision: 1.1.2.2 $ (DEC) $Date: 1995/10/30 21:48:23 $
	$RCSfile: mallocdata.c,v $ $Revision: 1.1.4.4 $ (DEC) $Date: 1996/02/08 19:08:30 $
	$RCSfile: raise.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1995/10/27 19:40:45 $
	$RCSfile: rec_mutex.c,v $ $Revision: 1.1.8.2 $ (DEC) $Date: 1997/06/24 19:15:05 $
	$RCSfile: sleep.c,v $ $Revision: 4.2.9.5 $ (DEC) $Date: 1995/10/31 15:54:41 $
	$RCSfile: schyield.s,v $ $Revision: 1.1.2.2 $ (DEC) $Date: 1995/09/27 17:08:25 $
	$RCSfile: tis_rwlock.c,v $ $Revision: 1.1.5.2 $ (DEC) $Date: 1996/12/03 20:38:25 $
	$RCSfile: ldr_dummy.c,v $ $Revision: 4.2.15.2 $ (DEC) $Date: 1997/10/13 21:06:11 $
	$RCSfile: ldr_status.c,v $ $Revision: 4.2.8.3 $ (DEC) $Date: 1994/04/05 15:05:50 $
	$RCSfile: setlocale.c,v $ $Revision: 4.4.18.4 $ (DEC) $Date: 1995/04/27 20:15:29 $
	$RCSfile: getenv.c,v $ $Revision: 4.2.11.4 $ (DEC) $Date: 1995/06/12 20:40:24 $
	$RCSfile: basename.c,v $ $Revision: 4.2.12.2 $ (DEC) $Date: 1996/09/16 19:39:28 $
	$RCSfile: __ispriv.c,v $ $Revision: 1.1.9.2 $ (DEC) $Date: 1995/09/25 21:03:53 $
	$RCSfile: bsearch.c,v $ $Revision: 4.2.6.3 $ (DEC) $Date: 1994/04/05 21:09:30 $
	$RCSfile: read_nc.c,v $ $Revision: 1.1.7.2 $ (DEC) $Date: 1997/09/23 14:15:35 $
	$RCSfile: Ufwrite.c,v $ $Revision: 1.1.2.2 $ (DEC) $Date: 1994/11/23 20:11:24 $
	$RCSfile: fwrite.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/11/23 20:11:38 $
	$RCSfile: __getmbcurmax.c,v $ $Revision: 1.1.7.2 $ (DEC) $Date: 1994/04/05 16:51:10 $
	$RCSfile: wcstombs.c,v $ $Revision: 4.2.7.3 $ (DEC) $Date: 1994/05/31 18:15:14 $
	$RCSfile: wctomb.c,v $ $Revision: 4.2.11.2 $ (DEC) $Date: 1997/07/15 17:35:42 $
	$RCSfile: localeconv.c,v $ $Revision: 4.2.7.3 $ (DEC) $Date: 1994/05/31 18:14:20 $
	$RCSfile: wcslen.c,v $ $Revision: 4.2.9.3 $ (DEC) $Date: 1995/03/09 18:40:34 $
	$RCSfile: strncat.c,v $ $Revision: 4.2.10.2 $ (DEC) $Date: 1996/02/16 21:06:27 $
	$RCSfile: __lc_load.c,v $ $Revision: 1.1.9.2 $ (DEC) $Date: 1994/11/10 14:56:05 $
	$RCSfile: __lc_dlopen.c,v $ $Revision: 1.1.2.6 $ (DEC) $Date: 1995/06/12 20:38:38 $
	$RCSfile: __lc_dlsym.c,v $ $Revision: 1.1.2.5 $ (DEC) $Date: 1995/06/12 20:38:40 $
	$RCSfile: ldr_load.c,v $ $Revision: 1.1.3.5 $ (DEC) $Date: 1995/04/28 14:20:17 $
	$RCSfile: tzset.c,v $ $Revision: 1.1.24.2 $ (DEC) $Date: 1997/08/04 17:11:53 $
	 ldtbread.c: 1.1 1/7/82
/usr/lib/cmplrs/cc/crt0.o:
	$RCSfile: crt0.s,v $ $Revision: 1.1.21.11 $ (DEC) $Date: 1995/09/06 19:54:27 $
cc  (cc)
	Digital UNIX Compiler Driver 3.11




From effbot at telia.com  Mon Oct 23 19:44:49 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Mon, 23 Oct 2000 19:44:49 +0200
Subject: [Python-Dev] FYI: ajuba solutions (formerly scriptics) acquired by interwoven
Message-ID: <003201c03d18$f384a5c0$3c6340d5@hagrid>

looks like Tcl's parent company has ceased to be:

    http://biz.yahoo.com/bw/001020/ca_interwo.html

    "The Ajuba team will be assimilated into Interwoven's
    existing technical staff much as the Neonyoyo team
    was immediately after its acquisition in June. The Ajuba
    product line will be discontinued."

</F>




From guido at python.org  Mon Oct 23 22:12:49 2000
From: guido at python.org (Guido van Rossum)
Date: Mon, 23 Oct 2000 15:12:49 -0500
Subject: [Python-Dev] Starship down ?
In-Reply-To: Your message of "Mon, 23 Oct 2000 15:35:40 +0200."
             <39F43EAC.1A518A27@lemburg.com> 
References: <39F43EAC.1A518A27@lemburg.com> 
Message-ID: <200010232012.PAA12261@cj20424-a.reston1.va.home.com>

> The starship.python.net server seems to be down. Could someone
> with sysadmin access please fix this ?!

Yeah, this is very unfortunate.  It's the same problem that's keeping
pytholabs.com down.  The BeOpen systems staff is working on it, but I
don't know what the problem is or when it will be fixed.

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



From esr at thyrsus.com  Mon Oct 23 21:40:16 2000
From: esr at thyrsus.com (Eric S. Raymond)
Date: Mon, 23 Oct 2000 15:40:16 -0400
Subject: [Python-Dev] FYI: ajuba solutions (formerly scriptics) acquired by interwoven
In-Reply-To: <003201c03d18$f384a5c0$3c6340d5@hagrid>; from effbot@telia.com on Mon, Oct 23, 2000 at 07:44:49PM +0200
References: <003201c03d18$f384a5c0$3c6340d5@hagrid>
Message-ID: <20001023154016.A2722@thyrsus.com>

Fredrik Lundh <effbot at telia.com>:
> looks like Tcl's parent company has ceased to be:

This raises anew a question I've been meaning to bring up for the last
week: is it finally time to move away from Python's dependence on
Tcl/Tk for GUI support?

It seems to me that the Tcl world has been in increasing disarray for
the last two years.  Its growth doesn't seem to have matched Perl's or
Python's; no strong community site analogous to python.org or CPAN has
emerged; and John Osterhout's attempt to commercialize the language
have led to a series of false starts and erratic moves.  And Osterhout
cheerfully acknowledges that on a technical level that Tcl has been
pushed past the natural limits of applicability for its design
approach.  

Tcl's long-term prognosis looks, to me, increasingly poor.  Which suggests
to me that some move toqwards making Python less dependent on Tk would be
a good thing.

I understand that we can't simply drop Tkinter.  But I think it might be worth
another look at alternatives (notably wxPython) to consider bringing one
into the core distribution during 2.x, so that later on we can plan to
move Tk to "unsupported -- legacy".
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

You need only reflect that one of the best ways to get yourself 
a reputation as a dangerous citizen these days is to go about 
repeating the very phrases which our founding fathers used in the 
great struggle for independence.
	-- Attributed to Charles Austin Beard (1874-1948)



From guido at python.org  Mon Oct 23 23:08:13 2000
From: guido at python.org (Guido van Rossum)
Date: Mon, 23 Oct 2000 16:08:13 -0500
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: Your message of "Mon, 23 Oct 2000 15:40:16 -0400."
             <20001023154016.A2722@thyrsus.com> 
References: <003201c03d18$f384a5c0$3c6340d5@hagrid>  
            <20001023154016.A2722@thyrsus.com> 
Message-ID: <200010232108.QAA12524@cj20424-a.reston1.va.home.com>

[ESR]
> This raises anew a question I've been meaning to bring up for the last
> week: is it finally time to move away from Python's dependence on
> Tcl/Tk for GUI support?
> 
> It seems to me that the Tcl world has been in increasing disarray for
> the last two years.  Its growth doesn't seem to have matched Perl's or
> Python's; no strong community site analogous to python.org or CPAN has
> emerged; and John Osterhout's attempt to commercialize the language
> have led to a series of false starts and erratic moves.  And Osterhout
> cheerfully acknowledges that on a technical level that Tcl has been
> pushed past the natural limits of applicability for its design
> approach.  
> 
> Tcl's long-term prognosis looks, to me, increasingly poor.  Which
> suggests to me that some move toqwards making Python less dependent
> on Tk would be a good thing.
> 
> I understand that we can't simply drop Tkinter.  But I think it
> might be worth another look at alternatives (notably wxPython) to
> consider bringing one into the core distribution during 2.x, so that
> later on we can plan to move Tk to "unsupported -- legacy".

Yes, it may be time to have this discussion again.

Of course, Tcl/Tk still has a much larger following than wxWindows,
and it is more stable too.  (For example, it's easy to cause crashes
-- not just exceptions -- by leaving out an initialization call in
wxPython.)

Plus, Tk has two very high quality widgets: the Canvas and Text
widgets are unsurpassed in functionality and robustness by other
widget sets.  You can draw more lines or characters per second in most
toolkits, but few toolkits offer the convenience of marks and tags,
not having to deal with refresh events, being able to group objects,
move them around, change attributes, etc., etc., etc.

The Scintilla text widget comes close (and surpasses Tkinter in some
respects, while coming short in others), but I know of no widget in a
popular widget set that offers anything close to the Canvas widget.

There are other choices too, all of which have Python support already:
gtk, qt, and the Mozilla toolkit (whose name I forget -- maybe David
Ascher can fill me in).

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



From akuchlin at mems-exchange.org  Mon Oct 23 22:21:18 2000
From: akuchlin at mems-exchange.org (Andrew Kuchling)
Date: Mon, 23 Oct 2000 16:21:18 -0400
Subject: [Python-Dev] FYI: ajuba solutions (formerly scriptics) acquired by interwoven
In-Reply-To: <20001023154016.A2722@thyrsus.com>; from esr@thyrsus.com on Mon, Oct 23, 2000 at 03:40:16PM -0400
References: <003201c03d18$f384a5c0$3c6340d5@hagrid> <20001023154016.A2722@thyrsus.com>
Message-ID: <20001023162118.B18005@kronos.cnri.reston.va.us>

Fredrik Lundh <effbot at telia.com> wrote:
> looks like Tcl's parent company has ceased to be:

I checked out comp.lang.tcl after hearing about this.  Ousterhout
posted to say that an official statement will be coming out today or
tomorrow, so I wouldn't conclude that Tcl is dead just yet; we'll see
what he says the core team is going to do...

On Mon, Oct 23, 2000 at 03:40:16PM -0400, Eric S. Raymond wrote:
>This raises anew a question I've been meaning to bring up for the last
>week: is it finally time to move away from Python's dependence on
>Tcl/Tk for GUI support?

It seems to me that supporting MacOS is the big problem for
cross-platform GUIs.  There are several different systems such as Qt
that aim for portability across Windows and Unix, but add in the MacOS
and the options really decrease.  How good is wxWindows support for
MacOS?

Or will MacOS X fix the problem?  I know MacOS X uses a BSD-based
underlying kernel, but don't know if it will support X Windows out of
the box.  If people can only use MacOS-specific GUI APIs, then
software such as Tk would still need to be ported specially to MacOS X.

--amk



From akuchlin at mems-exchange.org  Mon Oct 23 22:30:11 2000
From: akuchlin at mems-exchange.org (Andrew Kuchling)
Date: Mon, 23 Oct 2000 16:30:11 -0400
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: <200010232108.QAA12524@cj20424-a.reston1.va.home.com>; from guido@python.org on Mon, Oct 23, 2000 at 04:08:13PM -0500
References: <003201c03d18$f384a5c0$3c6340d5@hagrid> <20001023154016.A2722@thyrsus.com> <200010232108.QAA12524@cj20424-a.reston1.va.home.com>
Message-ID: <20001023163011.C18005@kronos.cnri.reston.va.us>

On Mon, Oct 23, 2000 at 04:08:13PM -0500, Guido van Rossum wrote:
>The Scintilla text widget comes close (and surpasses Tkinter in some
>respects, while coming short in others), but I know of no widget in a
>popular widget set that offers anything close to the Canvas widget.

I believe the GNOME (not GTk's, but GNOME's) canvas widget began as a
fork of the Tk widget that was then substantially enhanced to be a
general-purpose display engine, with antialiasing, alpha compositing,
more attention to performance, and other fancy features.  I don't know
if the corresponding text widget (which is Pango, www.pango.org, I
think) is equally featureful.

--amk



From gvwilson at nevex.com  Mon Oct 23 22:33:48 2000
From: gvwilson at nevex.com (Greg Wilson)
Date: Mon, 23 Oct 2000 16:33:48 -0400 (EDT)
Subject: [Python-Dev] Re: ajuba solutions (formerly scriptics) acquired by interwoven
In-Reply-To: <20001023154016.A2722@thyrsus.com>
Message-ID: <Pine.LNX.4.10.10010231624060.31805-100000@akbar.nevex.com>

> Fredrik Lundh <effbot at telia.com>:
> > looks like Tcl's parent company has ceased to be:

> Eric Raymond:
> This raises anew a question I've been meaning to bring up for the last week:
> is it finally time to move away from Python's dependence on Tcl/Tk for GUI
> support?

Yes please.

> It seems to me that the Tcl world has been in increasing disarray for the
> last two years.  Its growth doesn't seem to have matched Perl's or Python's;
> no strong community site analogous to python.org or CPAN has emerged;

I have been told by two different publishers that they can't even give Tcl books
away any longer.  It's also interesting that the new Ruby book from Hunt and
Thomas clearly positions Ruby as an alternative to Python, rather than Tcl or
Perl (I saw three mentions in the first ten minutes of the fact that Ruby is
more widely used in Japan than Python).  Also interesting that the Ruby GUI
toolkit they describe is Tk-based...

> I understand that we can't simply drop Tkinter.  But I think it might be
> worth another look at alternatives (notably wxPython) to consider bringing
> one into the core distribution during 2.x, so that later on we can plan to
> move Tk to "unsupported -- legacy".

I thought about using wxPython in the most recent run of my Python course, but
decided to stick to Tkinter because:

- There isn't a wxWindows/wxPython book (matters a lot when organizations are
  trying to decide what to adopt for long-term use).

- Tkinter came packaged with the 1.5.2 installer, wxPython didn't.

- There aren't as many tools on top of wxPython as there are on top of Tkinter.
  In particular, I think that a vector drawing package on top of wxPython that
  did what Sketch does, but on Windows as well as Linux, would make a great
  subject for a book on Python, non-trivial OO, and HCI (hint, hint...)

Thanks,
Greg




From effbot at telia.com  Mon Oct 23 23:02:58 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Mon, 23 Oct 2000 23:02:58 +0200
Subject: [Python-Dev] FYI: ajuba solutions (formerly scriptics) acquired by interwoven
References: <003201c03d18$f384a5c0$3c6340d5@hagrid> <20001023154016.A2722@thyrsus.com> <20001023162118.B18005@kronos.cnri.reston.va.us>
Message-ID: <001e01c03d34$d11bd5f0$3c6340d5@hagrid>

andrew wrote:
> I checked out comp.lang.tcl after hearing about this.  Ousterhout
> posted to say that an official statement will be coming out today or
> tomorrow, so I wouldn't conclude that Tcl is dead just yet; we'll see
> what he says the core team is going to do...

from an open-source perspective, Tcl might be more alive
than ever:

http://sourceforge.net/projects/tcl
http://sourceforge.net/projects/tktoolkit

and trust me, the Python 2.0/Tk8.4/Tkinter3000 combo
will rock ;-)

</F>




From esr at thyrsus.com  Mon Oct 23 23:15:03 2000
From: esr at thyrsus.com (Eric S. Raymond)
Date: Mon, 23 Oct 2000 17:15:03 -0400
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: <200010232108.QAA12524@cj20424-a.reston1.va.home.com>; from guido@python.org on Mon, Oct 23, 2000 at 04:08:13PM -0500
References: <003201c03d18$f384a5c0$3c6340d5@hagrid> <20001023154016.A2722@thyrsus.com> <200010232108.QAA12524@cj20424-a.reston1.va.home.com>
Message-ID: <20001023171503.B2889@thyrsus.com>

Guido van Rossum <guido at python.org>:
> There are other choices too, all of which have Python support already:
> gtk, qt, and the Mozilla toolkit (whose name I forget -- maybe David
> Ascher can fill me in).

I'm glad you brought up GTK+.  Of all the alternatives you mentioned,
it seems to me the most likely to attract long-term cross-platform
support by lots of developers (GNOME, Nautilus and Sun Microsystems
seem like a tough trio to beat on this score).  Thus, GTK+ may be be
the safest alternative in terms of being least likely to strand us N
years down the road.

The GTK+ API seems like a nice clean design, and there is already a Python
binding.  Any comment from anybody on how stable it is?  Are the text and
canvas widgets anywhere near competitive with Tk's?  There are hints
of a wxWindows-based port to Windows on the GTK+ site; is there a Mac port?
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

.. a government and its agents are under no general duty to 
provide public services, such as police protection, to any 
particular individual citizen...
        -- Warren v. District of Columbia, 444 A.2d 1 (D.C. App.181)



From trentm at ActiveState.com  Mon Oct 23 23:06:41 2000
From: trentm at ActiveState.com (Trent Mick)
Date: Mon, 23 Oct 2000 14:06:41 -0700
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: <200010232108.QAA12524@cj20424-a.reston1.va.home.com>; from guido@python.org on Mon, Oct 23, 2000 at 04:08:13PM -0500
References: <003201c03d18$f384a5c0$3c6340d5@hagrid> <20001023154016.A2722@thyrsus.com> <200010232108.QAA12524@cj20424-a.reston1.va.home.com>
Message-ID: <20001023140641.A3899@ActiveState.com>

On Mon, Oct 23, 2000 at 04:08:13PM -0500, Guido van Rossum wrote:
> There are other choices too, all of which have Python support already:
...
> and the Mozilla toolkit (whose name I forget -- maybe David
> Ascher can fill me in).

XUL. Though slappin' a GUI together in XUL is not all the same as for
the other toolkits. Layout with XML, functionality with JavaScript and Python
(and/or Perl of C++).


Trent


-- 
Trent Mick
TrentM at ActiveState.com



From effbot at telia.com  Mon Oct 23 23:33:02 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Mon, 23 Oct 2000 23:33:02 +0200
Subject: [Python-Dev] FYI: ajuba solutions (formerly scriptics) acquired by interwoven
References: <003201c03d18$f384a5c0$3c6340d5@hagrid> <20001023154016.A2722@thyrsus.com> <20001023162118.B18005@kronos.cnri.reston.va.us>
Message-ID: <004201c03d38$d4836e20$3c6340d5@hagrid>

andrew wrote:
> I checked out comp.lang.tcl after hearing about this.  Ousterhout
> posted to say that an official statement will be coming out today or
> tomorrow, so I wouldn't conclude that Tcl is dead just yet; we'll see
> what he says the core team is going to do...

they just updated their site:

http://www.ajubasolutions.com/company/whatsnew.html

    "Tcl is not a core technology at Interwoven, and
    Interwoven will not invest in the development of
    Tcl. However, Ajuba has transferred responsibility
    for Tcl core development to the newly formed Tcl
    Core Team /.../ We expect the Tcl Core Team to
    evolve Tcl at a much faster rate than any single
    organization could achieve by itself. 

    "Over the next few weeks Ajuba will release in open-
    source form many of the Tcl packages that we deve-
    loped for our products. Stay tuned for more info...

</F>




From akuchlin at mems-exchange.org  Mon Oct 23 23:26:18 2000
From: akuchlin at mems-exchange.org (Andrew Kuchling)
Date: Mon, 23 Oct 2000 17:26:18 -0400
Subject: [Python-Dev] Re: ajuba acquired by interwoven
In-Reply-To: <Pine.LNX.4.10.10010231624060.31805-100000@akbar.nevex.com>; from gvwilson@nevex.com on Mon, Oct 23, 2000 at 04:33:48PM -0400
References: <20001023154016.A2722@thyrsus.com> <Pine.LNX.4.10.10010231624060.31805-100000@akbar.nevex.com>
Message-ID: <20001023172618.A23898@kronos.cnri.reston.va.us>

Some details begin to emerge at 
http://www.ajubasolutions.com/company/whatsnew.html

It looks like some of their proprietary code will be released as open
source, possibly including the TclPro development environment.  The
new company will not be funding Tcl/Tk development, and instead it's
up to the 14 members of the recently-formed Tcl core team.  I don't
know if any of those people are being paid to work on Tcl, but
probably at least some of them are.  I expect this will cause a good
deal disruption, perhaps even a fatal amount, particularly if core
developers such as Jeffrey Hobbs no longer work on Tcl full-time.

--amk



From esr at thyrsus.com  Mon Oct 23 23:58:20 2000
From: esr at thyrsus.com (Eric S. Raymond)
Date: Mon, 23 Oct 2000 17:58:20 -0400
Subject: [Python-Dev] Re: ajuba acquired by interwoven
In-Reply-To: <20001023172618.A23898@kronos.cnri.reston.va.us>; from akuchlin@mems-exchange.org on Mon, Oct 23, 2000 at 05:26:18PM -0400
References: <20001023154016.A2722@thyrsus.com> <Pine.LNX.4.10.10010231624060.31805-100000@akbar.nevex.com> <20001023172618.A23898@kronos.cnri.reston.va.us>
Message-ID: <20001023175820.A3117@thyrsus.com>

Andrew Kuchling <akuchlin at mems-exchange.org>:
> Some details begin to emerge at 
> http://www.ajubasolutions.com/company/whatsnew.html
> 
> It looks like some of their proprietary code will be released as open
> source, possibly including the TclPro development environment.  The
> new company will not be funding Tcl/Tk development, and instead it's
> up to the 14 members of the recently-formed Tcl core team.  I don't
> know if any of those people are being paid to work on Tcl, but
> probably at least some of them are.  I expect this will cause a good
> deal disruption, perhaps even a fatal amount, particularly if core
> developers such as Jeffrey Hobbs no longer work on Tcl full-time.

Not necessarily...

Good for Tcl: they *have* a core team now

Bad for Tcl: at 14 it's too big, unless there's some inner core of no
	more than three or four architects.

Good for Tcl: Much of the proprietary code will go open.

Bad for Tcl: Not clear whether the two Ajuba employees "replaced" are
		on the new core team. Not clear whether their time 
		available will increase or decrease.

Good for Tcl: Osterhout's rather lame attempts to develop under a mixed 
		model have almost certainly come to an end in favor of
		an Apache-like model funded by big Tcl users.

With good leadership, they could manage the transition to something
resembling the Apache Software Foundation's organization.  If so, Tcl
might actually improve.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Rifles, muskets, long-bows and hand-grenades are inherently democratic
weapons.  A complex weapon makes the strong stronger, while a simple
weapon -- so long as there is no answer to it -- gives claws to the
weak.
        -- George Orwell, "You and the Atom Bomb", 1945



From robin at alldunn.com  Tue Oct 24 01:03:44 2000
From: robin at alldunn.com (Robin Dunn)
Date: Mon, 23 Oct 2000 16:03:44 -0700
Subject: [Python-Dev] Re: ajuba solutions (formerly scriptics) acquired by interwoven
References: <Pine.LNX.4.10.10010231624060.31805-100000@akbar.nevex.com>
Message-ID: <036501c03d45$81aefae0$3225d2d1@ARES>

I'm not on python-dev so please be sure to copy me on replies.


"Greg Wilson" <gvwilson at nevex.com> wrote:
>
> I thought about using wxPython in the most recent run of my Python course,
but
> decided to stick to Tkinter because:
>
> - There isn't a wxWindows/wxPython book (matters a lot when organizations
are
>   trying to decide what to adopt for long-term use).
>

This is something I am hoping to change in the near future.  I have a lot of
ideas, have been putting an outline together, and have a phone conference
with a potential publisher tomorrow.

> - Tkinter came packaged with the 1.5.2 installer, wxPython didn't.
>
> - There aren't as many tools on top of wxPython as there are on top of
Tkinter.
>   In particular, I think that a vector drawing package on top of wxPython
that
>   did what Sketch does, but on Windows as well as Linux, would make a
great
>   subject for a book on Python, non-trivial OO, and HCI (hint, hint...)

Hint received and understood...


"Andrew Kuchling" akuchlin at mems-exchange.org wrote:
>
> It seems to me that supporting MacOS is the big problem for
> cross-platform GUIs.  There are several different systems such as Qt
> that aim for portability across Windows and Unix, but add in the MacOS
> and the options really decrease.  How good is wxWindows support for
> MacOS?

My understanding is that the version in CVS is nearly up to date with the
features in the MSW and GTK versions, though I haven't had a chance to use
it myself.  It's in use in at least a few commercial applications around the
world.

The next step I guess is getting it wrapped up in wxPython, which should
just be a matter of porting some of the low level startup and helper code,
and putting some ifdef's in the SWIG interface files for things that may be
different in the Mac version of wxWindows.  Unfortunately, given the current
state of the amount of my spare time and relative Mac-illiterate-ness, it's
either going to require someone else to work on it and be wxPython-Mac's
champion, or somebody needs to fund my ramp-up and development time so I can
cut back on other things.  The good news is that I have been loaned a Mac
and CodeWarior and such to play with, I just haven't found the time to play
much lately.



"Guido van Rossum" guido at python.org wrote:
> Plus, Tk has two very high quality widgets: the Canvas and Text
> widgets are unsurpassed in functionality and robustness by other
> widget sets.  You can draw more lines or characters per second in most
> toolkits, but few toolkits offer the convenience of marks and tags,
> not having to deal with refresh events, being able to group objects,
> move them around, change attributes, etc., etc., etc.
>
> The Scintilla text widget comes close (and surpasses Tkinter in some
> respects, while coming short in others),

Just in case anybody didn't know already, wxWindows/wxPython has a wrapper
around Scintilla available called wxStyledTextCtrl.

> but I know of no widget in a
> popular widget set that offers anything close to the Canvas widget.

wxWindows has a canvas widget in development right now.  I've been trying to
nudge the developers working on it towards features found in the tk canvas
and the GNOME canvas widget.  I have high hopes for it but I'm not sure how
long it will be before it gets to the same level as the others.


--
Robin Dunn
Software Craftsman
robin at AllDunn.com
http://wxPython.org     Java give you jitters?
http://wxPROs.com        Relax with wxPython!





From esr at thyrsus.com  Tue Oct 24 01:29:54 2000
From: esr at thyrsus.com (Eric S. Raymond)
Date: Mon, 23 Oct 2000 19:29:54 -0400
Subject: [Python-Dev] Re: ajuba solutions (formerly scriptics) acquired by interwoven
In-Reply-To: <036501c03d45$81aefae0$3225d2d1@ARES>; from robin@alldunn.com on Mon, Oct 23, 2000 at 04:03:44PM -0700
References: <Pine.LNX.4.10.10010231624060.31805-100000@akbar.nevex.com> <036501c03d45$81aefae0$3225d2d1@ARES>
Message-ID: <20001023192954.A3313@thyrsus.com>

Robin Dunn <robin at alldunn.com>:
>                                      Unfortunately, given the current
> state of the amount of my spare time and relative Mac-illiterate-ness, it's
> either going to require someone else to work on it and be wxPython-Mac's
> champion, or somebody needs to fund my ramp-up and development time so I can
> cut back on other things.

This is exactly what CoSource and SourceXchange are for.  Post your Mac port
as a project there and see who ponies up money.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

  "...quemadmodum gladius neminem occidit, occidentis telum est."
[...a sword never kills anybody; it's a tool in the killer's hand.]
        -- (Lucius Annaeus) Seneca "the Younger" (ca. 4 BC-65 AD),



From MarkH at ActiveState.com  Tue Oct 24 01:19:33 2000
From: MarkH at ActiveState.com (Mark Hammond)
Date: Tue, 24 Oct 2000 10:19:33 +1100
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: <20001023140641.A3899@ActiveState.com>
Message-ID: <ECEPKNMJLHAPFFJHDOJBMEJGDOAA.MarkH@ActiveState.com>

Trimmed all CCs

[Guido]
> and the Mozilla toolkit (whose name I forget -- maybe David
> Ascher can fill me in).

[Trent "David Ascher" Mick responds]
> XUL. Though slappin' a GUI together in XUL is not all the same as for
> the other toolkits. Layout with XML, functionality with
> JavaScript and Python (and/or Perl of C++).

As a fairly irrelevant (at this point in time) observation:

Something about the Mozilla XUL engine seems "right".  It is large and
complex, but their XML based layout engine, and powerful "code-less" widget
creation has a lot of potential IMO.

It is very very new and rough.  It is very tightly bound with Mozilla
itself and javascript, although efforts are underway to separate it from
both.  It is huge, and constantly changing.  It has been designed for
tomorrow, and struggles along today.  But it may well turn out to be and
expressive and compelling model for the future.

So, if we can just continue to disagree for the next 2 or 3 years, it may
well become something worth considering ;-)

Mark.




From robin at alldunn.com  Tue Oct 24 01:56:59 2000
From: robin at alldunn.com (Robin Dunn)
Date: Mon, 23 Oct 2000 16:56:59 -0700
Subject: [Python-Dev] Re: ajuba solutions (formerly scriptics) acquired by interwoven
References: <Pine.LNX.4.10.10010231624060.31805-100000@akbar.nevex.com> <036501c03d45$81aefae0$3225d2d1@ARES> <20001023192954.A3313@thyrsus.com>
Message-ID: <038601c03d4c$ef14f1f0$3225d2d1@ARES>

>
> This is exactly what CoSource and SourceXchange are for.  Post your Mac
port
> as a project there and see who ponies up money.

Now why didn't I think of that???  Thanks for the idea!

--
Robin Dunn
Software Craftsman
robin at AllDunn.com
http://wxPython.org     Java give you jitters?
http://wxPROs.com        Relax with wxPython!





From DavidA at ActiveState.com  Tue Oct 24 06:00:51 2000
From: DavidA at ActiveState.com (David Ascher)
Date: Mon, 23 Oct 2000 21:00:51 -0700 (Pacific Daylight Time)
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: <200010232108.QAA12524@cj20424-a.reston1.va.home.com>
Message-ID: <Pine.WNT.4.21.0010231545180.1476-100000@loom>

> The Scintilla text widget comes close (and surpasses Tkinter in some
> respects, while coming short in others), but I know of no widget in a
> popular widget set that offers anything close to the Canvas widget.
> 
> There are other choices too, all of which have Python support already:
> gtk, qt, and the Mozilla toolkit (whose name I forget -- maybe David
> Ascher can fill me in).

The mozilla toolkits has more names than I care to remember.  =)  The most
generic name is XPFE, although there are some parts of it with nicer names
like XUL (pronounced Zool) and XBL.  It also heavily uses XML, DTDs, CSS,
etc.

Mozilla is definitely a long-term investment in our part.  For example,
currently it's not possible to have Python code inline in the XUL
(XML) code, and JavaScript is the only option there.  We'll be working w/
the Netscape and Mozilla crowds to fix that, but it's not there yet.

That said, Mozilla does have a fairly strong vision for the future, allows
some of the benefits of the web technologies to transfer to the GUI world
(designers, not coders, can do the UI work).

In terms of the closest equivalent to the Canvas widget, apart from XUL
itself, which is very hierarchical, there is the promise of SVG support,
which will give you a lot more than the Canvas.  That, too, is not quite
ready for prime time yet.

Hope this is helpful,

--david





From cgw at fnal.gov  Tue Oct 24 06:32:04 2000
From: cgw at fnal.gov (Charles G Waldman)
Date: Mon, 23 Oct 2000 23:32:04 -0500 (CDT)
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: <Pine.WNT.4.21.0010231545180.1476-100000@loom>
References: <200010232108.QAA12524@cj20424-a.reston1.va.home.com>
	<Pine.WNT.4.21.0010231545180.1476-100000@loom>
Message-ID: <14837.4292.807070.848419@buffalo.fnal.gov>

David Ascher writes:
 > 
 > That said, Mozilla does have a fairly strong vision for the future, allows
 > some of the benefits of the web technologies to transfer to the GUI world
 > (designers, not coders, can do the UI work).

Sounds great for the future, but I want to inject a few of my
unsolicated, opinionated observations - today, in 2000, the Mozilla
stuff is *far* from usable.  If you want to produce nice, professional
looking GUI apps which fit nicely with the desktop (rather that having
their own completely different look-and-feel) it's hard to beat Gtk+
or Tkinter.  Tkinter is still quite viable, especially if
cross-plaform support is important.  Some of the examples in Grayson's
book are quite beautiful.  It will be a long time until
XPFE/XUL/whatchamacallit gets to this level of viability.

Also consider that Sun (and HP?) now ship Gnome by default, rather
than CDE (or so I hear, anyway).  I predict that Gnome compatibility
will become more and more of a desirable feature.

Evidence of the above is the "Galeon" project.  It's widely perceived
that Mozilla has a nice rendering engine (Gecko) wrapped up in a
dreadful GUI (XPFE).  So the Galeon project places the Gecko engine
inside a Gtk+/Gnome GUI, which provides a much more pleasant user
experience.

There's also a (preliminary) port of Gtk+ to Win32:
http://www.gimp.org/~tml/gimp/win32/

And, finally, IMO, the work being done on PyGtk is of high quality.
I'm using it currently in production code.



From DavidA at ActiveState.com  Tue Oct 24 07:12:14 2000
From: DavidA at ActiveState.com (David Ascher)
Date: Mon, 23 Oct 2000 22:12:14 -0700 (Pacific Daylight Time)
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: <14837.4292.807070.848419@buffalo.fnal.gov>
Message-ID: <Pine.WNT.4.21.0010232209570.612-100000@cr469175-a>

> There's also a (preliminary) port of Gtk+ to Win32:
> http://www.gimp.org/~tml/gimp/win32/

FWIW, the last time I checked, this was useless.  I'd be glad to be wrong,
but I'm not holding my breath.  Not surprisingly, the GTK crowd, which is
rooted in Linux tradition (!), has little interest in Win32 ports, and
even less experience in that world.  Until that happens, a lot of
platform-agnostic projects and vendors will have a hard time w/ GTK.

I don't mean to diss GTK, just pointing out that cross-platform solutions
are important to a whole lot of communities (Python included).

--david




From tim_one at email.msn.com  Tue Oct 24 07:20:07 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Tue, 24 Oct 2000 01:20:07 -0400
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: <200010232108.QAA12524@cj20424-a.reston1.va.home.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCEEIAHMAA.tim_one@email.msn.com>

[ESR]
> ...
> and John Osterhout's attempt to commercialize the language have led to
> a series of false starts and erratic moves.

We don't want to criticize anyone for that:  PythonLabs' attempts *not* to
commercialize Python may yet make Tcl's path look as straight and true as a
laser beam <blink>.

obliquely y'rs  - tim





From tim_one at email.msn.com  Tue Oct 24 07:31:07 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Tue, 24 Oct 2000 01:31:07 -0400
Subject: [Python-Dev] Starship down ?
In-Reply-To: <200010232012.PAA12261@cj20424-a.reston1.va.home.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCAEIBHMAA.tim_one@email.msn.com>

[MAL]
> The starship.python.net server seems to be down. Could someone
> with sysadmin access please fix this ?!

[GvR]
> Yeah, this is very unfortunate.  It's the same problem that's keeping
> pytholabs.com down.  The BeOpen systems staff is working on it, but I
> don't know what the problem is or when it will be fixed.

FYI, pythonlabs.com is up again, but Starship is still down.  We only said
it's the same problem because we didn't know what either problem was.  And,
we still don't!

long-distance-ly y'rs  - tim





From cgw at fnal.gov  Tue Oct 24 07:34:23 2000
From: cgw at fnal.gov (Charles G Waldman)
Date: Tue, 24 Oct 2000 00:34:23 -0500 (CDT)
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: <Pine.WNT.4.21.0010232209570.612-100000@cr469175-a>
References: <14837.4292.807070.848419@buffalo.fnal.gov>
	<Pine.WNT.4.21.0010232209570.612-100000@cr469175-a>
Message-ID: <14837.8031.342286.639052@buffalo.fnal.gov>

David Ascher writes:

 >cgw> There's also a (preliminary) port of Gtk+ to Win32:
 >cgw> http://www.gimp.org/~tml/gimp/win32/
 > 
 > FWIW, the last time I checked, this was useless.

That's what I meant by "preliminary" ;-)

 > I don't mean to diss GTK, just pointing out that cross-platform solutions
 > are important to a whole lot of communities (Python included).

Right.  Cross-platform is very important, but so is native
look-and-feel, and this is where (IMO) XPFE falls flat on its face.
Something like WxWindows, which uses Gtk+ on *nix and MFC (?) on Win,
seems like it could be a real winner.  If the x-platform GUI doesn't
use native dialog boxes and filechoosers, users REALLY notice this and
they will just hate it.  (Yes, this is based on observations of actual
paying customers).

I have a little bit of experience with cross-platform development -
having used a lot of these tools - at my last job, after evaluating
just about everything, we bought into (against my advice!) a doomed
commercial product called Visix Galaxy (for which I immediately
created a set of Python bindings).  The problem with all of these
things, of course, is that the more cross-platform they are, the more
"lowest-common-denominator" they are forced to become.

Tkinter, with widgets like Canvas, was really pretty amazing - for its
day - feature-rich *and x-platform.  But even this broke down if you
started using fancy features like drawing with dashed lines - works on
X, not on Windows (last time I checked, anyway) - the more you start
pushing the limits of the toolkit, the more the portability breaks
down.

Tkinter-is-dead-long-live-Tkinter'ly yrs, 
				     -C



From MarkH at ActiveState.com  Tue Oct 24 07:48:34 2000
From: MarkH at ActiveState.com (Mark Hammond)
Date: Tue, 24 Oct 2000 16:48:34 +1100
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: <14837.8031.342286.639052@buffalo.fnal.gov>
Message-ID: <ECEPKNMJLHAPFFJHDOJBEEKEDOAA.MarkH@ActiveState.com>

> Right.  Cross-platform is very important, but so is native
> look-and-feel, and this is where (IMO) XPFE falls flat on its face.

Actually, my experience with XPFE from a look-and-feel POV has been pretty
positive.  It is true they have re-implemented most widgets rather than use
native ones, and also true that you can make these widgets look nothing
like native LAF - but generally, my experience with Mozilla and the
"classic" skin is that it is close enough that it is very hard to tell.  It
looks more like "subtle enhancements", in the same way IE provides "subtle
enhancements"

> seems like it could be a real winner.  If the x-platform GUI doesn't
> use native dialog boxes and filechoosers, users REALLY notice this and

Agreed.  However, XPFE works fine here IMO.

Again, I do not want to propose XPFE as viable today, and I agree it may
never be viable.  Most other critisisms posted are valid, but I don't think
that LAF is one such problem with XPFE.

Mark.




From paul at prescod.net  Tue Oct 24 08:29:42 2000
From: paul at prescod.net (Paul Prescod)
Date: Mon, 23 Oct 2000 23:29:42 -0700
Subject: [Python-Dev] FYI: ajuba solutions (formerly scriptics) acquired by 
 interwoven
References: <003201c03d18$f384a5c0$3c6340d5@hagrid> <20001023154016.A2722@thyrsus.com> <20001023162118.B18005@kronos.cnri.reston.va.us> <001e01c03d34$d11bd5f0$3c6340d5@hagrid>
Message-ID: <39F52C56.214B28A1@prescod.net>

Fredrik Lundh wrote:
> 
>...
> 
> http://sourceforge.net/projects/tcl
> http://sourceforge.net/projects/tktoolkit
> 
> and trust me, the Python 2.0/Tk8.4/Tkinter3000 combo
> will rock ;-)

Perhaps this could be an opportunity to split Tcl and Tk more cleanly.
People like Fredrick and his Perl/Ruby/... equivalents could get more
deeply involved in setting direction. It would be interesting to
contrast the number of Tcl versus Tk users right now.
-- 
 Paul Prescod - Not encumbered by corporate consensus
Simplicity does not precede complexity, but follows it. 
	- http://www.cs.yale.edu/homes/perlis-alan/quotes.html



From paul at prescod.net  Tue Oct 24 08:40:49 2000
From: paul at prescod.net (Paul Prescod)
Date: Mon, 23 Oct 2000 23:40:49 -0700
Subject: [Python-Dev] Gradual migration
Message-ID: <39F52EF1.A201C6D9@prescod.net>

Python 3K. It is the repository for our hopes and dreams. We tend to
invoke it in three different situations:

 1. in delaying discussions of gee-whiz features (e.g. static type
checking)

 2. in delaying hairy implementation re-factoring that we don't
want to undertake right now.

 3. in delaying painful backwards-compatibility breakage

I think it is somewhat debatable whether we really need to or should do
these three things all at once but that's a separate discussion for
another day. (the other experiment may inform our decision)

I want to focus on "3" -- breakage. Rather than delaying painful
backwards-compatibility breakage I thing we should make it less painful.
We should decide where we are going long before we ask our users to move
there. I think we should start including alternatives to syntaxes and
features that we know are broken. Once people move to the alternatives
we can "reassign" or remove the original syntax with much less pain.

In other words, rather than telling people "here's a new version, your
code is broken, sorry." We should tell them: "we're going to break code.
Here's an alternative syntax that you can use that will be interpreted
the same in the old and new versions -- please move to this new syntax
as quickly as possible."

I'll outline some examples of the strategy. You may or may not like
details of the particular proposals but you might still agree with the
strategy. Also, I don't claim that all of the proposals are fully
fleshed-out...again, it's the strategy I'm most interested in. I don't
even agree with every feature change I describe below -- they are just
some I've heard of for Python 3000. In other words ** this is not a
design document for Python 3000! **

Separating byte arrays from strings:

 1. immediately introduce two new functions:

   binopen("foo").read() -> byte array
   stropen("foo","UTF-8".read() -> u"...."

 2. warn about string literals that have embedded non-Unicode characters

 3. deprecate extension modules that return "old fashioned" string
arrays

 4. after a period where all strings have been restricted to
Unicode-compatibility, merge the Unicode and string types.

 5. deprecate the special Unicode u"" syntax as an imperialist
anachronism



Reclaiming the division operator from truncating integer division:

 1. immediately introduce new functions: div() that does division as we
wish it was.

 2. add a warning mode to Python (long overdue)

 3. with the warning mode on, old-fashioned division triggers a
deprecation warning.

 4. after three years as a warning situation we expect all in-use Python
scripts to have been upgraded to use the new operations and to
explicitly truncate integer division when that is what is wanted.

 5. at that point we can re-assign the division operator to be a
floating point division if we wish.




Case insensitivity:

 1. Warn whenever a module or class has two __dict__ entries that differ
only by case

 2. Eventually, disallow that form of name-clash altogether

 3. After a period, allow case variations to be equivalent.



Unifying types and classes (more vague):

 1. Add something like extension class to make type subclassing easier.

 2. Informally deprecate modules that do not incorporate it.

 3. Replace or fix details of the language and implementation that
behave differently for types and classes. (e.g. the type() operator)




-- 
 Paul Prescod - Not encumbered by ActiveState consensus
Simplicity does not precede complexity, but follows it. 
	- http://www.cs.yale.edu/homes/perlis-alan/quotes.html



From pf at artcom-gmbh.de  Tue Oct 24 09:47:03 2000
From: pf at artcom-gmbh.de (Peter Funk)
Date: Tue, 24 Oct 2000 09:47:03 +0200 (MEST)
Subject: Integer division revisited (was Re: [Python-Dev] Gradual migration)
In-Reply-To: <39F52EF1.A201C6D9@prescod.net> from Paul Prescod at "Oct 23, 2000 11:40:49 pm"
Message-ID: <m13nynX-000Dm8C@artcom0.artcom-gmbh.de>

Hi,

Paul Prescod wrote on python-dev at python.org:
[...]
> Reclaiming the division operator from truncating integer division:
[...]

Bruce Sherwood and David Scherer suggested a IMHO very clever solution to
this particular problem in March/April this year.  This thread was first 
posted to idle-dev and afterwards X-posted to python-dev:

http://www.python.org/pipermail/idle-dev/2000-April/000138.html
http://www.python.org/pipermail/idle-dev/2000-April/000140.html
http://www.python.org/pipermail/python-dev/2000-April/010029.html

Unfortunately I'm no native english speaker and have not enough time 
to make a Python-2.1 PEP from it.  May be somebody else wants to go for it?

I still believe, this was a very clever Python enhancement, which should
be officially proposed.

Regards, Peter
-- 
Peter Funk, Oldenburger Str.86, D-27777 Ganderkesee, Germany, Fax:+49 4222950260
office: +49 421 20419-0 (ArtCom GmbH, Grazer Str.8, D-28359 Bremen)



From mal at lemburg.com  Tue Oct 24 10:45:03 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Tue, 24 Oct 2000 10:45:03 +0200
Subject: [Python-Dev] Gradual migration
References: <39F52EF1.A201C6D9@prescod.net>
Message-ID: <39F54C0F.25798309@lemburg.com>

Paul Prescod wrote:
> 
> Python 3K. It is the repository for our hopes and dreams. We tend to
> invoke it in three different situations:
> 
>  1. in delaying discussions of gee-whiz features (e.g. static type
> checking)
> 
>  2. in delaying hairy implementation re-factoring that we don't
> want to undertake right now.
> 
>  3. in delaying painful backwards-compatibility breakage
> 
> I think it is somewhat debatable whether we really need to or should do
> these three things all at once but that's a separate discussion for
> another day. (the other experiment may inform our decision)

I think will simply be a consequence of doing a complete rewrite
of the interpreter for Py3K. AFAIR, the only truely feasable
solution would be doing the rewrite in a widely portable
subset of C++ and then managing classes at that level.
 
Moving to a common and very low-level strategy for classes
will allows us to put even the most basic types (strings and
numbers) into an inheritence tree. 

Differences like the
ones between Unicode and 8-bit strings would then flesh
out as two different subclasses of a generic string type which
again is based on a generic sequence type.

The same could be done for dictionaries: special ones for
just string keys, case insensitive lookups, etc. could all
be subclasses of a generic mapping class.

Dito for numbers (and division strategies).

By following this principle there won't be all that much
breakage, since the old functionality will still be around,
only the defaults will have changed.

Add to this pluggable compilers and ceval loops, plus a nice
way of configuring the lot on a per-module basis and you're
set. (Ok, it's a fluffy clouds image, but you get the picture ;-)

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From guido at python.org  Tue Oct 24 17:57:43 2000
From: guido at python.org (Guido van Rossum)
Date: Tue, 24 Oct 2000 10:57:43 -0500
Subject: [Python-Dev] Gradual migration
In-Reply-To: Your message of "Tue, 24 Oct 2000 10:45:03 +0200."
             <39F54C0F.25798309@lemburg.com> 
References: <39F52EF1.A201C6D9@prescod.net>  
            <39F54C0F.25798309@lemburg.com> 
Message-ID: <200010241557.KAA15629@cj20424-a.reston1.va.home.com>

> Paul Prescod wrote:
> > 
> > Python 3K. It is the repository for our hopes and dreams. We tend to
> > invoke it in three different situations:
> > 
> >  1. in delaying discussions of gee-whiz features (e.g. static type
> > checking)
> > 
> >  2. in delaying hairy implementation re-factoring that we don't
> > want to undertake right now.
> > 
> >  3. in delaying painful backwards-compatibility breakage
> > 
> > I think it is somewhat debatable whether we really need to or should do
> > these three things all at once but that's a separate discussion for
> > another day. (the other experiment may inform our decision)

Marc-Andre Lemburg replied:

> I think will simply be a consequence of doing a complete rewrite
> of the interpreter for Py3K. AFAIR, the only truely feasable
> solution would be doing the rewrite in a widely portable
> subset of C++ and then managing classes at that level.
>  
> Moving to a common and very low-level strategy for classes
> will allows us to put even the most basic types (strings and
> numbers) into an inheritence tree. 
> 
> Differences like the
> ones between Unicode and 8-bit strings would then flesh
> out as two different subclasses of a generic string type which
> again is based on a generic sequence type.
> 
> The same could be done for dictionaries: special ones for
> just string keys, case insensitive lookups, etc. could all
> be subclasses of a generic mapping class.
> 
> Dito for numbers (and division strategies).
> 
> By following this principle there won't be all that much
> breakage, since the old functionality will still be around,
> only the defaults will have changed.
> 
> Add to this pluggable compilers and ceval loops, plus a nice
> way of configuring the lot on a per-module basis and you're
> set. (Ok, it's a fluffy clouds image, but you get the picture ;-)

Good job in channeling me, Marc-Andre!  I'm sure that's not exactly
how it's going to be, but on the face of it, this sure sounds like a
reasonable possible route.  Do you want to be the author for PEP-3000?

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



From guido at python.org  Tue Oct 24 18:13:37 2000
From: guido at python.org (Guido van Rossum)
Date: Tue, 24 Oct 2000 11:13:37 -0500
Subject: [Python-Dev] Gradual migration
In-Reply-To: Your message of "Mon, 23 Oct 2000 23:40:49 MST."
             <39F52EF1.A201C6D9@prescod.net> 
References: <39F52EF1.A201C6D9@prescod.net> 
Message-ID: <200010241613.LAA15769@cj20424-a.reston1.va.home.com>

> I want to focus on "3" -- breakage. Rather than delaying painful
> backwards-compatibility breakage I thing we should make it less painful.
> We should decide where we are going long before we ask our users to move
> there. I think we should start including alternatives to syntaxes and
> features that we know are broken. Once people move to the alternatives
> we can "reassign" or remove the original syntax with much less pain.

Absolutely.  Whenever possible, we should try to plan for migration in
Python 2.x.

> In other words, rather than telling people "here's a new version, your
> code is broken, sorry." We should tell them: "we're going to break code.
> Here's an alternative syntax that you can use that will be interpreted
> the same in the old and new versions -- please move to this new syntax
> as quickly as possible."

It would also help if we could produce automatic translation tools
that will convert the old syntax into the new.  This desire may
restrict our choices however: the translation tools don't have runtime
information to go by.  It's easy enough to change obsolete syntax into
new syntax, but it's hard to decide whether a particular "/" operator
should be changed into an integer divide ("//") or left alone.

> I'll outline some examples of the strategy. You may or may not like
> details of the particular proposals but you might still agree with the
> strategy. Also, I don't claim that all of the proposals are fully
> fleshed-out...again, it's the strategy I'm most interested in. I don't
> even agree with every feature change I describe below -- they are just
> some I've heard of for Python 3000. In other words ** this is not a
> design document for Python 3000! **

I think the proper approach is to start a separate migration process
for each of these proposed changes.  Each should be paced separately
(the pace may depend on how hard to swallow the change is for users as
well as how hard it is to implement the new functionality) and for
each, a separate PEP in the 3000 series should be started.  I can even
see that several PEPs will be needed in some cases (e.g. one to
describe the new syntax, one to to flesh out the implementation, and
one to decide on the migration steps).

I won't comment on Paul's examples, that's for the various PEP
processes.

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



From cgw at fnal.gov  Tue Oct 24 17:21:45 2000
From: cgw at fnal.gov (Charles G Waldman)
Date: Tue, 24 Oct 2000 10:21:45 -0500 (CDT)
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: <ECEPKNMJLHAPFFJHDOJBKEKIDOAA.MarkH@ActiveState.com>
References: <14837.14407.954185.466011@buffalo.fnal.gov>
	<ECEPKNMJLHAPFFJHDOJBKEKIDOAA.MarkH@ActiveState.com>
Message-ID: <14837.43273.24692.93965@buffalo.fnal.gov>

Mark Hammond writes:
 > >  > Agreed.  However, XPFE works fine here IMO.
 > >
 > cgw> "Here" means on MS-Win, right?   Maybe that's why our perceptions are
 > cgw> so different.
 > 
 > Correct.  Although I have run it under Linux a few times, I wouldnt really
 > know LAF issues if I tripped over them there ;-)
 > 
 > Mark.

It's certainly true that the lack of a consistent look and feel for
Linux apps has been somewhat of a problem historically.  However, with
the emergence of Gnome, it seems that there is finally some
convergence.  (Althought people in the KDE/Qt camp will certainly not
agree!)  Gnome is gathering momentum, especially now that Sun has
joined the Gnome Foundation.  With outfits like Eazel, Helix Code,
etc, turning out high-quality products, things are moving fast in the
Gnome/Gtk+ world and it seems clear to me that this will be the major
desktop platform for Unix machines in the upcoming decade.

Back in my former life, when I was still worrying about Windows, the
company I worked for bought into a commerical x-platform GUI toolkit
called Galaxy (I mentioned this earlier).  Galaxy re-implemented all
the native widgets, kind of like XPFE does.  One issue with this was
that MS seemed to change something about the widgets in every release
- e.g. the Galaxy filechooser looked like Windows 3.1, then Win95 came
out and Galaxy had to play catch-up.  Once Galaxy had the Win95 LAF,
Win98 came out.  Now I hear there's something called Windows ME.  Have
they changed the look-and-feel again?  Seems to me like all the
widget-reimplementors are doomed to playing eternal catch-up.

OK, enough off-topic rambling (for now),
	   
	   -C






From akuchlin at mems-exchange.org  Tue Oct 24 17:43:26 2000
From: akuchlin at mems-exchange.org (Andrew Kuchling)
Date: Tue, 24 Oct 2000 11:43:26 -0400
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: <14837.43273.24692.93965@buffalo.fnal.gov>; from cgw@fnal.gov on Tue, Oct 24, 2000 at 10:21:45AM -0500
References: <14837.14407.954185.466011@buffalo.fnal.gov> <ECEPKNMJLHAPFFJHDOJBKEKIDOAA.MarkH@ActiveState.com> <14837.43273.24692.93965@buffalo.fnal.gov>
Message-ID: <20001024114326.E13957@kronos.cnri.reston.va.us>

On Tue, Oct 24, 2000 at 10:21:45AM -0500, Charles G Waldman wrote:
>It's certainly true that the lack of a consistent look and feel for
>Linux apps has been somewhat of a problem historically.  However, with
>the emergence of Gnome, it seems that there is finally some
>convergence.  (Althought people in the KDE/Qt camp will certainly not

Careful... while people may try to port GTk+ to Windows, porting GNOME
is a different kettle of wax, because GNOME needs GTk+ but also
entails gnome-libs and gnome-vfs and Bonobo and esound and lots of
other things, which provide services such as object embedding that
wouldn't be required -- or would be very different -- on Windows.  I
don't know if anyone is trying to tease apart GNOME into a
Windows-suitable subset; it seems like it would be a difficult task.

Qt is at least a toolkit that aims at cross-platform portability,
though there again, the KDE environment built on top of it is not
going to be portable to anything that isn't Unix.  Both the Qt and
GTk+ toolkits ignore the Mac, leaving Tk and wxWindows as the only
real possibilities.  This is why, every time this debate comes up, we
end up sticking with Tk; it may suck, but all the other systems don't
support everything...

Maybe the best approach is to follow /F's lead with Tkinter3000, and
reimplement the Tkinter API on top of MFC / GTk+ / Qt.  (Er... that
*is* what Tkinter3000 is, right?)  What's the problem we're trying to solve here?

     * Is it that the problem that the Tkinter module is a bad API for
       GUI programming?

     * Or is it that the Tk implementation is slow or bulky?

     * Or do we just dislike having to require Tcl as well as Tk?

Can someone articulate why Tk should be replaced?

--amk



From gvwilson at nevex.com  Tue Oct 24 17:52:00 2000
From: gvwilson at nevex.com (Greg Wilson)
Date: Tue, 24 Oct 2000 11:52:00 -0400 (EDT)
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: <20001024114326.E13957@kronos.cnri.reston.va.us>
Message-ID: <Pine.LNX.4.10.10010241146450.6622-100000@akbar.nevex.com>

> Andrew Kuchling wrote:
> What's the problem we're trying to solve here?
> 
> * Is it that the problem that the Tkinter module is a bad API for
>   GUI programming?
> 
> * Or is it that the Tk implementation is slow or bulky?
> 
> * Or do we just dislike having to require Tcl as well as Tk?
> 
> Can someone articulate why Tk should be replaced?

I can articulate why I'm unhappy with the current set-up:

1. Requiring Tcl is fragile.  Un-gumming installation on machines at Los
   Alamos before my first Python course cost me several hours, and I had
   to do it again two months' later.  I've run into similar problems with
   multiple Tcl installations on Windows machines (personal use).

2. (Lack of) native look and feel.  This is a complete show-stopper for
   many of the outfits I've dealt with (and not just with Python).

Performance doesn't really matter --- I've never had students complain about
speed, although I've never asked them to build something large enough that
refresh would be an issue.

I don't have experience teaching wxPython, so I can't comment on the
relative teachability of its API vs. Tk's.

Hope this helps,
Greg





From paul at prescod.net  Tue Oct 24 18:12:12 2000
From: paul at prescod.net (Paul Prescod)
Date: Tue, 24 Oct 2000 09:12:12 -0700
Subject: [Python-Dev] Gradual migration
References: <39F52EF1.A201C6D9@prescod.net> <39F54C0F.25798309@lemburg.com>
Message-ID: <39F5B4DC.C226D8F6@prescod.net>

"M.-A. Lemburg" wrote:
> 
>...
> 
> I think will simply be a consequence of doing a complete rewrite
> of the interpreter for Py3K. AFAIR, the only truely feasable
> solution would be doing the rewrite in a widely portable
> subset of C++ and then managing classes at that level.

I disagree for a variety of reasons:

 * implementation language and Python inheritance semantics are almost
completely distinct. After all, we have Python implementations in a
variety of languages with minor incompatibilities. Python could have a
proper type/class merging even if it were written in assembly language.
So let's leave implementation language aside.

 * there is a hell of a lot we can do to make the type/class split less
visible without a major rewrite. For instance, lists could have a
__getitem__ method so that they "act like" instances. Instances could
return their methods in a dir() so that they "act like" built-in
objects. So there is no reason to wait for a complete rewrite to start
on this path.

 * It may even be the case that we can get from here to complete merged
type/class semantics WITHOUT a rewrite. If a mad genious had not written
stackless Python I would have sworn up and down that stackless Python
would require a Python rewrite. It didn't. If another slightly less mad
genious had not integrated ints and longs I would never have believed it
possible without another rewrite. Someone needs to do an analysis of
what it takes to merge types and classes and *demonstrate* that it
requires a rewrite rather than *asserting* that it requires a rewrite.

In other words, let's stop sprinkling the "major rewrite" pixie dust on
hard problems and instead decide where we want to go and how we want to
get there!

> Moving to a common and very low-level strategy for classes
> will allows us to put even the most basic types (strings and
> numbers) into an inheritence tree.

I don't know what you mean by a "low-level strategy" for classes. It's
not like we can somehow use C++ vtables without giving up Python's
dynamicity. Python's class handling is about as low-level as it can get
in my humble opinion.

> Differences like the
> ones between Unicode and 8-bit strings would then flesh
> out as two different subclasses of a generic string type which
> again is based on a generic sequence type.

Of course that's where we want to go but it doesn't avoid the backwards
compatibility problems. We can do this today using proxying.

> The same could be done for dictionaries: special ones for
> just string keys, case insensitive lookups, etc. could all
> be subclasses of a generic mapping class.

We can easily do this today.

> Dito for numbers (and division strategies).

There's no way I'm going to let you get away with that little sleight of
hand. How is inheritance holy water going to allow us to change the
semantics of:

5/2

without breaking code??

The same goes for

a.b = 5

versus

a.B = 5

C++ does not help. Inheritance does not help. Pluggable compilers do not
help. We *will* break code. We just need to decide whether to do it in a
thoughtful way that gives people a chance to migrate or put off
decisions until the last possible moment and then spring it on them with
no between-version upgrade path.

> By following this principle there won't be all that much
> breakage, since the old functionality will still be around,
> only the defaults will have changed.

When you change defaults you break code. Keeping the old functionality
around is barely helpful.  Nobody has EVER proposed a change to Python
where something that was previously possible is now made impossible. So
whatever our strategy, the PROBLEM is changing defaults. The solution is
telling people what defaults are changing in what timeline and
discouraging them from depending on the old defaults.

> Add to this pluggable compilers and ceval loops, plus a nice
> way of configuring the lot on a per-module basis and you're
> set. (Ok, it's a fluffy clouds image, but you get the picture ;-)

Sounds mythical. I'm trying to take it out of the realm of fluffy clouds
and bring it into the world that people can plan their businesses and
coding strategies around.
-- 
 Paul Prescod - Not encumbered by corporate consensus
Simplicity does not precede complexity, but follows it. 
	- http://www.cs.yale.edu/homes/perlis-alan/quotes.html



From paul at prescod.net  Tue Oct 24 18:30:17 2000
From: paul at prescod.net (Paul Prescod)
Date: Tue, 24 Oct 2000 09:30:17 -0700
Subject: [Python-Dev] Gradual migration
References: <39F52EF1.A201C6D9@prescod.net> <200010241613.LAA15769@cj20424-a.reston1.va.home.com>
Message-ID: <39F5B919.4B80A526@prescod.net>

Guido van Rossum wrote:
> 
> ...
> 
> I think the proper approach is to start a separate migration process
> for each of these proposed changes.  

I agree.

As a more concrete extension to my last email, I propose the following
doctrine:

"""
No major documented feature should be removed or have changed semantics
in Python 3000 or any other new version of Python until users have had a
year (preferably MORE!) of upgrade time. Upgrade time entails the
following parts:

    1. the released Python version has a new recommended way to
accomplish the task in a manner that will remain available in the
"breakage version" e.g. a div() function that people can use for a few
years while the semantics of "/" are in transition.

    2. the mechanism/syntax that will be removed is formally deprecated.
The documentation would say, e.g. "You should not use '/' for now. It is
changing semantics in the future."

    3. the released Python version sports a runtime warning to tell
users that the mechanism/syntax is going away. "CompatibilityError:
Future versions of Python will have different semantics for the '/'
operator. Please use div() instead."

The actual "right" amount of upgrade time depends on the extent of the
breakage and its ease of detection.
"""

I can PEP this if people agree. I think that the user community would
appreciate our effort to promise not to break code suddenly and
capriciously.
-- 
 Paul Prescod - Not encumbered by corporate consensus
Simplicity does not precede complexity, but follows it. 
	- http://www.cs.yale.edu/homes/perlis-alan/quotes.html



From barry at wooz.org  Tue Oct 24 18:26:13 2000
From: barry at wooz.org (Barry A. Warsaw)
Date: Tue, 24 Oct 2000 12:26:13 -0400 (EDT)
Subject: [Python-Dev] What to choose to replace Tkinter?
References: <20001024114326.E13957@kronos.cnri.reston.va.us>
	<Pine.LNX.4.10.10010241146450.6622-100000@akbar.nevex.com>
Message-ID: <14837.47141.817450.488896@anthem.concentric.net>

>>>>> "GW" == Greg Wilson <gvwilson at nevex.com> writes:

    GW> 2. (Lack of) native look and feel.  This is a complete
    GW> show-stopper for many of the outfits I've dealt with (and not
    GW> just with Python).

On the other hand, it's incredibly easy to whip together a GUI in Tk
for simple applications.  Yes, Tk gets painful as applications grow,
but I'd hate to abandon such a simple, well-known toolkit for a
complicated, hard-to-learn but powerful native look-and-feel one.  You
don't /always/ care about strict native LAF.

Or to restate: I'd hate to have to make that choice.  If we can't
satisfy both requirements (mandatory-native-LAF and rapid prototyping
friendliness), we may need to continue to support multiple toolkits.

the-delicious-aroma-of-the-first-GUI-bakeoff-still-in-the-air-ly y'rs,
-Barry



From guido at python.org  Tue Oct 24 19:39:38 2000
From: guido at python.org (Guido van Rossum)
Date: Tue, 24 Oct 2000 12:39:38 -0500
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: Your message of "Tue, 24 Oct 2000 11:52:00 -0400."
             <Pine.LNX.4.10.10010241146450.6622-100000@akbar.nevex.com> 
References: <Pine.LNX.4.10.10010241146450.6622-100000@akbar.nevex.com> 
Message-ID: <200010241739.MAA16414@cj20424-a.reston1.va.home.com>

> I can articulate why I'm unhappy with the current set-up:
> 
> 1. Requiring Tcl is fragile.  Un-gumming installation on machines at Los
>    Alamos before my first Python course cost me several hours, and I had
>    to do it again two months' later.  I've run into similar problems with
>    multiple Tcl installations on Windows machines (personal use).

For Windows, this problem has gone away in 1.6 and 2.0 -- we
distribute and install our own Tcl/Tk binaries, in a place that
doesn't affect or require existing Tcl/Tk installations.

Maybe we can do the same for Unix binary distributions?  I believe
Jeremy has already had to create a separate RPM for _tkinter because
there are too many different versions of Tcl/Tk out there -- it
shouldn't be hard to install our own altogether.

> 2. (Lack of) native look and feel.  This is a complete show-stopper for
>    many of the outfits I've dealt with (and not just with Python).

Really?  Are you sure that's not just general resistence against new
things?  To me, and I suspect may others, the app I use most often on
Windows is Netscape -- talk about lack of native look-and-feel!  It's
never bothered me all that much.

Or are you saying that IDLE isn't designed as a typical Microsoft app?
That's quite a separate issue from the widget look-and-feel!

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



From barry at wooz.org  Tue Oct 24 18:40:50 2000
From: barry at wooz.org (Barry A. Warsaw)
Date: Tue, 24 Oct 2000 12:40:50 -0400 (EDT)
Subject: [Python-Dev] Gradual migration
References: <39F52EF1.A201C6D9@prescod.net>
	<39F54C0F.25798309@lemburg.com>
	<39F5B4DC.C226D8F6@prescod.net>
Message-ID: <14837.48018.547379.464959@anthem.concentric.net>

>>>>> "PP" == Paul Prescod <paul at prescod.net> writes:

    PP>  * implementation language and Python inheritance semantics
    PP> are almost completely distinct. After all, we have Python
    PP> implementations in a variety of languages with minor
    PP> incompatibilities. Python could have a proper type/class
    PP> merging even if it were written in assembly language.  So
    PP> let's leave implementation language aside.

Jython experience backs this up.  It would be incredibly convenient if
we could just map Java classes to Python classes, so that for example,
we'd have in Java a PyException class that is exceptions.Exception
with minimal or no Java wrappings.  And Finn nearly did this.

The problem that we ran into with Java is that it allows only single
inheritance.  So you couldn't create a Python exception that multiply
inherited from two or more other Python exceptions.  Doesn't happen
often, but it does happen, so is that an acceptable tradeoff?

C++ might be better in this particular respect, but there will be
other issues, because as soon as you start transparently showing the
implementation's classes into Python, you inherit their semantics and
restrictions as well.

Just saying that it's tricky.
-Barry



From guido at python.org  Tue Oct 24 19:54:39 2000
From: guido at python.org (Guido van Rossum)
Date: Tue, 24 Oct 2000 12:54:39 -0500
Subject: [Python-Dev] Gradual migration
In-Reply-To: Your message of "Tue, 24 Oct 2000 09:30:17 MST."
             <39F5B919.4B80A526@prescod.net> 
References: <39F52EF1.A201C6D9@prescod.net> <200010241613.LAA15769@cj20424-a.reston1.va.home.com>  
            <39F5B919.4B80A526@prescod.net> 
Message-ID: <200010241754.MAA16520@cj20424-a.reston1.va.home.com>

> As a more concrete extension to my last email, I propose the following
> doctrine:
> 
> """
> No major documented feature should be removed or have changed semantics
> in Python 3000 or any other new version of Python until users have had a
> year (preferably MORE!) of upgrade time. Upgrade time entails the
> following parts:
> 
>     1. the released Python version has a new recommended way to
> accomplish the task in a manner that will remain available in the
> "breakage version" e.g. a div() function that people can use for a few
> years while the semantics of "/" are in transition.
> 
>     2. the mechanism/syntax that will be removed is formally deprecated.
> The documentation would say, e.g. "You should not use '/' for now. It is
> changing semantics in the future."
> 
>     3. the released Python version sports a runtime warning to tell
> users that the mechanism/syntax is going away. "CompatibilityError:
> Future versions of Python will have different semantics for the '/'
> operator. Please use div() instead."
> 
> The actual "right" amount of upgrade time depends on the extent of the
> breakage and its ease of detection.
> """
> 
> I can PEP this if people agree. I think that the user community would
> appreciate our effort to promise not to break code suddenly and
> capriciously.

Go for it.  I have little bandwidth to think about this deeply, but
what you're proposing here sounds like a good approach.  Certainly it
will make it easier if I can point to this PEP when I get the next FUD
email about "should I bother to learn Python 2.0 when Py3K is going to
be all different?"...

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



From effbot at telia.com  Tue Oct 24 19:07:12 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Tue, 24 Oct 2000 19:07:12 +0200
Subject: [Python-Dev] FYI: ajuba solutions (formerly scriptics) acquired by interwoven
References: <003201c03d18$f384a5c0$3c6340d5@hagrid> <20001023154016.A2722@thyrsus.com> <20001023162118.B18005@kronos.cnri.reston.va.us> <001e01c03d34$d11bd5f0$3c6340d5@hagrid> <39F52C56.214B28A1@prescod.net>
Message-ID: <006001c03ddc$dda85570$3c6340d5@hagrid>

paul wrote:
> Perhaps this could be an opportunity to split Tcl and Tk more cleanly.
> People like Fredrick and his Perl/Ruby/... equivalents could get more
> deeply involved in setting direction.

I'm waiting for the Tcl/Tk developers to grow up -- they still
fear that any attempt to make it easier to use Tk from other
languages would be to "give up the crown jewels" :-(

</F>




From effbot at telia.com  Tue Oct 24 18:59:23 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Tue, 24 Oct 2000 18:59:23 +0200
Subject: [Python-Dev] What to choose to replace Tkinter?
References: <14837.14407.954185.466011@buffalo.fnal.gov> <ECEPKNMJLHAPFFJHDOJBKEKIDOAA.MarkH@ActiveState.com> <14837.43273.24692.93965@buffalo.fnal.gov> <20001024114326.E13957@kronos.cnri.reston.va.us>
Message-ID: <005f01c03ddc$dd52bb60$3c6340d5@hagrid>

andrew wrote:
> Maybe the best approach is to follow /F's lead with Tkinter3000, and
> reimplement the Tkinter API on top of MFC / GTk+ / Qt.  (Er... that
> *is* what Tkinter3000 is, right?)

nope -- at least not initially.  the first two steps are a new
Tk glue layer, and an extension API that allows you to write
new widgets in pure Python.  also see:

    http://w1.132.telia.com/~u13208596/tkinter/index.htm

:::

I have plans for how to take the Tkinter API *and* the new
extension API beyond Tk, but let's save that for another day...

:::

> Can someone articulate why Tk should be replaced?

beats me ;-)

</F>




From cgw at fnal.gov  Tue Oct 24 18:54:35 2000
From: cgw at fnal.gov (Charles G Waldman)
Date: Tue, 24 Oct 2000 11:54:35 -0500 (CDT)
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: <20001024114326.E13957@kronos.cnri.reston.va.us>
References: <14837.14407.954185.466011@buffalo.fnal.gov>
	<ECEPKNMJLHAPFFJHDOJBKEKIDOAA.MarkH@ActiveState.com>
	<14837.43273.24692.93965@buffalo.fnal.gov>
	<20001024114326.E13957@kronos.cnri.reston.va.us>
Message-ID: <14837.48843.889458.137903@buffalo.fnal.gov>

Andrew Kuchling writes:
 > 
 > Careful... while people may try to port GTk+ to Windows, porting GNOME
 > is a different kettle of wax, because GNOME needs GTk+ but also
 > entails gnome-libs

But I was never seriously advocating Gtk+ on Windows.  This was just a
footnote.  I shouldn't have even mentioned the Windows Gtk+ port
because it just muddied the water.

The major point I was trying to make is that toolkits like Tkinter and
WxWindows, which try to delegate to the native widget sets whenever
possible, will succeed, and toolkits like Galaxy/AWT/Swing/XPFE, which
reimpliment all the widgets from scratch, are doomed to fail.  (IMO,
of course).

What I believe we need is a suitable abstraction which uses MFC on
MS-Win platforms and Gtk+ on Unix.  And which also doesn't, due to the
abstraction, take away too many features.  I don't know that much
about MFC, but for a simple example - Gtk+ offers an option for its
canvas widget to do all drawing in antialised mode (by the way, this
is slow but produces very nice looking results).  It would be a shame
if the abstraction layer didn't allow for things like this to be used.

 > This is why, every time this debate comes up, we
 > end up sticking with Tk; it may suck, but all the other systems don't
 > support everything...

Right.  FWIW, in my day-to-day work, if it has to run on MS-Win I use
Tkinter, and if MS-Win is not an issue I use PyGtk.  Fermilab will be
showing some network monitoring software at the Supercomputing 2000
conference next month, and it's mostly all stuff I whipped up a few
days using Tkinter.



From gmcm at hypernet.com  Tue Oct 24 19:14:42 2000
From: gmcm at hypernet.com (Gordon McMillan)
Date: Tue, 24 Oct 2000 13:14:42 -0400
Subject: [Python-Dev] Gradual migration
In-Reply-To: <39F5B4DC.C226D8F6@prescod.net>
Message-ID: <39F58B42.26855.490B8F73@localhost>

Paul Prescod wrote:
...
> .... It's
> not like we can somehow use C++ vtables without giving up Python's
> dynamicity. 

But that's exactly what COM does.

not-to-be-taken-as-an-endorsement-ly y'rs

- Gordon



From akuchlin at mems-exchange.org  Tue Oct 24 19:15:14 2000
From: akuchlin at mems-exchange.org (Andrew Kuchling)
Date: Tue, 24 Oct 2000 13:15:14 -0400
Subject: [Python-Dev] FYI: ajuba solutions (formerly scriptics) acquired by interwoven
In-Reply-To: <006001c03ddc$dda85570$3c6340d5@hagrid>; from effbot@telia.com on Tue, Oct 24, 2000 at 07:07:12PM +0200
References: <003201c03d18$f384a5c0$3c6340d5@hagrid> <20001023154016.A2722@thyrsus.com> <20001023162118.B18005@kronos.cnri.reston.va.us> <001e01c03d34$d11bd5f0$3c6340d5@hagrid> <39F52C56.214B28A1@prescod.net> <006001c03ddc$dda85570$3c6340d5@hagrid>
Message-ID: <20001024131514.B25025@kronos.cnri.reston.va.us>

On Tue, Oct 24, 2000 at 07:07:12PM +0200, Fredrik Lundh wrote:
>I'm waiting for the Tcl/Tk developers to grow up -- they still
>fear that any attempt to make it easier to use Tk from other
>languages would be to "give up the crown jewels" :-(

In the long run this has probably harmed Tk seriously.  If Tk was just
a widget set divorced from Tcl, then it might have been chosen as the
underlying widget set for GNOME or KDE, and then have benefited from
the development work done for those projects, such as the GNOME canvas
enhancements, which now can't be absorbed back into Tk without a lot
of effort to merge the two sets of code.  

--amk



From gvwilson at nevex.com  Tue Oct 24 19:58:59 2000
From: gvwilson at nevex.com (Greg Wilson)
Date: Tue, 24 Oct 2000 13:58:59 -0400 (EDT)
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: <200010241739.MAA16414@cj20424-a.reston1.va.home.com>
Message-ID: <Pine.LNX.4.10.10010241355360.6622-100000@akbar.nevex.com>

> > Greg Wilson:
> > I can articulate why I'm unhappy with the current set-up:
> > 1. Requiring Tcl is fragile.

> Guido van Rossum:
> For Windows, this problem has gone away in 1.6 and 2.0 -- we distribute and
> install our own Tcl/Tk binaries

OK.

> > Greg Wilson:
> > 2. (Lack of) native look and feel.  This is a complete show-stopper for
> >    many of the outfits I've dealt with (and not just with Python).

> Guido van Rossum:
> Really?  Are you sure that's not just general resistence against new things?

Well, my students' resistance to novelty is low enough that they're willing to
take a Python course :-).  This comes up every time I teach; no idea whether it
has any impact on the usability of completed applications, but I believe it
makes people less likely to choose Tkinter when starting development.

Thanks,
Greg




From guido at python.org  Tue Oct 24 21:04:55 2000
From: guido at python.org (Guido van Rossum)
Date: Tue, 24 Oct 2000 14:04:55 -0500
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: Your message of "Tue, 24 Oct 2000 13:58:59 -0400."
             <Pine.LNX.4.10.10010241355360.6622-100000@akbar.nevex.com> 
References: <Pine.LNX.4.10.10010241355360.6622-100000@akbar.nevex.com> 
Message-ID: <200010241904.OAA19165@cj20424-a.reston1.va.home.com>

> Well, my students' resistance to novelty is low enough that they're
> willing to take a Python course :-).  This comes up every time I
> teach; no idea whether it has any impact on the usability of
> completed applications, but I believe it makes people less likely to
> choose Tkinter when starting development.

Can you elaborate on the line of argument that you typically hear?
What do you say to dispel it?

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



From nas at arctrix.com  Tue Oct 24 13:56:11 2000
From: nas at arctrix.com (Neil Schemenauer)
Date: Tue, 24 Oct 2000 04:56:11 -0700
Subject: [Python-Dev] A small step to removing the type/class split
Message-ID: <20001024045611.B9993@glacier.fnational.com>

I've run into a problem with ExtensionClass which I believe can
only be fixed by modifying Python.  I will try to explain.

I have an ExtensionClass which defines __cmp__.  Depending on the
objects being compared, the __cmp__ method may never be called.
This is due to code in object.c that looks like this:

    if (PyInstance_Check(v) || PyInstance_Check(w)) {
        try to use use __cmp__ method
    }
    else {
        try number coerce and fall back on type name comparison
    }

Extension classes can never pass the PyInstance_Check predicate.
I've searched for all occurances of PyInstance_Check in the 2.0
source.  In many places that PyInstance_Check occurs a more
general "is this an instance-like type" check would seem to be
more suitable.

Here is my proposal:

  * Define a new type flag Py_TPFLAGS_INSTANCE.
  * Create a new predicate Py_IsInstance which checks for this
    flag.
  * Set this flag on PyInstance_Type.
  * Replace most occurances of PyInstance_Check with
    Py_IsInstance.

Extension types (like ExtensionClass) can then define the type
flag Py_TPLAGS_INSTANCE and be treated as an instance type by the
Python interpreter.  This should make it quite a bit easier to make
extension types behave like "real" classes.

Comments?

  Neil



From mal at lemburg.com  Tue Oct 24 21:37:30 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Tue, 24 Oct 2000 21:37:30 +0200
Subject: [Python-Dev] Gradual migration
References: <39F52EF1.A201C6D9@prescod.net> <39F54C0F.25798309@lemburg.com> <39F5B4DC.C226D8F6@prescod.net>
Message-ID: <39F5E4FA.9FD6D35@lemburg.com>

Paul Prescod wrote:
> 
> "M.-A. Lemburg" wrote:
> >
> >...
> >
> > I think will simply be a consequence of doing a complete rewrite
> > of the interpreter for Py3K. AFAIR, the only truely feasable
> > solution would be doing the rewrite in a widely portable
> > subset of C++ and then managing classes at that level.
> 
> I disagree for a variety of reasons:
> 
>  * implementation language and Python inheritance semantics are almost
> completely distinct. After all, we have Python implementations in a
> variety of languages with minor incompatibilities. Python could have a
> proper type/class merging even if it were written in assembly language.
> So let's leave implementation language aside.

Hey, think of it as opportunity: we can reuse much of C++'s 
optimizations and the integration of Python and C++ applications
will get *much* easier.
 
A rewrite shouldn't scare anyone away -- much of the existing
code can be reused since only the Python C APIs of the various
types will have to be rewritten, not the logic behind the types.

Besides, Py3K will be a project which runs in parallel to the
2.x development (at least that's what I've read on some BeOpen
webpage), so there's really not much to worry about wrt to
breakage, etc. People will be able to test-drive Py3K while
using the 2.x series.

>  * there is a hell of a lot we can do to make the type/class split less
> visible without a major rewrite. For instance, lists could have a
> __getitem__ method so that they "act like" instances. Instances could
> return their methods in a dir() so that they "act like" built-in
> objects. So there is no reason to wait for a complete rewrite to start
> on this path.

Right. I didn't want to say that things cannot be done prior
to the rewrite, only that a rewrite will give us much more
options that we currently have.

>  * It may even be the case that we can get from here to complete merged
> type/class semantics WITHOUT a rewrite. If a mad genious had not written
> stackless Python I would have sworn up and down that stackless Python
> would require a Python rewrite. It didn't. If another slightly less mad
> genious had not integrated ints and longs I would never have believed it
> possible without another rewrite. Someone needs to do an analysis of
> what it takes to merge types and classes and *demonstrate* that it
> requires a rewrite rather than *asserting* that it requires a rewrite.
>
> In other words, let's stop sprinkling the "major rewrite" pixie dust on
> hard problems and instead decide where we want to go and how we want to
> get there!

See above.
 
> > Moving to a common and very low-level strategy for classes
> > will allows us to put even the most basic types (strings and
> > numbers) into an inheritence tree.
> 
> I don't know what you mean by a "low-level strategy" for classes. It's
> not like we can somehow use C++ vtables without giving up Python's
> dynamicity. Python's class handling is about as low-level as it can get
> in my humble opinion.

With "low-level" I meant trying to build Python classes and
instances on top of a very thin layer on top of C++ classes,
e.g. all slots could be implemented using true C++ methods with
additional logic to override them using dynamically bound
Python method objects.

> > Differences like the
> > ones between Unicode and 8-bit strings would then flesh
> > out as two different subclasses of a generic string type which
> > again is based on a generic sequence type.
> 
> Of course that's where we want to go but it doesn't avoid the backwards
> compatibility problems.

Huh ? I was talking about clear design... not ways to avoid
b/w compatibility. Merging Unicode and strings will hurt one
way or another. This is simply a consequence of using strings
as binary containers where Unicode is meant for text only use.

> We can do this today using proxying.

Could you explain this ?
 
> > The same could be done for dictionaries: special ones for
> > just string keys, case insensitive lookups, etc. could all
> > be subclasses of a generic mapping class.
> 
> We can easily do this today.

No we can't: Python's use of pointer compares to find out
which type it is dealing with prevent this.
 
> > Dito for numbers (and division strategies).
> 
> There's no way I'm going to let you get away with that little sleight of
> hand. How is inheritance holy water going to allow us to change the
> semantics of:
> 
> 5/2
> 
> without breaking code??
> 
> The same goes for
> 
> a.b = 5
> 
> versus
> 
> a.B = 5
> 
> C++ does not help. Inheritance does not help. Pluggable compilers do not
> help. We *will* break code. We just need to decide whether to do it in a
> thoughtful way that gives people a chance to migrate or put off
> decisions until the last possible moment and then spring it on them with
> no between-version upgrade path.

Just tell Python to use the correct class for what the
code was written for (and this could be done by plugging in
a 2.0 compiler). The instances of those classes would still work
together with other semantics by virtue of exposing the same
interface, yet the internals would work differently, e.g.
a module using case insensitive lookup would be compiled using
case insensitive dictionaries as namespaces.

> > By following this principle there won't be all that much
> > breakage, since the old functionality will still be around,
> > only the defaults will have changed.
> 
> When you change defaults you break code. Keeping the old functionality
> around is barely helpful.  Nobody has EVER proposed a change to Python
> where something that was previously possible is now made impossible. So
> whatever our strategy, the PROBLEM is changing defaults. The solution is
> telling people what defaults are changing in what timeline and
> discouraging them from depending on the old defaults.

All true. I was just referring to the possibility of keeping
the old semantics around in case some module relies on them.
In this ideal world, a simple "define pythonlevel=2.0"
would suffice to make the old module work with Py3k.
 
> > Add to this pluggable compilers and ceval loops, plus a nice
> > way of configuring the lot on a per-module basis and you're
> > set. (Ok, it's a fluffy clouds image, but you get the picture ;-)
> 
> Sounds mythical. I'm trying to take it out of the realm of fluffy clouds
> and bring it into the world that people can plan their businesses and
> coding strategies around.

Hmm, wasn't Py3k meant as sandbox for new experiments ? 
The 2.x series is for doing business with, IMHO at least. 

At the current dev speed we'll have plenty of time to get Py3k
rock solid. Then we can add all the backward compatibility layers
we want to it. If the design is a good, adding these layers
won't pose much of a problem.

Why spoil all the fun when we haven't even started thinking
about all the possibilities we could use to make Py3k a
success ?

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From mal at lemburg.com  Tue Oct 24 21:54:39 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Tue, 24 Oct 2000 21:54:39 +0200
Subject: [Python-Dev] A small step to removing the type/class split
References: <20001024045611.B9993@glacier.fnational.com>
Message-ID: <39F5E8FF.5F18C71E@lemburg.com>

Neil Schemenauer wrote:
> 
> I've run into a problem with ExtensionClass which I believe can
> only be fixed by modifying Python.  I will try to explain.
> 
> I have an ExtensionClass which defines __cmp__.  Depending on the
> objects being compared, the __cmp__ method may never be called.
> This is due to code in object.c that looks like this:
> 
>     if (PyInstance_Check(v) || PyInstance_Check(w)) {
>         try to use use __cmp__ method
>     }
>     else {
>         try number coerce and fall back on type name comparison
>     }
> 
> Extension classes can never pass the PyInstance_Check predicate.
> I've searched for all occurances of PyInstance_Check in the 2.0
> source.  In many places that PyInstance_Check occurs a more
> general "is this an instance-like type" check would seem to be
> more suitable.
> 
> Here is my proposal:
> 
>   * Define a new type flag Py_TPFLAGS_INSTANCE.
>   * Create a new predicate Py_IsInstance which checks for this
>     flag.
>   * Set this flag on PyInstance_Type.
>   * Replace most occurances of PyInstance_Check with
>     Py_IsInstance.
> 
> Extension types (like ExtensionClass) can then define the type
> flag Py_TPLAGS_INSTANCE and be treated as an instance type by the
> Python interpreter.  This should make it quite a bit easier to make
> extension types behave like "real" classes.
> 
> Comments?

Sounds fine, except that the "isinstance()" behaviour would
have to be defined somewhere / somehow... a mapping of slots
to __special_methods__ would be a good start.

BTW, mxProxy does some of this mapping already... you may want to 
have a look.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From gmcm at hypernet.com  Tue Oct 24 22:01:25 2000
From: gmcm at hypernet.com (Gordon McMillan)
Date: Tue, 24 Oct 2000 16:01:25 -0400
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: <Pine.LNX.4.10.10010241355360.6622-100000@akbar.nevex.com>
References: <200010241739.MAA16414@cj20424-a.reston1.va.home.com>
Message-ID: <39F5B255.22108.49A43169@localhost>

Greg Wilson:
> > > 2. (Lack of) native look and feel.  This is a complete show-stopper for
> > >    many of the outfits I've dealt with (and not just with Python).
> 
> > Guido van Rossum:
> > Really?  Are you sure that's not just general resistence against new things?
> 
> Well, my students' resistance to novelty is low enough that they're willing to
> take a Python course :-).  This comes up every time I teach; no idea whether it
> has any impact on the usability of completed applications, but I believe it
> makes people less likely to choose Tkinter when starting development.

As I see it, Tk, like SQL, has the property that it's dead easy 
to get something crappy running, but it takes a real expert 
(like /F) to make it good. With wxPython, though, it's easy (if 
somewhat tedious) to get something good - at least as far as 
normal "forms" style GUIs.

I'm not taking sides - I dabble in both and will never be an 
expert at either. But for clients using Windows, I use 
wxPython because it's indistinguishable from native Win32.

(BTW, MFC is lagging further and further behind native Win32 -
 I believe MS considers it "legacy".)

- Gordon



From barry at wooz.org  Tue Oct 24 22:06:23 2000
From: barry at wooz.org (Barry A. Warsaw)
Date: Tue, 24 Oct 2000 16:06:23 -0400 (EDT)
Subject: [Python-Dev] A small step to removing the type/class split
References: <20001024045611.B9993@glacier.fnational.com>
Message-ID: <14837.60351.887533.801888@anthem.concentric.net>

>>>>> "NS" == Neil Schemenauer <nas at arctrix.com> writes:

    NS> I've run into a problem with ExtensionClass which I believe
    NS> can only be fixed by modifying Python.  I will try to explain.

    NS> I have an ExtensionClass which defines __cmp__.  Depending on
    NS> the objects being compared, the __cmp__ method may never be
    NS> called.  This is due to code in object.c that looks like this:

    |     if (PyInstance_Check(v) || PyInstance_Check(w)) {
    |         try to use use __cmp__ method
    |     }
    |     else {
    |         try number coerce and fall back on type name comparison
    |     }

I hit a similar wall when I tried (a long time ago) to take a boolean
class I'd written in Python and make it a built-in type.  The problem
was that in Python I could compare a Boolean instance against any
other object for truth equivalence, but because of this hack, I
couldn't do the same with the built-in type.

    |   * Define a new type flag Py_TPFLAGS_INSTANCE.
    |   * Create a new predicate Py_IsInstance which checks for this
    |     flag.
    |   * Set this flag on PyInstance_Type.
    |   * Replace most occurances of PyInstance_Check with
    |     Py_IsInstance.

    NS> Extension types (like ExtensionClass) can then define the type
    NS> flag Py_TPLAGS_INSTANCE and be treated as an instance type by
    NS> the Python interpreter.  This should make it quite a bit
    NS> easier to make extension types behave like "real" classes.

I'm not sure how well this addresses what I ran into.  Would
PyBooleanObject then have to have it's Py_TPFLAGS_INSTANCE flag set?
Does that actually make sense?  How does this interact with the rich
comparisons idea?  Seems like this is a hack that doesn't quite get at
the heart of the matter, worthwhile as it may be given the current
implementation.

-Barry



From barry at wooz.org  Tue Oct 24 22:11:54 2000
From: barry at wooz.org (Barry A. Warsaw)
Date: Tue, 24 Oct 2000 16:11:54 -0400 (EDT)
Subject: [Python-Dev] getting at the current frame
Message-ID: <14837.60682.437334.797392@anthem.concentric.net>

I've been playing around with ideas for internationalizing Mailman,
which naturally <wink> leads to string interpolation.  To see why,
think about making the following code translatable:

    def trade(yours, mine):
	print 'if you give me %s, i will give you %s' % (yours, mine)

Because the order of the interpolated values may change in the
translated string, you really have to do something like:

    def trade(yours, mine):
	print 'if you give me %(yours)s, i will give you %(mine)s' % {
	    'yours': yours,
	    'mine' : mine,
	    }

which actually will look something like this in real code:

    def trade(yours, mine):
	print _('if you give me %(yours)s, i will give you %(mine)s') % {
	    'yours': yours,
	    'mine' : mine,
	    }

The string wrapped in _() is what gets translated here.

Okay, we all know that's a pain, right?  Lots of people have proposed
solutions.  I've looked briefly at !?ng's Itpl.py, but I think it
probably does too much by adding evaluation.

I can define _() to make the problem somewhat more convenient:

    def _(s):
	try:
	    raise Exception
	except Exception:
	    frame = sys.exc_info()[2].tb_frame.f_back
	d = frame.f_globals.copy()
	d.update(frame.f_locals())
	return the_translation_of(s) % d

Now I can write the code like this:

    def trade(yours, mine):
	print _('if you give me %(yours)s, i will give you %(mine)s')

All well and good and doable in Python today, except getting the
current frame with the exception raising trick is slooow.  A simple
proposed addition to the sys module can improve the performance by
about 8x:

    def _(s):
        frame = sys.getcaller(1)
	d = frame.f_globals.copy()
	d.update(frame.f_locals())
	return the_translation_of(s) % d

The implementation of sys.getcaller() is given in the below patch.
Comments?  I think this particular addition is too small for a PEP,
although ?!ng still owns PEP 215 (which needs filling in).

-Barry

-------------------- snip snip --------------------
Index: sysmodule.c
===================================================================
RCS file: /cvsroot/python/python/dist/src/Python/sysmodule.c,v
retrieving revision 2.78
diff -u -r2.78 sysmodule.c
--- sysmodule.c	2000/09/01 23:29:28	2.78
+++ sysmodule.c	2000/10/24 17:50:30
@@ -15,6 +15,8 @@
 */
 
 #include "Python.h"
+#include "compile.h"
+#include "frameobject.h"
 
 #include "osdefs.h"
 
@@ -284,6 +286,38 @@
 }
 #endif
 
+static char getcaller_doc[] =
+"getcaller([depth]) -> frameobject\n\
+\n\
+By default, return the frame object at the top of the call stack.  If an\n\
+integer depth is given, return the frame object that many calls below the\n\
+top of the stack.  If that is deeper than the call stack, a ValueError is\n\
+raised.";
+
+
+static PyObject *
+sys_getcaller(PyObject *self, PyObject *args)
+{
+	PyFrameObject *f = PyThreadState_Get()->frame;
+	int depth = -1;
+
+	if (!PyArg_ParseTuple(args, "|i:getcaller", &depth))
+		return NULL;
+
+	while (depth > 0 && f != NULL) {
+		f = f->f_back;
+		--depth;
+	}
+	if (f == NULL) {
+		PyErr_SetString(PyExc_ValueError,
+				"call stack is not deep enough");
+		return NULL;
+	}
+	Py_INCREF(f);
+	return (PyObject*)f;
+}
+
+
 #ifdef Py_TRACE_REFS
 /* Defined in objects.c because it uses static globals if that file */
 extern PyObject *_Py_GetObjects(PyObject *, PyObject *);
@@ -313,6 +347,7 @@
 	{"getrefcount",	sys_getrefcount, 1, getrefcount_doc},
 	{"getrecursionlimit", sys_getrecursionlimit, 1,
 	 getrecursionlimit_doc},
+	{"getcaller", sys_getcaller, 1, getcaller_doc},
 #ifdef USE_MALLOPT
 	{"mdebug",	sys_mdebug, 1},
 #endif



From nas at arctrix.com  Tue Oct 24 15:45:35 2000
From: nas at arctrix.com (Neil Schemenauer)
Date: Tue, 24 Oct 2000 06:45:35 -0700
Subject: [Python-Dev] A small step to removing the type/class split
In-Reply-To: <14837.60351.887533.801888@anthem.concentric.net>; from barry@wooz.org on Tue, Oct 24, 2000 at 04:06:23PM -0400
References: <20001024045611.B9993@glacier.fnational.com> <14837.60351.887533.801888@anthem.concentric.net>
Message-ID: <20001024064535.A10253@glacier.fnational.com>

On Tue, Oct 24, 2000 at 04:06:23PM -0400, Barry A. Warsaw wrote:

[on Py_TPLAGS_INSTANCE]
> I'm not sure how well this addresses what I ran into [with a
> boolean extension type].  Would PyBooleanObject then have to
> have it's Py_TPFLAGS_INSTANCE flag set?  Does that actually
> make sense?

I think it would address your problem but I don't know if the
name of the flag makes sense.  Code around PyInstance_Check()
usually looks like this:

    if (PyInstance_Check(obj)) {
        PyObject *foo = PyObject_GetAttrString(obj, "__foo__");
        ...
    }
    else {
        ...
    }

There is not a lot of code that assumes (obj->ob_type ==
PyInstance_Type) after a PyInstance_Check().  That's encouraging.

> How does this interact with the rich comparisons idea?

I don't know.  I think I am trying to a address a deeper problem
here.

> Seems like this is a hack that doesn't quite get at the heart
> of the matter, worthwhile as it may be given the current
> implementation.

Yes, I have that feeling as well.  More deep thinking is probably
required. :)

  Neil




From mal at lemburg.com  Tue Oct 24 22:45:28 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Tue, 24 Oct 2000 22:45:28 +0200
Subject: [Python-Dev] getting at the current frame
References: <14837.60682.437334.797392@anthem.concentric.net>
Message-ID: <39F5F4E8.1188E1E0@lemburg.com>

"Barry A. Warsaw" wrote:
> [...]
> All well and good and doable in Python today, except getting the
> current frame with the exception raising trick is slooow.  A simple
> proposed addition to the sys module can improve the performance by
> about 8x:
> 
>     def _(s):
>         frame = sys.getcaller(1)
>         d = frame.f_globals.copy()
>         d.update(frame.f_locals())
>         return the_translation_of(s) % d
> 
> The implementation of sys.getcaller() is given in the below patch.
> Comments?  I think this particular addition is too small for a PEP,
> although ?!ng still owns PEP 215 (which needs filling in).

+1. 

I have a similar function in mxTools. I would use a different
name though... something like "sys.getframe()".

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From guido at python.org  Tue Oct 24 23:50:32 2000
From: guido at python.org (Guido van Rossum)
Date: Tue, 24 Oct 2000 16:50:32 -0500
Subject: [Python-Dev] A small step to removing the type/class split
In-Reply-To: Your message of "Tue, 24 Oct 2000 04:56:11 MST."
             <20001024045611.B9993@glacier.fnational.com> 
References: <20001024045611.B9993@glacier.fnational.com> 
Message-ID: <200010242150.QAA19518@cj20424-a.reston1.va.home.com>

> I've run into a problem with ExtensionClass which I believe can
> only be fixed by modifying Python.  I will try to explain.
> 
> I have an ExtensionClass which defines __cmp__.  Depending on the
> objects being compared, the __cmp__ method may never be called.
> This is due to code in object.c that looks like this:
> 
>     if (PyInstance_Check(v) || PyInstance_Check(w)) {
>         try to use use __cmp__ method
>     }
>     else {
>         try number coerce and fall back on type name comparison
>     }
> 
> Extension classes can never pass the PyInstance_Check predicate.
> I've searched for all occurances of PyInstance_Check in the 2.0
> source.  In many places that PyInstance_Check occurs a more
> general "is this an instance-like type" check would seem to be
> more suitable.
> 
> Here is my proposal:
> 
>   * Define a new type flag Py_TPFLAGS_INSTANCE.
>   * Create a new predicate Py_IsInstance which checks for this
>     flag.
>   * Set this flag on PyInstance_Type.
>   * Replace most occurances of PyInstance_Check with
>     Py_IsInstance.
> 
> Extension types (like ExtensionClass) can then define the type
> flag Py_TPLAGS_INSTANCE and be treated as an instance type by the
> Python interpreter.  This should make it quite a bit easier to make
> extension types behave like "real" classes.
> 
> Comments?

Good analysis of a problem -- but I disagree on the solution.

Rather than formalizing the exceptions made for instances, we should
work on eradicating the differences between classes and types.  I
believe that the plans for rich comparisons would or could also take
care of this.  I hope I'll have more time soon to explore this.

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



From barry at wooz.org  Tue Oct 24 22:49:04 2000
From: barry at wooz.org (barry at wooz.org)
Date: Tue, 24 Oct 2000 16:49:04 -0400 (EDT)
Subject: [Python-Dev] getting at the current frame
References: <14837.60682.437334.797392@anthem.concentric.net>
	<39F5F4E8.1188E1E0@lemburg.com>
Message-ID: <14837.62912.897422.392307@anthem.concentric.net>

>>>>> "M" == M  <mal at lemburg.com> writes:

    M> I have a similar function in mxTools. I would use a different
    M> name though... something like "sys.getframe()".

Works for me.

Thanks,
-Barry



From guido at python.org  Wed Oct 25 00:16:00 2000
From: guido at python.org (Guido van Rossum)
Date: Tue, 24 Oct 2000 17:16:00 -0500
Subject: [Python-Dev] Re: getting at the current frame
In-Reply-To: Your message of "Tue, 24 Oct 2000 17:04:11 -0400."
             <14837.63819.667508.794728@anthem.concentric.net> 
References: <14837.52425.84457.36757@anthem.concentric.net> <14837.53353.79747.421223@cj42289-a.reston1.va.home.com> <14837.60401.939234.320786@anthem.concentric.net> <200010242155.QAA19570@cj20424-a.reston1.va.home.com>  
            <14837.63819.667508.794728@anthem.concentric.net> 
Message-ID: <200010242216.RAA19692@cj20424-a.reston1.va.home.com>

>     GvR> Agreed.  I think it's good to have the functionality
>     GvR> available, but it's also good to make it *real* clear not to
>     GvR> mess with it unless you really know what you're doing.  Maybe
>     GvR> it should be in a separate module or at least have a leading
>     GvR> _underscore.
> 
> I think you're fairly safe from mischief since the only writable
> attributes of a frame object are f_trace, f_exc_type, f_exc_value, and
> f_exc_traceback.  The same caveats about f_globals and f_locals apply
> as with the dicts returned by locals() and globals().

It's not so much that it's easy to do damage with.  I have a
philosophical problem with making this a feature that people can use
whenever they feel like.  It's a messy feature and its use should
limited as an implementation aid for language features like variable
substitution.

The other, perhaps more major, problem with this it is that you can't
easily wrap functions that use it in other functions.  Normally, if
there's a function foo(arg) that does something, I can write a
function wrapfoo(arg) that does something else, then calls foo(arg),
and then does another thing.  But if foo() uses getframe(), that's not
so easy: the call to foo() in wrapfoo() will access wrapfoo()'s frame.

A way around this would be to implement foo as a call to (e.g.)
_foo(arg, frame), and define foo(arg) as _foo(arg, sys.getframe()).
Then _wrapfoo(arg, frame) could be defined as a wrapper around
_foo(arg, frame) and wrapfoo(arg) as _wrapfoo(arg, sys.getframe()).

This is another reason to be very selective in the use of getframe().

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



From nas at arctrix.com  Tue Oct 24 16:37:12 2000
From: nas at arctrix.com (Neil Schemenauer)
Date: Tue, 24 Oct 2000 07:37:12 -0700
Subject: [Python-Dev] A small step to removing the type/class split
In-Reply-To: <200010242150.QAA19518@cj20424-a.reston1.va.home.com>; from guido@python.org on Tue, Oct 24, 2000 at 04:50:32PM -0500
References: <20001024045611.B9993@glacier.fnational.com> <200010242150.QAA19518@cj20424-a.reston1.va.home.com>
Message-ID: <20001024073712.A10539@glacier.fnational.com>

On Tue, Oct 24, 2000 at 04:50:32PM -0500, Guido van Rossum wrote:
> Rather than formalizing the exceptions made for instances, we
> should work on eradicating the differences between classes and
> types.

Yes, I see this now.  Those PyInstance_Check() calls should
really go away.  Instead, the type should be responsible for
providing different behavior.

> I believe that the plans for rich comparisons would or could
> also take care of this.

I've just briefly looked at the proposal.  It consists of two
parts.  One is splitting __cmp__ into __gt__, __lt__, etc.  That
is a separate issue to the one we are dicussing.  The other part
is directly related.  In order for types to define their own
comparison behavior, it proposes that types have an optional
pointer to a rich comparison function in the type structure.  I
think this is the right idea but it doesn't go far enough.  Every
operation should be implementable by the type.  Code like:

    if (PyString_Check(obj)) {
        something
    }
    else if (PyInstance_Check(obj)) {
        something else
    }
    ...

should disappear unless it is need for performance reasons.  I
think we are close to achieving this goal.  I'll try to come up
with a proposal.

  Neil



From barry at wooz.org  Tue Oct 24 23:34:54 2000
From: barry at wooz.org (barry at wooz.org)
Date: Tue, 24 Oct 2000 17:34:54 -0400 (EDT)
Subject: [Python-Dev] Re: getting at the current frame
References: <14837.52425.84457.36757@anthem.concentric.net>
	<14837.53353.79747.421223@cj42289-a.reston1.va.home.com>
	<14837.60401.939234.320786@anthem.concentric.net>
	<200010242155.QAA19570@cj20424-a.reston1.va.home.com>
	<14837.63819.667508.794728@anthem.concentric.net>
	<200010242216.RAA19692@cj20424-a.reston1.va.home.com>
Message-ID: <14838.126.77589.541148@anthem.concentric.net>

>>>>> "GvR" == Guido van Rossum <guido at python.org> writes:

    GvR> The other, perhaps more major, problem with this it is that
    GvR> you can't easily wrap functions that use it in other
    GvR> functions.  Normally, if there's a function foo(arg) that
    GvR> does something, I can write a function wrapfoo(arg) that does
    GvR> something else, then calls foo(arg), and then does another
    GvR> thing.  But if foo() uses getframe(), that's not so easy: the
    GvR> call to foo() in wrapfoo() will access wrapfoo()'s frame.

    GvR> A way around this would be to implement foo as a call to
    GvR> (e.g.)  _foo(arg, frame), and define foo(arg) as _foo(arg,
    GvR> sys.getframe()).  Then _wrapfoo(arg, frame) could be defined
    GvR> as a wrapper around _foo(arg, frame) and wrapfoo(arg) as
    GvR> _wrapfoo(arg, sys.getframe()).

Darn good point.  So where could we put it?  It's a useful
introspection device.  If it goes in a separate module, should that
perhaps be called `reflection'?  Or maybe `runtime'?  Or maybe
"sys._getframe()" is good enough.

-Barry



From guido at python.org  Wed Oct 25 01:13:43 2000
From: guido at python.org (Guido van Rossum)
Date: Tue, 24 Oct 2000 18:13:43 -0500
Subject: [Python-Dev] Re: getting at the current frame
In-Reply-To: Your message of "Tue, 24 Oct 2000 17:34:54 -0400."
             <14838.126.77589.541148@anthem.concentric.net> 
References: <14837.52425.84457.36757@anthem.concentric.net> <14837.53353.79747.421223@cj42289-a.reston1.va.home.com> <14837.60401.939234.320786@anthem.concentric.net> <200010242155.QAA19570@cj20424-a.reston1.va.home.com> <14837.63819.667508.794728@anthem.concentric.net> <200010242216.RAA19692@cj20424-a.reston1.va.home.com>  
            <14838.126.77589.541148@anthem.concentric.net> 
Message-ID: <200010242313.SAA19938@cj20424-a.reston1.va.home.com>

> Darn good point.  So where could we put it?  It's a useful
> introspection device.  If it goes in a separate module, should that
> perhaps be called `reflection'?  Or maybe `runtime'?  Or maybe
> "sys._getframe()" is good enough.

sys._getframe() is good enough.

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



From DavidA at ActiveState.com  Wed Oct 25 01:08:28 2000
From: DavidA at ActiveState.com (David Ascher)
Date: Tue, 24 Oct 2000 16:08:28 -0700 (Pacific Daylight Time)
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: <14837.43273.24692.93965@buffalo.fnal.gov>
Message-ID: <Pine.WNT.4.21.0010241517480.1584-100000@loom>

> Back in my former life, when I was still worrying about Windows, the
> company I worked for bought into a commerical x-platform GUI toolkit
> called Galaxy (I mentioned this earlier).  Galaxy re-implemented all
> the native widgets, kind of like XPFE does.  One issue with this was
> that MS seemed to change something about the widgets in every release
> - e.g. the Galaxy filechooser looked like Windows 3.1, then Win95 came
> out and Galaxy had to play catch-up.  Once Galaxy had the Win95 LAF,
> Win98 came out.  Now I hear there's something called Windows ME.  Have
> they changed the look-and-feel again?  Seems to me like all the
> widget-reimplementors are doomed to playing eternal catch-up.

Back in a former life of _mine_, I was one of two people who understood
the architecture of Neuron Data's Open Interface Toolkit.  It used the
same strategy.  Not sure what that has to do with Python, though it was
a very fun project.  It was also fun to turn on the Mac 'theme' on a
Decwindows box (we're talking 1989 or so =).

The funniest story about that job involves Cray and black and white
monitors, but that's a story for another time, another place.

--da




From greg at cosc.canterbury.ac.nz  Wed Oct 25 01:18:59 2000
From: greg at cosc.canterbury.ac.nz (Greg Ewing)
Date: Wed, 25 Oct 2000 12:18:59 +1300 (NZDT)
Subject: [Python-Dev] Why not revive stdwin?
In-Reply-To: <20001023162118.B18005@kronos.cnri.reston.va.us>
Message-ID: <200010242318.MAA28238@s454.cosc.canterbury.ac.nz>

Andrew Kuchling <akuchlin at mems-exchange.org>:

> It seems to me that supporting MacOS is the big problem for
> cross-platform GUIs.

It appears that we can't rely on anyone else to provide and
support a GUI properly across all three platforms. If we
want one, it looks like we'll have to do it ourselves.

How about reviving and building upon stdwin? I quite liked
stdwin, despite its limitations, because it was small and simple,
and it worked on both Mac and Unix.

Greg Ewing, Computer Science Dept, +--------------------------------------+
University of Canterbury,	   | A citizen of NewZealandCorp, a	  |
Christchurch, New Zealand	   | wholly-owned subsidiary of USA Inc.  |
greg at cosc.canterbury.ac.nz	   +--------------------------------------+



From est at hyperreal.org  Tue Oct 24 23:58:43 2000
From: est at hyperreal.org (est at hyperreal.org)
Date: Tue, 24 Oct 2000 14:58:43 -0700 (PDT)
Subject: [Python-Dev] Re: getting at the current frame
In-Reply-To: <14838.126.77589.541148@anthem.concentric.net> from "barry@wooz.org"
 at "Oct 24, 2000 05:34:54 pm"
Message-ID: <20001024215843.7507.qmail@hyperreal.org>

barry at wooz.org discourseth:
> 
> Darn good point.  So where could we put it?  It's a useful
> introspection device.  If it goes in a separate module, should that
> perhaps be called `reflection'?  Or maybe `runtime'?  Or maybe
> "sys._getframe()" is good enough.

Hmm..I'd think `reification' instead of `reflection'.  My
understanding was that reification involves taking an implicit
language entity and making it an expressed value (e.g., getframe() or
call_with_current_continuation()) while reflection goes in the
opposite direction (e.g., eval()).

pedantically,

e



From greg at cosc.canterbury.ac.nz  Wed Oct 25 03:14:52 2000
From: greg at cosc.canterbury.ac.nz (Greg Ewing)
Date: Wed, 25 Oct 2000 14:14:52 +1300 (NZDT)
Subject: [Python-Dev] A small step to removing the type/class split
In-Reply-To: <20001024073712.A10539@glacier.fnational.com>
Message-ID: <200010250114.OAA28255@s454.cosc.canterbury.ac.nz>

Neil Schemenauer <nas at arctrix.com>:

> Those PyInstance_Check() calls should really go away. Instead, the
> type should be responsible for providing different behavior.

Yes, that's the crux of the problem, I think.

Another place where this is a nuisance is where it
assumes that if x has any tp_as_sequence slots and y
has any tp_as_number slots, then x*y is a sequence
replication operation.

Greg Ewing, Computer Science Dept, +--------------------------------------+
University of Canterbury,	   | A citizen of NewZealandCorp, a	  |
Christchurch, New Zealand	   | wholly-owned subsidiary of USA Inc.  |
greg at cosc.canterbury.ac.nz	   +--------------------------------------+




From esr at thyrsus.com  Wed Oct 25 06:56:27 2000
From: esr at thyrsus.com (Eric S. Raymond)
Date: Tue, 24 Oct 2000 21:56:27 -0700
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: <005f01c03ddc$dd52bb60$3c6340d5@hagrid>; from effbot@telia.com on Tue, Oct 24, 2000 at 06:59:23PM +0200
References: <14837.14407.954185.466011@buffalo.fnal.gov> <ECEPKNMJLHAPFFJHDOJBKEKIDOAA.MarkH@ActiveState.com> <14837.43273.24692.93965@buffalo.fnal.gov> <20001024114326.E13957@kronos.cnri.reston.va.us> <005f01c03ddc$dd52bb60$3c6340d5@hagrid>
Message-ID: <20001024215627.B1147@thyrsus.com>

Fredrik Lundh <effbot at telia.com>:
> > Can someone articulate why Tk should be replaced?
> 
> beats me ;-)

My main reason is that Tcl is in trouble, and I fear Tcl/Tk may become
effectively unmaintained in the foreseeable future.
-- 
		<a href="http:///~esr/">Eric S. Raymond</a>

Rapists just *love* unarmed women.  And the politicians who disarm them.



From esr at thyrsus.com  Wed Oct 25 07:29:17 2000
From: esr at thyrsus.com (Eric S. Raymond)
Date: Tue, 24 Oct 2000 22:29:17 -0700
Subject: [Python-Dev] Why not revive stdwin?
In-Reply-To: <200010242318.MAA28238@s454.cosc.canterbury.ac.nz>; from greg@cosc.canterbury.ac.nz on Wed, Oct 25, 2000 at 12:18:59PM +1300
References: <20001023162118.B18005@kronos.cnri.reston.va.us> <200010242318.MAA28238@s454.cosc.canterbury.ac.nz>
Message-ID: <20001024222917.I1147@thyrsus.com>

Greg Ewing <greg at cosc.canterbury.ac.nz>:
> It appears that we can't rely on anyone else to provide and
> support a GUI properly across all three platforms. If we
> want one, it looks like we'll have to do it ourselves.

I fear this is much too big a job to be practical -- not just in the
additional code but the downstream maintainance.
-- 
		<a href="http:///~esr/">Eric S. Raymond</a>

"I hold it, that a little rebellion, now and then, is a good thing, and as 
necessary in the political world as storms in the physical."
	-- Thomas Jefferson, Letter to James Madison, January 30, 1787



From barry at wooz.org  Wed Oct 25 05:11:54 2000
From: barry at wooz.org (Barry A. Warsaw)
Date: Tue, 24 Oct 2000 23:11:54 -0400 (EDT)
Subject: [Python-Dev] Re: getting at the current frame
References: <14837.52425.84457.36757@anthem.concentric.net>
	<14837.53353.79747.421223@cj42289-a.reston1.va.home.com>
	<14837.60401.939234.320786@anthem.concentric.net>
	<200010242155.QAA19570@cj20424-a.reston1.va.home.com>
	<14837.63819.667508.794728@anthem.concentric.net>
	<200010242216.RAA19692@cj20424-a.reston1.va.home.com>
	<14838.126.77589.541148@anthem.concentric.net>
	<200010242313.SAA19938@cj20424-a.reston1.va.home.com>
Message-ID: <14838.20346.451094.231019@anthem.concentric.net>

>>>>> "GvR" == Guido van Rossum <guido at python.org> writes:

    GvR> sys._getframe() is good enough.

Cool, I'll upload the patch to SF.

-Barry



From barry at wooz.org  Wed Oct 25 05:44:10 2000
From: barry at wooz.org (Barry A. Warsaw)
Date: Tue, 24 Oct 2000 23:44:10 -0400 (EDT)
Subject: [Python-Dev] Re: getting at the current frame
References: <14837.52425.84457.36757@anthem.concentric.net>
	<14837.53353.79747.421223@cj42289-a.reston1.va.home.com>
	<14837.60401.939234.320786@anthem.concentric.net>
	<200010242155.QAA19570@cj20424-a.reston1.va.home.com>
	<14837.63819.667508.794728@anthem.concentric.net>
	<200010242216.RAA19692@cj20424-a.reston1.va.home.com>
	<14838.126.77589.541148@anthem.concentric.net>
	<200010242313.SAA19938@cj20424-a.reston1.va.home.com>
	<14838.20346.451094.231019@anthem.concentric.net>
Message-ID: <14838.22282.676715.200546@anthem.concentric.net>

>>>>> "BAW" == Barry A Warsaw <barry at wooz.org> writes:

>>>>> "GvR" == Guido van Rossum <guido at python.org> writes:

    GvR> sys._getframe() is good enough.

    BAW> Cool, I'll upload the patch to SF.

Patch #102106

http://sourceforge.net/patch/?func=detailpatch&patch_id=102106&group_id=5470

(includes doc patch)

-Barry



From tim_one at email.msn.com  Wed Oct 25 09:10:36 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Wed, 25 Oct 2000 03:10:36 -0400
Subject: [Python-Dev] Gradual migration
In-Reply-To: <39F54C0F.25798309@lemburg.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCMELHHMAA.tim_one@email.msn.com>

[MAL]
> ...
> I think will simply be a consequence of doing a complete rewrite
> of the interpreter for Py3K.

Not just to be my usual self <wink>, but I do see a from-scratch rewrite as
being less likely as the years go by.  There's nothing I know of in Guido's
plans that can't be done incrementally instead -- and if he doesn't either,
selling a total- rewrite project to an employer is probably impossible.

The most successful projects I've seen and been on *did* rewrite all the
code routinely, but one subsystem at a time.  This happens when you're
tempted to add a hack, realize it wouldn't be needed if an entire area were
reworked, and mgmt is bright enough to realize that hacks compound in fatal
ways over time.  The "ain't broke, don't fix" philosophy is a good guide
here, provided you've got a very low threshold for insisting "it's broke"
<0.4 wink>.

if-you-would-have-liked-to-do-the-whole-differently-then-by-all-means-
    *do*-the-whole-thing-differently-that-works-in-c-too-ly y'rs  - tim





From moshez at math.huji.ac.il  Wed Oct 25 09:49:21 2000
From: moshez at math.huji.ac.il (Moshe Zadka)
Date: Wed, 25 Oct 2000 09:49:21 +0200 (IST)
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: <200010241739.MAA16414@cj20424-a.reston1.va.home.com>
Message-ID: <Pine.GSO.4.10.10010250923490.9960-100000@sundial>

On Tue, 24 Oct 2000, Guido van Rossum wrote:

> Maybe we can do the same for Unix binary distributions?

I don't know what you mean by "UNIX" binary distributions: each UNIX
has its own sets of horrors in the distribution arena. Personally, I
don't care what we do about RPMs, since I'm not a Red Hat user. However,
this should probably be more Red Hat's job then ours. Debian, on the
other hand, would probably do this much better then Python-Dev can,
without gratutitous Tcl/Tk installations. For other unices, most people
install from sources anyway, which mostly means I should get off my butt
and start working on the Sumo interpreter.

> Really?  Are you sure that's not just general resistence against new
> things?  To me, and I suspect may others, the app I use most often on
> Windows is Netscape -- talk about lack of native look-and-feel!  It's
> never bothered me all that much.

I don't know how to break this to you, but you're not the average computer
user <wink>.

--
Moshe Zadka <moshez at math.huji.ac.il>
There is no IGLU cabal.
http://advogato.org/person/moshez




From mal at lemburg.com  Wed Oct 25 10:10:46 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Wed, 25 Oct 2000 10:10:46 +0200
Subject: [Python-Dev] Gradual migration
References: <LNBBLJKPBEHFEDALKOLCMELHHMAA.tim_one@email.msn.com>
Message-ID: <39F69586.E017DA7E@lemburg.com>

Tim Peters wrote:
> 
> [MAL]
> > ...
> > I think this will simply be a consequence of doing a complete rewrite
> > of the interpreter for Py3K.
> 
> Not just to be my usual self <wink>, but I do see a from-scratch rewrite as
> being less likely as the years go by.  There's nothing I know of in Guido's
> plans that can't be done incrementally instead -- and if he doesn't either,
> selling a total- rewrite project to an employer is probably impossible.
>
> The most successful projects I've seen and been on *did* rewrite all the
> code routinely, but one subsystem at a time.  This happens when you're
> tempted to add a hack, realize it wouldn't be needed if an entire area were
> reworked, and mgmt is bright enough to realize that hacks compound in fatal
> ways over time.  The "ain't broke, don't fix" philosophy is a good guide
> here, provided you've got a very low threshold for insisting "it's broke"
> <0.4 wink>.

As I mentioned in the posting, the idea was from the "fluffy clouds"
area. The rewrite would only involve the core type system and perhaps
the core interpreter layout (parser, compiler, etc. all wrapped in
classes) -- most of the existing code would be reusable. 

The idea behind this is somewhat like what you do when starting out a
project based on a few simple functions and then reorganizing the
code into a class-based approach. There's no need to rewrite all 
the type internals, just the type interfaces. 

Python has long reached a level of complexity that is counter-
productive when it comes to adding new extension types. Just
think of all the problems people have with coercion, the integration
of user defined and internal types, the missing links between
types and classes, etc. etc.  

BTW, why all the talk about "employers" ? Much of Python's code
base was written without any employer knowing about it ;-)

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From jim at interet.com  Wed Oct 25 12:40:56 2000
From: jim at interet.com (James C. Ahlstrom)
Date: Wed, 25 Oct 2000 06:40:56 -0400
Subject: [Python-Dev] What to choose to replace Tkinter?
References: <14837.14407.954185.466011@buffalo.fnal.gov> <ECEPKNMJLHAPFFJHDOJBKEKIDOAA.MarkH@ActiveState.com> <14837.43273.24692.93965@buffalo.fnal.gov> <20001024114326.E13957@kronos.cnri.reston.va.us>
Message-ID: <39F6B8B8.E3242929@interet.com>

Andrew Kuchling wrote:

> Can someone articulate why Tk should be replaced?

I don't know whether Tk should replaced, but I
can explain why I don't use it for our commercial
Python application.

It is just too big and complicated.  Windows comes
with a built-in GUI, and I hesitate to install
another scripting language (Tcl) and its libraries,
and then install a big system which has frequently been
out of phase with Python releases just to access the
Windows GUI.

What if a user calls with a problem?  Why should I
have to debug their Tcl library path problems?  No
thanks.

JimA



From jim at interet.com  Wed Oct 25 12:47:05 2000
From: jim at interet.com (James C. Ahlstrom)
Date: Wed, 25 Oct 2000 06:47:05 -0400
Subject: [Python-Dev] What to choose to replace Tkinter?
References: <Pine.LNX.4.10.10010241146450.6622-100000@akbar.nevex.com> <200010241739.MAA16414@cj20424-a.reston1.va.home.com>
Message-ID: <39F6BA29.3CAB4C0E@interet.com>

Guido van Rossum wrote:

> > 2. (Lack of) native look and feel.  This is a complete show-stopper for
> >    many of the outfits I've dealt with (and not just with Python).
> 
> Really?  Are you sure that's not just general resistence against new
> things?  To me, and I suspect may others, the app I use most often on
> Windows is Netscape -- talk about lack of native look-and-feel!  It's
> never bothered me all that much.

In the past I have resolutely demanded native Windows look
and feel in my apps.  In fact, I have been tiresome on the topic.

Now I am changing my mind.  Lots of prominent Windows apps now
depart from Microsoft LAF, and I have the impression that users
are getting used to it.  I still think the usual File menu
items and file open/save dialogs should be standard, but I
am less concerned about other controls.  For a look
at how to really do controls, check out software for
kids.  Just my 1.e-2$.

JimA



From guido at python.org  Wed Oct 25 14:11:35 2000
From: guido at python.org (Guido van Rossum)
Date: Wed, 25 Oct 2000 07:11:35 -0500
Subject: [Python-Dev] Why not revive stdwin?
In-Reply-To: Your message of "Tue, 24 Oct 2000 22:29:17 MST."
             <20001024222917.I1147@thyrsus.com> 
References: <20001023162118.B18005@kronos.cnri.reston.va.us> <200010242318.MAA28238@s454.cosc.canterbury.ac.nz>  
            <20001024222917.I1147@thyrsus.com> 
Message-ID: <200010251211.HAA22128@cj20424-a.reston1.va.home.com>

> Greg Ewing <greg at cosc.canterbury.ac.nz>:
> > It appears that we can't rely on anyone else to provide and
> > support a GUI properly across all three platforms. If we
> > want one, it looks like we'll have to do it ourselves.

Eric Raymond:
> I fear this is much too big a job to be practical -- not just in the
> additional code but the downstream maintainance.

Well said.  The "roll your own" approach has been attempted before,
but simply isn't worth the time and effort.  After all, Python is a
glue language!

(And stdwin would really look pathetic in this time.)

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



From guido at python.org  Wed Oct 25 14:25:29 2000
From: guido at python.org (Guido van Rossum)
Date: Wed, 25 Oct 2000 07:25:29 -0500
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: Your message of "Wed, 25 Oct 2000 06:40:56 -0400."
             <39F6B8B8.E3242929@interet.com> 
References: <14837.14407.954185.466011@buffalo.fnal.gov> <ECEPKNMJLHAPFFJHDOJBKEKIDOAA.MarkH@ActiveState.com> <14837.43273.24692.93965@buffalo.fnal.gov> <20001024114326.E13957@kronos.cnri.reston.va.us>  
            <39F6B8B8.E3242929@interet.com> 
Message-ID: <200010251225.HAA22242@cj20424-a.reston1.va.home.com>

> Andrew Kuchling wrote:
> 
> > Can someone articulate why Tk should be replaced?

Jim Ahlstrom replied:

> I don't know whether Tk should replaced, but I
> can explain why I don't use it for our commercial
> Python application.
> 
> It is just too big and complicated.  Windows comes
> with a built-in GUI, and I hesitate to install
> another scripting language (Tcl) and its libraries,
> and then install a big system which has frequently been
> out of phase with Python releases just to access the
> Windows GUI.

To me this all sounds like FUD.  Since Python 1.6 and 2.0, you don't
have to install Tcl/Tk or its libraries -- it is installed
*transparently* by the Python Windows installer.  That's different --
and better -- than what happened in 1.5.2, where a separate Tcl/Tk
installer was optionally run.  The version issues are also resolved
this way: you are guaranteed to get exactly the Tcl/Tk version that
was tested by the developers.

> What if a user calls with a problem?  Why should I
> have to debug their Tcl library path problems?  No
> thanks.

The Tcl library paths are all taken care of by the new installer
strategy.

Really, give it a try.  It Just Works! (SM)

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



From guido at python.org  Wed Oct 25 14:27:28 2000
From: guido at python.org (Guido van Rossum)
Date: Wed, 25 Oct 2000 07:27:28 -0500
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: Your message of "Wed, 25 Oct 2000 06:47:05 -0400."
             <39F6BA29.3CAB4C0E@interet.com> 
References: <Pine.LNX.4.10.10010241146450.6622-100000@akbar.nevex.com> <200010241739.MAA16414@cj20424-a.reston1.va.home.com>  
            <39F6BA29.3CAB4C0E@interet.com> 
Message-ID: <200010251227.HAA22256@cj20424-a.reston1.va.home.com>

> In the past I have resolutely demanded native Windows look
> and feel in my apps.  In fact, I have been tiresome on the topic.
> 
> Now I am changing my mind.  Lots of prominent Windows apps now
> depart from Microsoft LAF, and I have the impression that users
> are getting used to it.  I still think the usual File menu
> items and file open/save dialogs should be standard, but I
> am less concerned about other controls.  For a look
> at how to really do controls, check out software for
> kids.  Just my 1.e-2$.

Even Microsoft is violating its own (boring) style guide, when they
think it appeals to a specific audience.  Have you seen their Media
Player?

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



From jim at digicool.com  Wed Oct 25 14:21:41 2000
From: jim at digicool.com (Jim Fulton)
Date: Wed, 25 Oct 2000 08:21:41 -0400
Subject: [Python-Dev] A small step to removing the type/class split
References: <20001024045611.B9993@glacier.fnational.com> <200010242150.QAA19518@cj20424-a.reston1.va.home.com>
Message-ID: <39F6D055.584C4FEA@digicool.com>

Guido van Rossum wrote:
> 
(snip)
> Rather than formalizing the exceptions made for instances, we should
> work on eradicating the differences between classes and types. 

Yee ha! I couldn't agree more. :)

> I believe that the plans for rich comparisons would or could also take
> care of this. 

I assume that rich comparison's have new slots with signatures
that don't assume objects of the same type.

> I hope I'll have more time soon to explore this.

Me too.

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 jim at digicool.com  Wed Oct 25 14:25:53 2000
From: jim at digicool.com (Jim Fulton)
Date: Wed, 25 Oct 2000 08:25:53 -0400
Subject: [Python-Dev] A small step to removing the type/class split
References: <20001024045611.B9993@glacier.fnational.com>
Message-ID: <39F6D151.70F47CFF@digicool.com>

Neil Schemenauer wrote:
> 
> I've run into a problem with ExtensionClass which I believe can
> only be fixed by modifying Python.  I will try to explain.
> 
> I have an ExtensionClass which defines __cmp__.  Depending on the
> objects being compared, the __cmp__ method may never be called.
> This is due to code in object.c that looks like this:
> 
>     if (PyInstance_Check(v) || PyInstance_Check(w)) {
>         try to use use __cmp__ method
>     }
>     else {
>         try number coerce and fall back on type name comparison
>     }
> 
> Extension classes can never pass the PyInstance_Check predicate.
> I've searched for all occurances of PyInstance_Check in the 2.0
> source.  In many places that PyInstance_Check occurs a more
> general "is this an instance-like type" check would seem to be
> more suitable.
> 
> Here is my proposal:

(snip)

I think you got some good answers later in the thread.

I'll point out that a work around is to make your ExtensionClass
a numeric type.  Numeric types have different comparison 
semantics that allow you to get around this limitation.
I did this a few months back for acquisition wrappers.

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 gvwilson at nevex.com  Wed Oct 25 14:38:12 2000
From: gvwilson at nevex.com (Greg Wilson)
Date: Wed, 25 Oct 2000 08:38:12 -0400 (EDT)
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: <200010241904.OAA19165@cj20424-a.reston1.va.home.com>
Message-ID: <Pine.LNX.4.10.10010250820030.2415-100000@akbar.nevex.com>

> Guido van Rossum:
> Can you elaborate on the line of argument that you typically hear
> [objections to Tkinter]? What do you say to dispel it?


From guido at python.org  Wed Oct 25 15:53:48 2000
From: guido at python.org (Guido van Rossum)
Date: Wed, 25 Oct 2000 08:53:48 -0500
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: Your message of "Wed, 25 Oct 2000 08:38:12 -0400."
             <Pine.LNX.4.10.10010250820030.2415-100000@akbar.nevex.com> 
References: <Pine.LNX.4.10.10010250820030.2415-100000@akbar.nevex.com> 
Message-ID: <200010251353.IAA28190@cj20424-a.reston1.va.home.com>

> From some feedback forms from old runs of my Python course (with spelling
> corrections :-)
> 
> 1. "My users don't care what programs are written in.  They just care
>    if they're easy to use.  They won't care if Python programs have
>    the same look and feel on different computers, because they won't
>    ever think of [name of program] as a Python program.  To them, it
>    will be a Windows program that looks funny."
> 
> 2. "You said three times in the intro lecture this morning that the
>    most important thing in a GUI was consistency.  Then you told us to
>    write GUIs that look different from everything else on the desktop."
> 
> 3. "I'm confused: I didn't realize that Python was a library on top of
>    TCL."
> 
> I spent a minute drawing blob diagrams to answer #3; I think most students
> understood, but the person who asked the question was clearly still confused.
> 
> I didn't try to dispel #1 or #2, because I agree with them: my
> experience is that consistent look and feel are crucial for making
> non-programmers less afraid of pressing the wrong button or making
> the program "do weird things".  Other people with more experience
> creating end-user applications may have different views.

This is helpful.  Can you elaborate on what elements of the Windows
look-and-feel are missing in Tkinter?  As far as I know, the menu
bars, file selection dialogs, scroll bars, dialog boxes and so on have
a thoroughly native look-and-feel, since Tk implements these as
wrappers around the native widgets.  IDLE doesn't look very different
from Notepad!

So what's missing?  A toolbar with icons?  That would be easy to add
using existing Tk controls (Pmw has it too).  The multiple document
interface?  It sucks -- and even Word 2000 has gone away from that!

What kind of GUIs did you teach them exactly?  If you started with
basic Tkinter widgets, sure, it looks different than anything else.
But that depends on the widget layout in the program, not on the
widget library used!

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



From barry at scottb.demon.co.uk  Wed Oct 25 15:55:40 2000
From: barry at scottb.demon.co.uk (Barry Scott)
Date: Wed, 25 Oct 2000 14:55:40 +0100
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: <200010251353.IAA28190@cj20424-a.reston1.va.home.com>
Message-ID: <002301c03e8b$42cbc280$060210ac@private>

I choose to use wxPython over TK because:

1. wxPython has a reasonable event model
2. wxPython allows me build one object hierarchy
3. TK requires I manage two object hierarchies, TK's and my classes
4. Hooking events to TK seems clumsy from Python

As others have said better docs on wxPython would be nice
and its to easy to crash the world from wxPython.

		Barry




From claird at starbase.neosoft.com  Wed Oct 25 16:58:53 2000
From: claird at starbase.neosoft.com (Cameron Laird)
Date: Wed, 25 Oct 2000 09:58:53 -0500 (CDT)
Subject: [Python-Dev] Miscellaneous comments on Tkinter and related matters
Message-ID: <200010251458.JAA77237@starbase.neosoft.com>

I can rarely afford to dip into Python-Dev.  My head is exploding
too much of the time as it is.

Maybe I can help with the recent Tkinter discussions, though.
1.  Tcl's going to be around for a long time.
    Here's the insider scoop on what the Ajuba
    Solutions announcement means:  insiders
    don't know.  That is, *nobody* is sure how
    Tcl will develop.

    It'll survive, though, for quite a while.
    Do NOT worry that it'll suddenly dry up
    and blow away.

    I'm working on a more detailed explanation
    of Tcl processes.  It'll probably take a
    few weeks, though.  In the meantime, just
    ignore the mess, and understand that the
    Tcl Core Team includes bright people who'll
    land on their feet somehow.
2.  I agree that MacOS is the thorny problem for
    the standard Pysolution.  I'd be happy to
    discuss the possibilities (Tkinter?  wxWindows?
    Qt?!? GTK+?!!?!? ...) with a smaller group,
    and, of course, Fredrik, Robin, Guido, ...
    all are quite knowledgeable about these
    matters.

    There are a few things you should know about
    the Tcl side.  The bad is that Tk is barely
    maintained for MacOS.  It's really rather
    miserable.  On the other hand, Jim Ingham is
    now an Apple employee, and things could change
    in a hurry, at any time.

    The good is that Tk starts far ahead of any
    competitor.  It has already solved most of
    the hard problems.  All it needs is a little
    maintenance.
3.  Is there a way to have Tk without contamination
    by Tcl?  More than ever.  This is what makes me
    most cheerful about Tkinter's prospects.  The
    Tcl Core Team has largely given up its hangups
    about co-operating with foreigners (or its
    hangups that barbarians have hangups about co-
    operating with Tcl).  This is a *very* good
    time for someone like Fredrik to establish a
    working relationship, and get CVS access.  I
    really think Tk can be maintained by a different
    group than Tcl.

    Perl, Ruby, ... folks are also receptive to the
    idea (I've talked with them).  For pointers to
    some of what's happening in this area, see
    <URL:http://starbase.neosoft.com/~claird/comp.lang.misc/core_enhancement.html>

    Also, you should know that my favorite enhancement
    to Tk is a remodularization called TkGS.  This
    should improve performance under Win*, make it
    more portable to BeOS, improve access by Python,
    and so on.
4.  Greg's right that some publishers are dumping Tcl.
    Not all, though.  If it matters, we can go into
    details.
5.  Pango is indeed cool, but it's different from
    [text].  The world is probably moving to Pango and
    similar implementations.  The world will be missing
    much of what [text] offers.
6.  ANYONE with an urge to get out a Python-related
    idea should pursue it.  *DDJ*'s a great outlet.
    It's far from the only one.  If people have ideas
    about articles, but are held back by lack of time/
    fluency/contacts/..., *please* get in touch with
    me.  I'll find a way at least to give articles a
    fair chance at being published.

Cameron Laird       <claird at NeoSoft.com>       +1 281 996 8546 FAX
http://starbase.neosoft.com/~claird/misc.writing/publications.html



From cgw at fnal.gov  Wed Oct 25 17:31:38 2000
From: cgw at fnal.gov (Charles G Waldman)
Date: Wed, 25 Oct 2000 10:31:38 -0500 (CDT)
Subject: [Python-Dev] Miscellaneous comments on Tkinter and related matters
In-Reply-To: <200010251458.JAA77237@starbase.neosoft.com>
References: <200010251458.JAA77237@starbase.neosoft.com>
Message-ID: <14838.64730.225260.148853@buffalo.fnal.gov>

Cameron Laird writes:
 > I can rarely afford to dip into Python-Dev.  My head is exploding
 > too much of the time as it is.
 > 
 > Maybe I can help with the recent Tkinter discussions, though.

 > 2.  I agree that MacOS is the thorny problem for
 >     the standard Pysolution. 

What is the impact of the fact that MacOS X will run X?  Doesn't this
open the door to a lot of new possibilities, at least if we don't need
to support Mac OS[6-9].  Or is the installed base of MacOS[6-9] just
way too big to even think about dropping (or deprecating) support for
it?



From tim_one at email.msn.com  Wed Oct 25 18:23:30 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Wed, 25 Oct 2000 12:23:30 -0400
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: <200010251225.HAA22242@cj20424-a.reston1.va.home.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCIEMOHMAA.tim_one@email.msn.com>

[Guido, on finding Tcl/Tk under Windows]
> To me this all sounds like FUD.  Since Python 1.6 and 2.0, you don't
> have to install Tcl/Tk or its libraries -- it is installed
> *transparently* by the Python Windows installer.  That's different --
> and better -- than what happened in 1.5.2, where a separate Tcl/Tk
> installer was optionally run.  The version issues are also resolved
> this way: you are guaranteed to get exactly the Tcl/Tk version that
> was tested by the developers.

Unless you're Fredrik, alas <wink>.  Apparently Tcl still honors library
envars first if they exist, and if some other installation or use of Tcl/Tk
set those, you can still end up w/ a mix. *Much* better than before, though,
and I don't recall ay instance of this happening in real life so far apart
from /F (who had no problem figuring it out, of course).

>> What if a user calls with a problem?  Why should I
>> have to debug their Tcl library path problems?  No
>> thanks.

> The Tcl library paths are all taken care of by the new installer
> strategy.
>
> Really, give it a try.  It Just Works! (SM)

I'll second that!  "Mystery startup errors" from the Python+Tcl+Tk+Windows
combo were at least weekly questions on c.l.py for 1.5.2, often daily.  I've
seen none for 1.6 or 2.0.

and-all-it-took-was-avoiding-ms's-recommended-practices<wink>-ly y'rs  - tim





From guido at python.org  Wed Oct 25 19:46:55 2000
From: guido at python.org (Guido van Rossum)
Date: Wed, 25 Oct 2000 12:46:55 -0500
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: Your message of "Wed, 25 Oct 2000 12:23:30 -0400."
             <LNBBLJKPBEHFEDALKOLCIEMOHMAA.tim_one@email.msn.com> 
References: <LNBBLJKPBEHFEDALKOLCIEMOHMAA.tim_one@email.msn.com> 
Message-ID: <200010251746.MAA30108@cj20424-a.reston1.va.home.com>

> [Guido, on finding Tcl/Tk under Windows]
> > To me this all sounds like FUD.  Since Python 1.6 and 2.0, you don't
> > have to install Tcl/Tk or its libraries -- it is installed
> > *transparently* by the Python Windows installer.  That's different --
> > and better -- than what happened in 1.5.2, where a separate Tcl/Tk
> > installer was optionally run.  The version issues are also resolved
> > this way: you are guaranteed to get exactly the Tcl/Tk version that
> > was tested by the developers.

[Tim]
> Unless you're Fredrik, alas <wink>.  Apparently Tcl still honors library
> envars first if they exist, and if some other installation or use of Tcl/Tk
> set those, you can still end up w/ a mix. *Much* better than before, though,
> and I don't recall ay instance of this happening in real life so far apart
> from /F (who had no problem figuring it out, of course).

Hm...  In FixTk, TCL_LIBRARY is set explicitly.  Perhaps it should set
TK_LIBRARY explicitly too?

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



From trentm at ActiveState.com  Wed Oct 25 19:11:42 2000
From: trentm at ActiveState.com (Trent Mick)
Date: Wed, 25 Oct 2000 10:11:42 -0700
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: <LNBBLJKPBEHFEDALKOLCIEMOHMAA.tim_one@email.msn.com>; from tim_one@email.msn.com on Wed, Oct 25, 2000 at 12:23:30PM -0400
References: <200010251225.HAA22242@cj20424-a.reston1.va.home.com> <LNBBLJKPBEHFEDALKOLCIEMOHMAA.tim_one@email.msn.com>
Message-ID: <20001025101142.B8625@ActiveState.com>

On Wed, Oct 25, 2000 at 12:23:30PM -0400, Tim Peters wrote:
> [Guido, on finding Tcl/Tk under Windows]
> > To me this all sounds like FUD.  Since Python 1.6 and 2.0, you don't
> > have to install Tcl/Tk or its libraries -- it is installed
> > *transparently* by the Python Windows installer.  That's different --
> > and better -- than what happened in 1.5.2, where a separate Tcl/Tk
> > installer was optionally run.  The version issues are also resolved
> > this way: you are guaranteed to get exactly the Tcl/Tk version that
> > was tested by the developers.
> 
> Unless you're Fredrik, alas <wink>.

...Or anybody installing ActivePython for that matter. We give instructions
that the latest version of Tcl/Tk has to be installed separately, but Tk is
*not* bundled with it.


Trent

-- 
Trent Mick
TrentM at ActiveState.com



From pf at artcom-gmbh.de  Wed Oct 25 19:02:45 2000
From: pf at artcom-gmbh.de (Peter Funk)
Date: Wed, 25 Oct 2000 19:02:45 +0200 (MEST)
Subject: GUI-Discussion; MacOS vs. MacOS X (was Re: [Python-Dev] Miscellaneous comments on Tkinter and related...)
In-Reply-To: <14838.64730.225260.148853@buffalo.fnal.gov> from Charles G Waldman at "Oct 25, 2000 10:31:38 am"
Message-ID: <m13oTwr-000Dm8C@artcom0.artcom-gmbh.de>

Hi,

Charles G Waldman:
>  > 2.  I agree that MacOS is the thorny problem for
>  >     the standard Pysolution. 
> 
> What is the impact of the fact that MacOS X will run X?  Doesn't this
> open the door to a lot of new possibilities, at least if we don't need
> to support Mac OS[6-9].  Or is the installed base of MacOS[6-9] just
> way too big to even think about dropping (or deprecating) support for
> it?

It will take years, before MacOS X will find its way onto the desk
of the average Apple Mac user.  The Mac s mostly used in the graphics 
and printing industry (our cutsomers) where people normally don't 
even think about a OS upgrade, if they don't have to.  They usually
run a mix of Photoshop, Quark XPRess, Artwork, illustrator or other 
so called creative software on the version of the OS they had on 
the machine when they bought it.  THese machines are usually used
through a period of at least four years.

So MacOS X might simplify things for software vendors from 2004 on 
and later.

Regards, Peter



From guido at python.org  Wed Oct 25 20:21:58 2000
From: guido at python.org (Guido van Rossum)
Date: Wed, 25 Oct 2000 13:21:58 -0500
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: Your message of "Wed, 25 Oct 2000 10:11:42 MST."
             <20001025101142.B8625@ActiveState.com> 
References: <200010251225.HAA22242@cj20424-a.reston1.va.home.com> <LNBBLJKPBEHFEDALKOLCIEMOHMAA.tim_one@email.msn.com>  
            <20001025101142.B8625@ActiveState.com> 
Message-ID: <200010251821.NAA30247@cj20424-a.reston1.va.home.com>

> ...Or anybody installing ActivePython for that matter. We give instructions
> that the latest version of Tcl/Tk has to be installed separately, but Tk is
> *not* bundled with it.

And that's a shame.  Any chance that will be fixed any time soon?

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



From jeremy at alum.mit.edu  Wed Oct 25 15:36:46 2000
From: jeremy at alum.mit.edu (Jeremy Hylton)
Date: Wed, 25 Oct 2000 09:36:46 -0400 (EDT)
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: <200010251821.NAA30247@cj20424-a.reston1.va.home.com>
References: <200010251225.HAA22242@cj20424-a.reston1.va.home.com>
	<LNBBLJKPBEHFEDALKOLCIEMOHMAA.tim_one@email.msn.com>
	<20001025101142.B8625@ActiveState.com>
	<200010251821.NAA30247@cj20424-a.reston1.va.home.com>
Message-ID: <14838.57838.841831.632628@bitdiddle.concentric.net>

>>>>> "GvR" == Guido van Rossum <guido at python.org> writes:

  >> ...Or anybody installing ActivePython for that matter. We give
  >> instructions that the latest version of Tcl/Tk has to be
  >> installed separately, but Tk is *not* bundled with it.

  GvR> And that's a shame.  Any chance that will be fixed any time
  GvR> soon?

I think a version of Tkinter packaged with a distutils setup script is
the best answer for Unix platforms.  As a Linux user, I do *not* want
to install a second copy of Tcl/Tk.

If we have a distutil-Tkinter, e.g. 
    ftp://ftp.python.org/pub/python/2.0/Tkinter-2.0-8.0.tar.gz
then a user can download it and run "python setup.py install" to build
a Tkinter against their installed version of Tk.  This will be
straightforward on many Linux systems, because they ship with Tk
installed.

Jeremy



From jeremy at alum.mit.edu  Wed Oct 25 15:41:30 2000
From: jeremy at alum.mit.edu (Jeremy Hylton)
Date: Wed, 25 Oct 2000 09:41:30 -0400 (EDT)
Subject: [Python-Dev] build problems under Solaris
Message-ID: <14838.58122.920099.787981@bitdiddle.concentric.net>

There are two bug reports about build problems under Solaris (117508
and 117606).  I don't have access to a Solaris machine, so I can't do
anything to help these users.  Since ActivePython is shipped for
Solaris, I assume that you (or someone else at AS) does have access to
a Solaris machine.  Can you take a look at these problems?  Or assign
them to someone else who can?

Jeremy




From guido at python.org  Wed Oct 25 20:50:07 2000
From: guido at python.org (Guido van Rossum)
Date: Wed, 25 Oct 2000 13:50:07 -0500
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: Your message of "Wed, 25 Oct 2000 09:36:46 -0400."
             <14838.57838.841831.632628@bitdiddle.concentric.net> 
References: <200010251225.HAA22242@cj20424-a.reston1.va.home.com> <LNBBLJKPBEHFEDALKOLCIEMOHMAA.tim_one@email.msn.com> <20001025101142.B8625@ActiveState.com> <200010251821.NAA30247@cj20424-a.reston1.va.home.com>  
            <14838.57838.841831.632628@bitdiddle.concentric.net> 
Message-ID: <200010251850.NAA30475@cj20424-a.reston1.va.home.com>

> I think a version of Tkinter packaged with a distutils setup script is
> the best answer for Unix platforms.  As a Linux user, I do *not* want
> to install a second copy of Tcl/Tk.

Why not?  Because if every app using Tcl/Tk did that there would be
hundreds of copies of Tcl/Tk on your disk?  I don't think that
argument flies; only a few other major languages use Tcl/Tk this was,
so maybe you'd end up with 4 copies of Tcl/Tk: one for Tcl/Tk itself,
one for Python+Tkinter, one for Perl/Tk (that's a separate code base
anyway so you already have this today -- if you install Perl/Tk, that
is), and one for Ruby.  Given modern disk sizes I don't think it's a
problem.  We do the same for Windows, for good reasons: so we can be
independent of whatever Tcl/Tk version is already installed.

> If we have a distutil-Tkinter, e.g. 
>     ftp://ftp.python.org/pub/python/2.0/Tkinter-2.0-8.0.tar.gz
> then a user can download it and run "python setup.py install" to build
> a Tkinter against their installed version of Tk.  This will be
> straightforward on many Linux systems, because they ship with Tk
> installed.

Of course that's easier.  But less robust.  (And why is there an "8.0"
in the filename if it works with other Tcl/Tk versions???)

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



From paul at prescod.net  Wed Oct 25 20:11:34 2000
From: paul at prescod.net (Paul Prescod)
Date: Wed, 25 Oct 2000 11:11:34 -0700
Subject: [Python-Dev] Gradual migration
References: <39F52EF1.A201C6D9@prescod.net> <39F54C0F.25798309@lemburg.com> <39F5B4DC.C226D8F6@prescod.net> <39F5E4FA.9FD6D35@lemburg.com>
Message-ID: <39F72256.C7F93BFB@prescod.net>

"M.-A. Lemburg" wrote:
> 
> ...
>
> >  * implementation language and Python inheritance semantics are almost
> > completely distinct. After all, we have Python implementations in a
> > variety of languages with minor incompatibilities. Python could have a
> > proper type/class merging even if it were written in assembly language.
> > So let's leave implementation language aside.
> 
> Hey, think of it as opportunity: we can reuse much of C++'s
> optimizations and the integration of Python and C++ applications
> will get *much* easier.

We could make integrating C++ and Python easier through CXX or Py_Cpp.
Perhaps we should ship one of those with Python 2.1. Anyhow, integrating
C++ and Python is not really so hard, in my experience.
 
> A rewrite shouldn't scare anyone away -- much of the existing
> code can be reused since only the Python C APIs of the various
> types will have to be rewritten, not the logic behind the types.

I wasn't really addressing the issue of backwards compatibility of
extensions -- I was talking about Python programs. Nevertheless, I can't
resist:

Porting your app to the Python APIs is often the majority of the work in
a particular extension. A lot of Python extensions consist only of API
glue!
 
> Besides, Py3K will be a project which runs in parallel to the
> 2.x development (at least that's what I've read on some BeOpen
> webpage), so there's really not much to worry about wrt to
> breakage, etc. People will be able to test-drive Py3K while
> using the 2.x series.

I don't see how that helps. If you can't write programs that work both
on the old interpreter and the new one then you need to have a "switch
over" day. The whole point of my doctrine is that Python 3K should run
all code that the version of Python immediately before it did. The most
it can do in terms of breakage is to warn about error messages. In that
case it doesn't matter much whether Python 3K is available at the same
time as 2.X or emerges from Guido's head fully formed.

> >  * there is a hell of a lot we can do to make the type/class split less
> > visible without a major rewrite. For instance, lists could have a
> > __getitem__ method so that they "act like" instances. Instances could
> > return their methods in a dir() so that they "act like" built-in
> > objects. So there is no reason to wait for a complete rewrite to start
> > on this path.
> 
> Right. I didn't want to say that things cannot be done prior
> to the rewrite, only that a rewrite will give us much more
> options that we currently have.

Okay, so do you agree with the rule expressed here:

http://www.python.org/pipermail/python-dev/2000-October/016785.html

> > I don't know what you mean by a "low-level strategy" for classes. It's
> > not like we can somehow use C++ vtables without giving up Python's
> > dynamicity. Python's class handling is about as low-level as it can get
> > in my humble opinion.
> 
> With "low-level" I meant trying to build Python classes and
> instances on top of a very thin layer on top of C++ classes,
> e.g. all slots could be implemented using true C++ methods with
> additional logic to override them using dynamically bound
> Python method objects.

I don't think that there is really interesting magic in a C++ compiler.
A vtable is an array of pointers to functions. We've already implemented
the equivalent in ANSI C. C++ exceptions, constructors, destriuctors and
smart pointers are a little more interesting from a code maintenance and
simplicity point of view. But even then I think that we could get to a
C++ implementation through incremental rewrites.

> > > Differences like the
> > > ones between Unicode and 8-bit strings would then flesh
> > > out as two different subclasses of a generic string type which
> > > again is based on a generic sequence type.
> >
> > Of course that's where we want to go but it doesn't avoid the backwards
> > compatibility problems.
> 
> Huh ? I was talking about clear design... not ways to avoid
> b/w compatibility. 

But the whole point of my original article was backwards
compatibility!!! I didn't address an implementation strategy for Py3K at
all.

> Merging Unicode and strings will hurt one
> way or another. This is simply a consequence of using strings
> as binary containers where Unicode is meant for text only use.

The question I wanted to address is how we can *minimize the pain*. 

> ...
> > C++ does not help. Inheritance does not help. Pluggable compilers do not
> > help. We *will* break code. We just need to decide whether to do it in a
> > thoughtful way that gives people a chance to migrate or put off
> > decisions until the last possible moment and then spring it on them with
> > no between-version upgrade path.
> 
> Just tell Python to use the correct class for what the
> code was written for (and this could be done by plugging in
> a 2.0 compiler). The instances of those classes would still work
> together with other semantics by virtue of exposing the same
> interface, yet the internals would work differently, e.g.
> a module using case insensitive lookup would be compiled using
> case insensitive dictionaries as namespaces.

A mode switch solutiion is fraught with dangers. First there is the
issue of the correct default for the mode switch. 

http://www.python.org/pipermail/python-dev/2000-April/010029.html

Second, there are dangers cutting and pasting between modules.

Anyhow, even if we allow a mode switch we need to be able to help people
to upgrade their modules in a reasonable time. That's what the message I
cited advocates.

>...
> Why spoil all the fun when we haven't even started thinking
> about all the possibilities we could use to make Py3k a
> success ?

Asking for a map of where we are going and how we will get here is
"spoiling all of the fun?" I'm not sure what you are reacting to -- I
didn't advise one implementation strategy or another -- I just said that
we should employ a strategy that minimizes sudden and surprising code
breakage.

-- 
 Paul Prescod - Not encumbered by corporate consensus
Simplicity does not precede complexity, but follows it. 
	- http://www.cs.yale.edu/homes/perlis-alan/quotes.html



From fdrake at acm.org  Wed Oct 25 20:06:50 2000
From: fdrake at acm.org (Fred L. Drake, Jr.)
Date: Wed, 25 Oct 2000 14:06:50 -0400 (EDT)
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: <200010251850.NAA30475@cj20424-a.reston1.va.home.com>
References: <200010251225.HAA22242@cj20424-a.reston1.va.home.com>
	<LNBBLJKPBEHFEDALKOLCIEMOHMAA.tim_one@email.msn.com>
	<20001025101142.B8625@ActiveState.com>
	<200010251821.NAA30247@cj20424-a.reston1.va.home.com>
	<14838.57838.841831.632628@bitdiddle.concentric.net>
	<200010251850.NAA30475@cj20424-a.reston1.va.home.com>
Message-ID: <14839.8506.304295.908264@cj42289-a.reston1.va.home.com>

Guido van Rossum writes:
 > Why not?  Because if every app using Tcl/Tk did that there would be
 > hundreds of copies of Tcl/Tk on your disk?  I don't think that
 > argument flies; only a few other major languages use Tcl/Tk this was,

  So should every application written in Python install it's own copy
of Python, since there may be unexpected incompatibilities between
versions?


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at acm.org>
PythonLabs Team Member




From paul at prescod.net  Wed Oct 25 20:18:16 2000
From: paul at prescod.net (Paul Prescod)
Date: Wed, 25 Oct 2000 11:18:16 -0700
Subject: [Python-Dev] Miscellaneous comments on Tkinter and related matters
References: <200010251458.JAA77237@starbase.neosoft.com> <14838.64730.225260.148853@buffalo.fnal.gov>
Message-ID: <39F723E8.2AC6787@prescod.net>

Charles G Waldman wrote:
> 
> ...
> What is the impact of the fact that MacOS X will run X?  Doesn't this
> open the door to a lot of new possibilities, at least if we don't need
> to support Mac OS[6-9].  Or is the installed base of MacOS[6-9] just
> way too big to even think about dropping (or deprecating) support for
> it?

Would Mac users go for: "first install X. Then you can run Python."

-- 
 Paul Prescod - Not encumbered by corporate consensus
Simplicity does not precede complexity, but follows it. 
	- http://www.cs.yale.edu/homes/perlis-alan/quotes.html



From guido at python.org  Wed Oct 25 21:14:57 2000
From: guido at python.org (Guido van Rossum)
Date: Wed, 25 Oct 2000 14:14:57 -0500
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: Your message of "Wed, 25 Oct 2000 14:06:50 -0400."
             <14839.8506.304295.908264@cj42289-a.reston1.va.home.com> 
References: <200010251225.HAA22242@cj20424-a.reston1.va.home.com> <LNBBLJKPBEHFEDALKOLCIEMOHMAA.tim_one@email.msn.com> <20001025101142.B8625@ActiveState.com> <200010251821.NAA30247@cj20424-a.reston1.va.home.com> <14838.57838.841831.632628@bitdiddle.concentric.net> <200010251850.NAA30475@cj20424-a.reston1.va.home.com>  
            <14839.8506.304295.908264@cj42289-a.reston1.va.home.com> 
Message-ID: <200010251914.OAA30720@cj20424-a.reston1.va.home.com>

>  > Why not?  Because if every app using Tcl/Tk did that there would be
>  > hundreds of copies of Tcl/Tk on your disk?  I don't think that
>  > argument flies; only a few other major languages use Tcl/Tk this was,
> 
> So should every application written in Python install it's own copy
> of Python, since there may be unexpected incompatibilities between
> versions?

Of course not, but large and important ones may.  Some already do,
e.g. Alice, Zope, Ultraseek.  I have no problem with this.  (The
saving grace is that none of these needs to recursively include
Tcl. :-)

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



From gvwilson at nevex.com  Wed Oct 25 20:17:24 2000
From: gvwilson at nevex.com (Greg Wilson)
Date: Wed, 25 Oct 2000 14:17:24 -0400 (EDT)
Subject: [Python-Dev] Gradual migration
In-Reply-To: <39F72256.C7F93BFB@prescod.net>
Message-ID: <Pine.LNX.4.10.10010251415580.10577-100000@akbar.nevex.com>

> Paul Prescod:
> Anyhow, integrating C++ and Python is not really so hard, in my experience.

...unless you are using heavily-templated code, e.g. every damn class you've
been asked to wrap up seems to be derived from something in the STL...

Greg




From cgw at fnal.gov  Wed Oct 25 20:18:56 2000
From: cgw at fnal.gov (Charles G Waldman)
Date: Wed, 25 Oct 2000 13:18:56 -0500 (CDT)
Subject: [Python-Dev] Miscellaneous comments on Tkinter and related matters
In-Reply-To: <39F723E8.2AC6787@prescod.net>
References: <200010251458.JAA77237@starbase.neosoft.com>
	<14838.64730.225260.148853@buffalo.fnal.gov>
	<39F723E8.2AC6787@prescod.net>
Message-ID: <14839.9232.950919.629446@buffalo.fnal.gov>

Paul Prescod writes:
 > 
 > Would Mac users go for: "first install X. Then you can run Python."
 > 

I should probably just shut up, because I really don't know enough
about Mac OS X, but what I was wondering is whether OS X will actually
*use* the X Window System.  Of course we don't want to tell users that
they have to go install X on their own.




From tim_one at email.msn.com  Wed Oct 25 20:18:55 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Wed, 25 Oct 2000 14:18:55 -0400
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: <14839.8506.304295.908264@cj42289-a.reston1.va.home.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCGENHHMAA.tim_one@email.msn.com>

[Guido]
> Why not?  Because if every app using Tcl/Tk did that there would be
> hundreds of copies of Tcl/Tk on your disk?  I don't think that
> argument flies; only a few other major languages use Tcl/Tk this was,

[Fred Drake]
>   So should every application written in Python install it's own copy
> of Python, since there may be unexpected incompatibilities between
> versions?

So long as Python doesn't guarantee binary compatibility across releases,
that's the only thing that works.  Play PySol lately <wink>?





From paul at prescod.net  Wed Oct 25 20:27:33 2000
From: paul at prescod.net (Paul Prescod)
Date: Wed, 25 Oct 2000 11:27:33 -0700
Subject: [Python-Dev] Miscellaneous comments on Tkinter and related matters
References: <200010251458.JAA77237@starbase.neosoft.com>
		<14838.64730.225260.148853@buffalo.fnal.gov>
		<39F723E8.2AC6787@prescod.net> <14839.9232.950919.629446@buffalo.fnal.gov>
Message-ID: <39F72615.40B38862@prescod.net>

Charles G Waldman wrote:
> 
>...
> 
> I should probably just shut up, because I really don't know enough
> about Mac OS X, but what I was wondering is whether OS X will actually
> *use* the X Window System.  Of course we don't want to tell users that
> they have to go install X on their own.

And become just another Unix? Then how would they get people to pay the
Macintosh usability premium?

Seriously, maybe someday as a "Linux compatibility mode" but I don't
think it is officially proposed.

-- 
 Paul Prescod - Not encumbered by corporate consensus
Simplicity does not precede complexity, but follows it. 
	- http://www.cs.yale.edu/homes/perlis-alan/quotes.html



From paul at prescod.net  Wed Oct 25 20:30:34 2000
From: paul at prescod.net (Paul Prescod)
Date: Wed, 25 Oct 2000 11:30:34 -0700
Subject: Integer division revisited (was Re: [Python-Dev] Gradual migration)
References: <m13nynX-000Dm8C@artcom0.artcom-gmbh.de>
Message-ID: <39F726CA.9D472E50@prescod.net>

Peter Funk wrote:
> 
> ..
> 
> Bruce Sherwood and David Scherer suggested a IMHO very clever solution to
> this particular problem in March/April this year.  This thread was first
> posted to idle-dev and afterwards X-posted to python-dev:
> 
> http://www.python.org/pipermail/idle-dev/2000-April/000138.html
> http://www.python.org/pipermail/idle-dev/2000-April/000140.html
> http://www.python.org/pipermail/python-dev/2000-April/010029.html
 
Tim's last message on it doesn't sound overwhelmingly positiive to me!
Also, don't forget that Python is also a command line so "version
pragmas" cause additional complexity there.

-- 
 Paul Prescod
Simplicity does not precede complexity, but follows it. 
	- http://www.cs.yale.edu/homes/perlis-alan/quotes.html



From DavidA at ActiveState.com  Wed Oct 25 20:59:35 2000
From: DavidA at ActiveState.com (David Ascher)
Date: Wed, 25 Oct 2000 11:59:35 -0700 (Pacific Daylight Time)
Subject: [Python-Dev] build problems under Solaris
In-Reply-To: <14838.58122.920099.787981@bitdiddle.concentric.net>
Message-ID: <Pine.WNT.4.21.0010251159020.1360-100000@loom>

On Wed, 25 Oct 2000, Jeremy Hylton wrote:

> There are two bug reports about build problems under Solaris (117508
> and 117606).  I don't have access to a Solaris machine, so I can't do
> anything to help these users.  Since ActivePython is shipped for
> Solaris, I assume that you (or someone else at AS) does have access to
> a Solaris machine.  Can you take a look at these problems?  Or assign
> them to someone else who can?

Sure, we'll take a look.  

--david




From akuchlin at mems-exchange.org  Wed Oct 25 23:51:40 2000
From: akuchlin at mems-exchange.org (Andrew Kuchling)
Date: Wed, 25 Oct 2000 17:51:40 -0400
Subject: [Python-Dev] 2.0 articles
Message-ID: <E13oYSS-00071f-00@kronos.cnri.reston.va.us>

I'd like to begin writing an article about 2.0's Unicode support.
Before beginning, has anyone else already begun this task?  If yes,
please let me know...

(Incidentally, did a 2.0 press release ever go out?  Is someone going
to write one?)

--amk



From MarkH at ActiveState.com  Thu Oct 26 00:18:27 2000
From: MarkH at ActiveState.com (Mark Hammond)
Date: Thu, 26 Oct 2000 09:18:27 +1100
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: <200010251821.NAA30247@cj20424-a.reston1.va.home.com>
Message-ID: <ECEPKNMJLHAPFFJHDOJBCEOADOAA.MarkH@ActiveState.com>

[Trent]
> > ...Or anybody installing ActivePython for that matter. We
> > give instructions that the latest version of Tcl/Tk has to
> > be installed separately, but Tk is *not* bundled with it.

[Guido]
> And that's a shame.  Any chance that will be fixed any time soon?

Not presuming to speak for anyone, least of all the ActivePython product
manager :-)

I don't think it will be "fixed", as it is not considered "broken".  It was
an explicit choice to leave out Tcl/Tk.  And my recollection is that the
"feedback" address sees more requests for wxPython than Tcl/Tk.

We make it pretty clear Tcl/Tk is not included - I assume that everyone who
cares about that simply uses BeOpen releases or source tarballs.

[When I say "wont be fixed", I mean it is unlikely to appear in the core
ActivePython release.  It almost certainly will be supported as an add-on,
whatever that turns out to mean exactly ;-]

Mark.




From guido at python.org  Thu Oct 26 02:15:31 2000
From: guido at python.org (Guido van Rossum)
Date: Wed, 25 Oct 2000 19:15:31 -0500
Subject: [Python-Dev] 2.0 articles
In-Reply-To: Your message of "Wed, 25 Oct 2000 17:51:40 -0400."
             <E13oYSS-00071f-00@kronos.cnri.reston.va.us> 
References: <E13oYSS-00071f-00@kronos.cnri.reston.va.us> 
Message-ID: <200010260015.TAA02798@cj20424-a.reston1.va.home.com>

> (Incidentally, did a 2.0 press release ever go out?  Is someone going
> to write one?)

No; and not me...

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



From MarkH at ActiveState.com  Thu Oct 26 01:29:52 2000
From: MarkH at ActiveState.com (Mark Hammond)
Date: Thu, 26 Oct 2000 10:29:52 +1100
Subject: [Python-Dev] sys.__stdout__ - was RE: [Idle-dev] Doc Commentary
In-Reply-To: <200010251513.KAA28803@cj20424-a.reston1.va.home.com>
Message-ID: <ECEPKNMJLHAPFFJHDOJBOEOFDOAA.MarkH@ActiveState.com>

[From a mail in idle-dev - dropped idle-dev and all CCs]

[idle-dev poster]
> > >>> import sys
> > >>> f = open('some-output-file', 'w')
> > >>> sys.stdout = f
> > >>> # do some stuff
> > >>> sys.stdout = sys.__stdout__
> >
> > Because on entry, sys.stdout is already redirected
> > (not reflected in sys.__stdout__)

[Guido]

> Where did you get this idiom?  You should never use sys.__stdout__
> this way!  The proper idiom is
>
>   save_stdout = sys.stdout
>   try:
>       sys.stdout = f
>       # do some stuff
>   finally:
>       sys.stdout = save_stdout
>
> If you know of any places that are promoting direct use of __stdout__,
> please let them know this is wrong.  If you are contemplating to use
> this in code examples you intend to distribute, please don't!

I admit that I first became aware of sys.__stdout__ after seeing this exact
same idiom in other peoples code.  I always assumed that this is _exactly_
what sys.__stdout__ was to be used for!

The following examples exist:

* Tools/unicode/makeunicodedata.py - exactly the idiom you despise.
* Tools/il8n/pygettext.py - ditto
* Tools/idle/PyParse.py - disabled, debugging output function - presumably
to get around sys.stdout redirection - but this sounds suspect as an idiom
to me too!

So what _is_ it intended for?

Mark.




From greg at cosc.canterbury.ac.nz  Thu Oct 26 02:16:02 2000
From: greg at cosc.canterbury.ac.nz (Greg Ewing)
Date: Thu, 26 Oct 2000 13:16:02 +1300 (NZDT)
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: <200010251353.IAA28190@cj20424-a.reston1.va.home.com>
Message-ID: <200010260016.NAA28387@s454.cosc.canterbury.ac.nz>

> If you started with basic Tkinter widgets, sure, it looks different
> than anything else.  But that depends on the widget layout in the
> program, not on the widget library used!

This is one of my main gripes about the Tk API.  The default
behaviours of all its layout managers suck. In order to get a layout
that looks pleasant and/or conforms to some style guide, you have to
set a whole slew of options every time you place a widget.

Greg Ewing, Computer Science Dept, +--------------------------------------+
University of Canterbury,	   | A citizen of NewZealandCorp, a	  |
Christchurch, New Zealand	   | wholly-owned subsidiary of USA Inc.  |
greg at cosc.canterbury.ac.nz	   +--------------------------------------+



From barry at wooz.org  Thu Oct 26 02:17:38 2000
From: barry at wooz.org (Barry A. Warsaw)
Date: Wed, 25 Oct 2000 20:17:38 -0400 (EDT)
Subject: [Python-Dev] sys.__stdout__ - was RE: [Idle-dev] Doc Commentary
References: <200010251513.KAA28803@cj20424-a.reston1.va.home.com>
	<ECEPKNMJLHAPFFJHDOJBOEOFDOAA.MarkH@ActiveState.com>
Message-ID: <14839.30754.217582.20441@anthem.concentric.net>

>>>>> "MH" == Mark Hammond <MarkH at ActiveState.com> writes:

    MH> * Tools/il8n/pygettext.py

That's embarassing. ;)

Here's a patch, but I'm not going to check it in because I think a
/much/ better idiom to adopt is to use extended print instead.  I need
to make some updates to pygettext.py soon, so I'll probably just
2.0-ify it at the same time.

-Barry

-------------------- snip snip --------------------
Index: pygettext.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Tools/i18n/pygettext.py,v
retrieving revision 1.9
diff -u -r1.9 pygettext.py
--- pygettext.py	2000/05/02 19:28:30	1.9
+++ pygettext.py	2000/10/26 00:16:22
@@ -283,6 +283,7 @@
         options = self.__options
         timestamp = time.ctime(time.time())
         # common header
+        stdout = sys.stdout
         try:
             sys.stdout = fp
             # The time stamp in the header doesn't have the same format
@@ -314,7 +315,7 @@
                 print 'msgid', normalize(k)
                 print 'msgstr ""\n'
         finally:
-            sys.stdout = sys.__stdout__
+            sys.stdout = stdout
 
 
 def main():



From gmcm at hypernet.com  Thu Oct 26 02:39:14 2000
From: gmcm at hypernet.com (Gordon McMillan)
Date: Wed, 25 Oct 2000 20:39:14 -0400
Subject: [Python-Dev] sys.__stdout__ - was RE: [Idle-dev] Doc Commentary
In-Reply-To: <ECEPKNMJLHAPFFJHDOJBOEOFDOAA.MarkH@ActiveState.com>
References: <200010251513.KAA28803@cj20424-a.reston1.va.home.com>
Message-ID: <39F744F2.17759.4FC8E6D4@localhost>

> [Guido]
> 
> > Where did you get this idiom?  You should never use sys.__stdout__
> > this way!  The proper idiom is
> >
> >   save_stdout = sys.stdout
> >   try:
> >       sys.stdout = f
> >       # do some stuff
> >   finally:
> >       sys.stdout = save_stdout
[Mark]
> So what _is_ it intended for?

A fail-safe. The recommended idiom might also be called 
"plays well with others"; a barbarian notion that fortunately has 
not infected most import hacks or program exits...

works-for-me-so-buzz-off-ly y'rs

- Gordon



From akuchlin at mems-exchange.org  Thu Oct 26 04:40:03 2000
From: akuchlin at mems-exchange.org (Andrew Kuchling)
Date: Wed, 25 Oct 2000 22:40:03 -0400
Subject: [Python-Dev] 2.0 press release
In-Reply-To: <200010260015.TAA02798@cj20424-a.reston1.va.home.com>; from guido@python.org on Wed, Oct 25, 2000 at 07:15:31PM -0500
References: <E13oYSS-00071f-00@kronos.cnri.reston.va.us> <200010260015.TAA02798@cj20424-a.reston1.va.home.com>
Message-ID: <20001025224003.A27300@kronos.cnri.reston.va.us>

On Wed, Oct 25, 2000 at 07:15:31PM -0500, Guido van Rossum wrote:
>> (Incidentally, did a 2.0 press release ever go out?  Is someone going
>> to write one?)
>No; and not me...

Little-known fact: Guido actually does nothing but sit in his pyjamas
(with feet!)  all day, drinking cocoa, eating Hostess Twinkies and
watching Tiny Toons, while his long-suffering co-workers implement and
debug the fantastically complex algorithms that go into Python.

Here's some rough text: Can someone with a clue about writing a good
press release give this a look?

--amk


Reston, VA, Oct 25 2000: The Python development team today announced
the release of version 2.0 of the Python programming language.
Version 2.0 adds a number of significant new features:

	* Unicode support, in the form of a new Unicode data type,
	library additions for conversion to/from various encodings,
	and support for displaying Unicode strings in Tk widgets.

	* New language features: garbage collection of cycles, list
	comprehensions, augmented assignment, string methods.

	* Distutils, a new system for making Python modules and
	extensions easily available to a wider audience with very
	little overhead for build/release/install mechanics.

	* Improved XML support, including support for the Simple API
	for XML (SAX2), a miniature Document Object Model (DOM), and
	the Expat parser.

	* Many library improvements, including HTTP/1.1 support, an
	enhanced curses module, the ability to read and write
	ZIP-format files, support for the Windows registry, and many
	more minor improvements.

	* Ports to new platforms: 64-bit Windows on the Itanium
	processor, Windows CE, and Darwin/MacOS X.
	
Python is an interpreted, object-oriented, high-level programming
language.  Its high-level built in data structures, combined with
dynamic typing and dynamic binding, make it very attractive for rapid
application development, as well as for use as a scripting or glue
language to connect existing components together.  Python's simple,
easy to learn syntax emphasizes readability and therefore reduces the
cost of program maintenance, and it supports modules and packages,
encouraging program modularity and code reuse.  

Many extension modules for Python have been written to interface 
with other libraries and applications.  Some of the available modules
include:

	* Support for many relational databases (Oracle, Sybase, MySQL)
	* GUI toolkits (Tk, Windows MFC, wxWindows, KDE, GNOME)
	* Internet protocols (LDAP, WebDAV, XML-RPC, SOAP)
	* Mathematics (Numeric Python)

Python is used for many different purposes, particularly
cross-platform rapid development, Web development, and scripting of
scientific applications.  Some of the applications using Python
include:

	* Zope, the leading Open Source web application server
	* The Mailman mailing list manager
	* The Reportlab PDF document generation toolset
	* XXX suggestions?

XXX too darn many lists here?

<Insert 4 or 5 quotations from various people here.  
 Possible people: someone from Digital Creations, PythonWare,
	          Reportlabs, ActiveState/O'Reilly, TheKompany,
	          Infoseek, Red Hat, a developer from some well-known
	          free software project that uses Python>

The Python interpreter and the extensive standard library are
available free of charge and are distributed under an open-source
license.  Ports have been made to all major platforms, such as
Windows, MacOS, and many Unix variants (Linux, Solaris, FreeBSD, etc.)
New versions are developed collaboratively by a core group of over 20
developers.

About BeOpen:
  <get text for this>

About Python:

   More information about Python can be obtained from the official Python
   website, http://www.python.org. 

(XXX Do you include About sections for the companies that provide quotes?)

Press contacts:
XXX whose address?




From guido at python.org  Thu Oct 26 06:02:11 2000
From: guido at python.org (Guido van Rossum)
Date: Wed, 25 Oct 2000 23:02:11 -0500
Subject: [Python-Dev] sys.__stdout__
In-Reply-To: Your message of "Thu, 26 Oct 2000 10:29:52 +1100."
             <ECEPKNMJLHAPFFJHDOJBOEOFDOAA.MarkH@ActiveState.com> 
References: <ECEPKNMJLHAPFFJHDOJBOEOFDOAA.MarkH@ActiveState.com> 
Message-ID: <200010260402.XAA03016@cj20424-a.reston1.va.home.com>

> So what _is_ it intended for?

Example: IDLE redirects sys.stderr so that it gets displayed in the
Python Shell window with a different text color.  But occasionally I
need to debug IDLE and the bug is in the text drawing.  Then it's nice
if I can write to __stderr__, which goes to the console.

Or suppose I'm in a regular interactive session and I've managed to
screw myself by assigning a bogus file object to sys.stdout (it
happens :-).  If I know that, I can type sys.stdout = sys.__stdout__
at the >>> prompt and save myself -- so I don't have to restart the
session and perhaps lose valuable data.

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



From fdrake at acm.org  Thu Oct 26 05:55:13 2000
From: fdrake at acm.org (Fred L. Drake, Jr.)
Date: Wed, 25 Oct 2000 23:55:13 -0400 (EDT)
Subject: [Python-Dev] sys.__stdout__ - was RE: [Idle-dev] Doc Commentary
In-Reply-To: <ECEPKNMJLHAPFFJHDOJBOEOFDOAA.MarkH@ActiveState.com>
References: <200010251513.KAA28803@cj20424-a.reston1.va.home.com>
	<ECEPKNMJLHAPFFJHDOJBOEOFDOAA.MarkH@ActiveState.com>
Message-ID: <14839.43809.850142.50138@cj42289-a.reston1.va.home.com>

Mark Hammond writes:
 > * Tools/unicode/makeunicodedata.py - exactly the idiom you despise.
 > * Tools/il8n/pygettext.py - ditto

  I've just fixed these two; too bad checkin messages aren't getting
sent.  ;(

 > * Tools/idle/PyParse.py - disabled, debugging output function - presumably
 > to get around sys.stdout redirection - but this sounds suspect as an idiom
 > to me too!

  I've left this one for someone with a good idea about what to do
about it.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at acm.org>
PythonLabs Team Member




From fdrake at acm.org  Thu Oct 26 06:31:33 2000
From: fdrake at acm.org (Fred L. Drake, Jr.)
Date: Thu, 26 Oct 2000 00:31:33 -0400 (EDT)
Subject: [Python-Dev] Re: [Bug #117070] README instructions for configuring Setup are not helpful
In-Reply-To: <20001025222406.A8389@snowy.squish.net>
References: <200010251752.KAA02444@sf-web2.i.sourceforge.net>
	<20001025222406.A8389@snowy.squish.net>
Message-ID: <14839.45989.450533.514732@cj42289-a.reston1.va.home.com>

[Moved over from a discussion in the bugs list; this relates to bug:
 http://sourceforge.net/bugs/?func=detailbug&bug_id=117070&group_id=5470
 Please be sure to CC: Jon on all replies.]

Jon Ribbens writes:
 > Why the Setup.in/Setup thing at all? Just copying Setup.in to Setup without
 > changes is unexpected enough to warrant mentioning in a paragraph of its
 > own, completely explicitly. The '.in' suffix is usually used for files which
 > autoconf is going to use to create a new file from - you cannot usually
 > simply copy the file yourself. An experienced admin installing Python is
 > more likely to believe the README is wrong than what it tells them to do
 > is correct. Why does the Setup.in file exist in the first place? Surely it
 > should be named 'Setup.dist' (and an identical file 'Setup' exist right from
 > the start).

  Ok, here's the plan:  Change Setup.in to Setup.dist, and provide a
copy as Setup.  Since this doesn't help if the source and build
directories differ, configure.in can be modified to create Setup if
(and only if!) it doesn't exist, by copying it from $srcdir/Modules/.
  I have the changes to configure.in, configure, Setup*, and
Modules/Makefile.pre.in ready, but I still need to update the
instructions in the README & possibly elsewhere.
  Does this sound agreeable?


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at acm.org>
PythonLabs Team Member




From effbot at telia.com  Thu Oct 26 09:15:45 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Thu, 26 Oct 2000 09:15:45 +0200
Subject: [Python-Dev] sys.__stdout__ - was RE: [Idle-dev] Doc Commentary
References: <ECEPKNMJLHAPFFJHDOJBOEOFDOAA.MarkH@ActiveState.com>
Message-ID: <002f01c03f1c$9d721ef0$3c6340d5@hagrid>

mark wrote:
> > If you know of any places that are promoting direct use of __stdout__,
> > please let them know this is wrong.  If you are contemplating to use
> > this in code examples you intend to distribute, please don't!
> 
> I admit that I first became aware of sys.__stdout__ after seeing this exact
> same idiom in other peoples code.  I always assumed that this is _exactly_
> what sys.__stdout__ was to be used for!
> 
> The following examples exist:

and several examples in the eff-bot guide.

guess I'll have to fix it in the second edition...

</F>




From ping at lfw.org  Thu Oct 26 10:09:44 2000
From: ping at lfw.org (Ka-Ping Yee)
Date: Thu, 26 Oct 2000 01:09:44 -0700 (PDT)
Subject: [Python-Dev] getting at the current frame
In-Reply-To: <14837.60682.437334.797392@anthem.concentric.net>
Message-ID: <Pine.LNX.4.10.10010252356410.7079-100000@skuld.kingmanhall.org>

On Tue, 24 Oct 2000, Barry A. Warsaw wrote:
> 
> Okay, we all know that's a pain, right?  Lots of people have proposed
> solutions.  I've looked briefly at !?ng's Itpl.py, but I think it
> probably does too much by adding evaluation.

Do you think a variant of Itpl that only looked up variable names
would solve your problem?

> I can define _() to make the problem somewhat more convenient:
> 
>     def _(s):
> 	try:
> 	    raise Exception
> 	except Exception:
> 	    frame = sys.exc_info()[2].tb_frame.f_back
> 	d = frame.f_globals.copy()
> 	d.update(frame.f_locals())
> 	return the_translation_of(s) % d

How about this routine to get the current frame: inspect.currentframe().

Could i humbly re-request approval for inspect.py in the standard library?

    http://lfw.org/python/inspect.py

It's been up there for a long time, there's lots of good stuff in it,
and previous feedback on this list has all been fairly positive --
there just hasn't been an explicit approval for inclusion.  This is
probably because we were busy trying to get 2.0 released (even though
inspect.py was proposed here before ascii.py, and ascii.py did get
accepted).

I think the functionality it provides is important to supporting the
language definition.  It abstracts away the special secret attributes
and protects us from future changes in the internals.

If there are changes that need to be made before it can be accepted,
i'd be happy to make them.


-- ?!ng




From effbot at telia.com  Thu Oct 26 10:36:14 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Thu, 26 Oct 2000 10:36:14 +0200
Subject: [Python-Dev] getting at the current frame
References: <Pine.LNX.4.10.10010252356410.7079-100000@skuld.kingmanhall.org>
Message-ID: <014501c03f27$cec2ef10$3c6340d5@hagrid>

> Could i humbly re-request approval for inspect.py in the standard library?
> 
>     http://lfw.org/python/inspect.py
> 
> It's been up there for a long time

hey, you still haven't fixed the *2 bug...

> I think the functionality it provides is important to supporting the
> language definition.  It abstracts away the special secret attributes
> and protects us from future changes in the internals.

agreed.

> inspect.py was proposed here before ascii.py, and ascii.py did get
> accepted

as part of the curses package, yes.

</F>




From ping at lfw.org  Thu Oct 26 10:53:56 2000
From: ping at lfw.org (Ka-Ping Yee)
Date: Thu, 26 Oct 2000 01:53:56 -0700 (PDT)
Subject: [Python-Dev] getting at the current frame
In-Reply-To: <014501c03f27$cec2ef10$3c6340d5@hagrid>
Message-ID: <Pine.LNX.4.10.10010260153110.7079-100000@skuld.kingmanhall.org>

On Thu, 26 Oct 2000, Fredrik Lundh wrote:
> > It's been up there for a long time
> 
> hey, you still haven't fixed the *2 bug...

Sorry -- looks like an older version than the one i have on my local
disk, which did get fixed.  The one on the website is now up to date.

    http://lfw.org/python/inspect.py


-- ?!ng




From jon+sourceforge at unequivocal.co.uk  Thu Oct 26 11:39:01 2000
From: jon+sourceforge at unequivocal.co.uk (Jon Ribbens)
Date: Thu, 26 Oct 2000 10:39:01 +0100
Subject: [Python-Dev] Re: [Bug #117070] README instructions for configuring Setup are not helpful
In-Reply-To: <14839.45989.450533.514732@cj42289-a.reston1.va.home.com>; from fdrake@acm.org on Thu, Oct 26, 2000 at 12:31:33AM -0400
References: <200010251752.KAA02444@sf-web2.i.sourceforge.net> <20001025222406.A8389@snowy.squish.net> <14839.45989.450533.514732@cj42289-a.reston1.va.home.com>
Message-ID: <20001026103901.A11873@snowy.squish.net>

"Fred L. Drake, Jr." <fdrake at acm.org> wrote:
>   Ok, here's the plan:  Change Setup.in to Setup.dist, and provide a
> copy as Setup.  Since this doesn't help if the source and build
> directories differ, configure.in can be modified to create Setup if
> (and only if!) it doesn't exist, by copying it from $srcdir/Modules/.
>   Does this sound agreeable?

Sounds cool. I would mention in the first part of the install instructions
about the Setup file, that you edit it to change the available modules
(this concept is not obvious if you don't know how Python works!),
that you can edit it now but if you have not installed Python before it is
best to try building without editing it first and that there are more
instructions further down the README. You might like to mention 'readline'
here too to head-off newsgroup questions about why up-arrow doesn't work ;-).

Cheers


Jon



From guido at python.org  Thu Oct 26 13:38:34 2000
From: guido at python.org (Guido van Rossum)
Date: Thu, 26 Oct 2000 06:38:34 -0500
Subject: [Python-Dev] sys.__stdout__
In-Reply-To: Your message of "Wed, 25 Oct 2000 23:55:13 -0400."
             <14839.43809.850142.50138@cj42289-a.reston1.va.home.com> 
References: <200010251513.KAA28803@cj20424-a.reston1.va.home.com> <ECEPKNMJLHAPFFJHDOJBOEOFDOAA.MarkH@ActiveState.com>  
            <14839.43809.850142.50138@cj42289-a.reston1.va.home.com> 
Message-ID: <200010261138.GAA04678@cj20424-a.reston1.va.home.com>

>  > * Tools/idle/PyParse.py - disabled, debugging output function - presumably
>  > to get around sys.stdout redirection - but this sounds suspect as an idiom
>  > to me too!
> 
> I've left this one for someone with a good idea about what to do
> about it.

Don't touch it!  This one is needed because at this point sys.stdout
and sys.stderr are redirected to a window where you don't want the
parser debug output to show up.  (I mentioned this example in my
previous post.)

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



From guido at python.org  Thu Oct 26 13:45:49 2000
From: guido at python.org (Guido van Rossum)
Date: Thu, 26 Oct 2000 06:45:49 -0500
Subject: [Python-Dev] Re: [Bug #117070] README instructions for configuring Setup are not helpful
In-Reply-To: Your message of "Thu, 26 Oct 2000 00:31:33 -0400."
             <14839.45989.450533.514732@cj42289-a.reston1.va.home.com> 
References: <200010251752.KAA02444@sf-web2.i.sourceforge.net> <20001025222406.A8389@snowy.squish.net>  
            <14839.45989.450533.514732@cj42289-a.reston1.va.home.com> 
Message-ID: <200010261145.GAA04767@cj20424-a.reston1.va.home.com>

[Fred]
>   Ok, here's the plan:  Change Setup.in to Setup.dist, and provide a
> copy as Setup.  Since this doesn't help if the source and build
> directories differ, configure.in can be modified to create Setup if
> (and only if!) it doesn't exist, by copying it from $srcdir/Modules/.
>   I have the changes to configure.in, configure, Setup*, and
> Modules/Makefile.pre.in ready, but I still need to update the
> instructions in the README & possibly elsewhere.
>   Does this sound agreeable?

Sure, except I'm not comfortable with having two files with identical
contents under CVS control.  How about not checking in Setup, but
creating it in configure if it doesn't exist?

This is necessary also for the following reason: when you build in a
different tree than the source tree, you should get a fresh copy of
Setup in the build tree -- another copy of Setup in the source tree is
useless.

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



From guido at python.org  Thu Oct 26 13:48:20 2000
From: guido at python.org (Guido van Rossum)
Date: Thu, 26 Oct 2000 06:48:20 -0500
Subject: [Python-Dev] getting at the current frame
In-Reply-To: Your message of "Thu, 26 Oct 2000 01:09:44 MST."
             <Pine.LNX.4.10.10010252356410.7079-100000@skuld.kingmanhall.org> 
References: <Pine.LNX.4.10.10010252356410.7079-100000@skuld.kingmanhall.org> 
Message-ID: <200010261148.GAA04780@cj20424-a.reston1.va.home.com>

> Could i humbly re-request approval for inspect.py in the standard library?
> 
>     http://lfw.org/python/inspect.py

To avoid that we forget about this again, and to make sure it gets
proper treatment, could you submit it through the patch manager?  No
need to turn it into a context diff, just upload the entire file.

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



From thomas at xs4all.net  Thu Oct 26 12:21:05 2000
From: thomas at xs4all.net (Thomas Wouters)
Date: Thu, 26 Oct 2000 12:21:05 +0200
Subject: [Python-Dev] A small step to removing the type/class split
In-Reply-To: <200010250114.OAA28255@s454.cosc.canterbury.ac.nz>; from greg@cosc.canterbury.ac.nz on Wed, Oct 25, 2000 at 02:14:52PM +1300
References: <20001024073712.A10539@glacier.fnational.com> <200010250114.OAA28255@s454.cosc.canterbury.ac.nz>
Message-ID: <20001026122105.N12812@xs4all.nl>

On Wed, Oct 25, 2000 at 02:14:52PM +1300, Greg Ewing wrote:
> Neil Schemenauer <nas at arctrix.com>:

> > Those PyInstance_Check() calls should really go away. Instead, the
> > type should be responsible for providing different behavior.

> Yes, that's the crux of the problem, I think.

> Another place where this is a nuisance is where it
> assumes that if x has any tp_as_sequence slots and y
> has any tp_as_number slots, then x*y is a sequence
> replication operation.

This is screwed in more than one way. The logic of which 'type' operation
has precedence isn't even internally consistent. The case of 'x*y' and 'x+y'
check the tp_as_number and tp_as_sequence slots in a *different order*, so
'x*y' can end up a number where 'x+y' ends up a sequence. (Or the other way
'round, I forget. I'm also struggling to catch up on my mail since Apachecon
had little to no connectivity, so I don't feel like checking :)

Brainwashed-into-Apache-2.0-forever-ly y'rs,
-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!



From thomas at xs4all.net  Thu Oct 26 12:51:30 2000
From: thomas at xs4all.net (Thomas Wouters)
Date: Thu, 26 Oct 2000 12:51:30 +0200
Subject: [Python-Dev] ViewCVS on Sourceforge
Message-ID: <20001026125130.O12812@xs4all.nl>

I had a chat with Greg Stein about ViewCVS on the ApacheCon (I think Jon
Travis and Gregory Trubetskoy where there as well, but my memory is a bit
hazy) and since he's probably in some airplane over the atlantic right now,
I'll run away and steal his idea ;) We were kind of reflecting how nice it
would be if we could have ViewCVS, instead of cvsweb, on SourceForge. The
nice thing about ViewCVS is that it's a lot more efficient than cvsweb, and
it doesn't need write access to the repository itself. So how about we run
ViewCVS on python.sourceforge.net ourselves ?

We could do it now, in fact, with the complete CVS snapshot that gets made
every once in a while (that *does* still get made & backupped, right ?)
though it would obviously be a lot more useful if ViewCVS just had direct
access to the repository. I'm not sure how accessible that repository is,
however. Cursory searches on shell.sourceforge.net doesn't show anything,
except that the python-cvs.tgz that's in /home/projects/python is apparently
the one used for the move to sourceforge :-) Can we get access to the
repository directly, even if it's only semi-realtime ? (I wouldn't mind
doing a couple of rsync's in cron to keep it up to date) If anything,
running ViewCVS will show SourceForge how much nicer it is... ;-)

-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!



From jon+sourceforge at unequivocal.co.uk  Thu Oct 26 13:01:27 2000
From: jon+sourceforge at unequivocal.co.uk (Jon Ribbens)
Date: Thu, 26 Oct 2000 12:01:27 +0100
Subject: [Python-Dev] Re: [Bug #117070] README instructions for configuring Setup are not helpful
In-Reply-To: <200010261145.GAA04767@cj20424-a.reston1.va.home.com>; from guido@python.org on Thu, Oct 26, 2000 at 06:45:49AM -0500
References: <200010251752.KAA02444@sf-web2.i.sourceforge.net> <20001025222406.A8389@snowy.squish.net> <14839.45989.450533.514732@cj42289-a.reston1.va.home.com> <200010261145.GAA04767@cj20424-a.reston1.va.home.com>
Message-ID: <20001026120127.B11873@snowy.squish.net>

Guido van Rossum <guido at python.org> wrote:
> Sure, except I'm not comfortable with having two files with identical
> contents under CVS control.  How about not checking in Setup, but
> creating it in configure if it doesn't exist?

I think that would be fine so long as the README file makes it clear that
you edit the Setup file after './configure' but before 'make'.

Cheers


Jon



From mal at lemburg.com  Thu Oct 26 13:23:19 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Thu, 26 Oct 2000 13:23:19 +0200
Subject: [Python-Dev] 2.0 articles
References: <E13oYSS-00071f-00@kronos.cnri.reston.va.us>
Message-ID: <39F81427.FF4223C2@lemburg.com>

Andrew Kuchling wrote:
> 
> I'd like to begin writing an article about 2.0's Unicode support.
> Before beginning, has anyone else already begun this task?  If yes,
> please let me know...

I've already started something in that direction. The plan is to
write down the story of adding Unicode support to Python, the
pifalls, solutions, hacks, etc. I'll probably submit it to DDJ.

A article about *using* Unicode support would of course
be a nice complement to get a feeling of how it's like working
with the implementation :-)
 
> (Incidentally, did a 2.0 press release ever go out?  Is someone going
> to write one?)
> 
> --amk
> 
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://www.python.org/mailman/listinfo/python-dev

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From fdrake at acm.org  Thu Oct 26 14:21:08 2000
From: fdrake at acm.org (Fred L. Drake, Jr.)
Date: Thu, 26 Oct 2000 08:21:08 -0400 (EDT)
Subject: [Python-Dev] sys.__stdout__
In-Reply-To: <200010261138.GAA04678@cj20424-a.reston1.va.home.com>
References: <200010251513.KAA28803@cj20424-a.reston1.va.home.com>
	<ECEPKNMJLHAPFFJHDOJBOEOFDOAA.MarkH@ActiveState.com>
	<14839.43809.850142.50138@cj42289-a.reston1.va.home.com>
	<200010261138.GAA04678@cj20424-a.reston1.va.home.com>
Message-ID: <14840.8628.315347.722506@cj42289-a.reston1.va.home.com>

I wrote:
 > I've left this one for someone with a good idea about what to do
 > about it.

Guido van Rossum replied:
 > Don't touch it!  This one is needed because at this point sys.stdout
 > and sys.stderr are redirected to a window where you don't want the
 > parser debug output to show up.

  See, I knew someone would come up with a better idea!  ;)


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at acm.org>
PythonLabs Team Member




From skip at mojam.com  Thu Oct 26 14:31:36 2000
From: skip at mojam.com (Skip Montanaro)
Date: Thu, 26 Oct 2000 07:31:36 -0500 (CDT)
Subject: [Python-Dev] Re: [Bug #117070] README instructions for configuring Setup are not helpful
In-Reply-To: <14839.45989.450533.514732@cj42289-a.reston1.va.home.com>
References: <200010251752.KAA02444@sf-web2.i.sourceforge.net>
	<20001025222406.A8389@snowy.squish.net>
	<14839.45989.450533.514732@cj42289-a.reston1.va.home.com>
Message-ID: <14840.9256.408848.728486@beluga.mojam.com>

    Fred> Ok, here's the plan: Change Setup.in to Setup.dist, and provide a
    copy as Setup.

I don't like the idea that a file I am supposed to edit (Setup) would be in
the CVS repository where it could conceivably get messed with by a "cvs up"
command.  The current makefile target that emits a warning if Setup.in
(.dist) is newer than Setup should be sufficient to alert users when Setup
needs to be looked at.

-- 
Skip Montanaro (skip at mojam.com)
http://www.mojam.com/
http://www.musi-cal.com/



From skip at mojam.com  Thu Oct 26 14:34:09 2000
From: skip at mojam.com (Skip Montanaro)
Date: Thu, 26 Oct 2000 07:34:09 -0500 (CDT)
Subject: [Python-Dev] getting at the current frame
In-Reply-To: <Pine.LNX.4.10.10010252356410.7079-100000@skuld.kingmanhall.org>
References: <14837.60682.437334.797392@anthem.concentric.net>
	<Pine.LNX.4.10.10010252356410.7079-100000@skuld.kingmanhall.org>
Message-ID: <14840.9409.491061.671168@beluga.mojam.com>

    Ping> Could i humbly re-request approval for inspect.py in the standard
    Ping> library?

    Ping>     http://lfw.org/python/inspect.py

+1.  I've written functions over the years to do some small bits of what
inspect.py does.  I'd much rather have those things in a standard place with
more eyeballs checking them for correctness.

Skip



From akuchlin at mems-exchange.org  Thu Oct 26 14:56:26 2000
From: akuchlin at mems-exchange.org (Andrew Kuchling)
Date: Thu, 26 Oct 2000 08:56:26 -0400
Subject: [Python-Dev] 2.0 articles
In-Reply-To: <39F81427.FF4223C2@lemburg.com>; from mal@lemburg.com on Thu, Oct 26, 2000 at 01:23:19PM +0200
References: <E13oYSS-00071f-00@kronos.cnri.reston.va.us> <39F81427.FF4223C2@lemburg.com>
Message-ID: <20001026085626.A27785@kronos.cnri.reston.va.us>

On Thu, Oct 26, 2000 at 01:23:19PM +0200, M.-A. Lemburg wrote:
>A article about *using* Unicode support would of course
>be a nice complement to get a feeling of how it's like working

And that's what I want to write, so it works out nicely; great!

Finn, your comment has been noted; I'll take note of any differences
with Jython's Unicode support.  A draft will be announced on
python-dev, whenever it actually gets done.

--amk




From mal at lemburg.com  Thu Oct 26 15:07:35 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Thu, 26 Oct 2000 15:07:35 +0200
Subject: [Python-Dev] Gradual migration
References: <39F52EF1.A201C6D9@prescod.net> <39F54C0F.25798309@lemburg.com> <39F5B4DC.C226D8F6@prescod.net> <39F5E4FA.9FD6D35@lemburg.com> <39F72256.C7F93BFB@prescod.net>
Message-ID: <39F82C97.12D04C85@lemburg.com>

Paul Prescod wrote:
> 
> "M.-A. Lemburg" wrote:
> >
> > ...
> >
> > >  * implementation language and Python inheritance semantics are almost
> > > completely distinct. After all, we have Python implementations in a
> > > variety of languages with minor incompatibilities. Python could have a
> > > proper type/class merging even if it were written in assembly language.
> > > So let's leave implementation language aside.
> >
> > Hey, think of it as opportunity: we can reuse much of C++'s
> > optimizations and the integration of Python and C++ applications
> > will get *much* easier.
> 
> We could make integrating C++ and Python easier through CXX or Py_Cpp.
> Perhaps we should ship one of those with Python 2.1. Anyhow, integrating
> C++ and Python is not really so hard, in my experience.

Ok, you can use SWIG to get most of the work done, but the interface
between the C++ object world and the Python object world is one
big mess -- all implementations I've seen use shadow objects
or proxies to interface from one to the other... with lots of
temporary objects used for the linkup.

Having Python itself written in C++ we could do *much* better.

But that's only a nice side-effect. The real argument here is
that we can push the type logic one layer further down. Ideal would
be a level of integration such as the one implemented in JPython
or Jython.
 
> > A rewrite shouldn't scare anyone away -- much of the existing
> > code can be reused since only the Python C APIs of the various
> > types will have to be rewritten, not the logic behind the types.
> 
> I wasn't really addressing the issue of backwards compatibility of
> extensions -- I was talking about Python programs. Nevertheless, I can't
> resist:
> 
> Porting your app to the Python APIs is often the majority of the work in
> a particular extension. A lot of Python extensions consist only of API
> glue!

True, but we're lucky, since we could provide a compatibility
layer on top of the new API.

BTW, I think I now know what your main concern is: the Python
level compatibility. I was talking of what goes on under the
hood and still think that Py3K should be used as a chance to
simplify the Python backend. As simplification often means
generalization, we'll open up new doors for future developments
along the way.

> > > I don't know what you mean by a "low-level strategy" for classes. It's
> > > not like we can somehow use C++ vtables without giving up Python's
> > > dynamicity. Python's class handling is about as low-level as it can get
> > > in my humble opinion.
> >
> > With "low-level" I meant trying to build Python classes and
> > instances on top of a very thin layer on top of C++ classes,
> > e.g. all slots could be implemented using true C++ methods with
> > additional logic to override them using dynamically bound
> > Python method objects.
> 
> I don't think that there is really interesting magic in a C++ compiler.
> A vtable is an array of pointers to functions. We've already implemented
> the equivalent in ANSI C. C++ exceptions, constructors, destriuctors and
> smart pointers are a little more interesting from a code maintenance and
> simplicity point of view. But even then I think that we could get to a
> C++ implementation through incremental rewrites.

Naa, the whole type slot interface is one big mess (sorry, Guido :-).
some slots are packaged, some are not, some are NULL, some are not,
there are oodles of sometimes weird dependencies between the
slots which are not really documented, etc. etc.

The slot design has serious drawbacks and should be replaced by
something more reliable, preferably C++ methods. That way, we'll
get some more "type" safety into Python and its extensions.

Note that porting old extensions won't be all that hard: 
a class reusing the existing slot functions as methods should
suffice in many cases.

> > Why spoil all the fun when we haven't even started thinking
> > about all the possibilities we could use to make Py3k a
> > success ?
> 
> Asking for a map of where we are going and how we will get here is
> "spoiling all of the fun?" I'm not sure what you are reacting to -- I
> didn't advise one implementation strategy or another -- I just said that
> we should employ a strategy that minimizes sudden and surprising code
> breakage.

Ok, we've been talking about different things here: with "spoiling
the fun" I meant putting ropes on possible changes to the C 
backend. 

You are talking about the frontend and I agree with you
that there should be a clear upgrade path from the 2.x series
to Py3K w/r to the Python side of things.

So I guess it's time for some PEPs now... the upgrade path
PEP and the fluffy clouds PEP.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From guido at python.org  Thu Oct 26 16:42:40 2000
From: guido at python.org (Guido van Rossum)
Date: Thu, 26 Oct 2000 09:42:40 -0500
Subject: [Python-Dev] Re: [Bug #117070] README instructions for configuring Setup are not helpful
In-Reply-To: Your message of "Thu, 26 Oct 2000 12:01:27 +0100."
             <20001026120127.B11873@snowy.squish.net> 
References: <200010251752.KAA02444@sf-web2.i.sourceforge.net> <20001025222406.A8389@snowy.squish.net> <14839.45989.450533.514732@cj42289-a.reston1.va.home.com> <200010261145.GAA04767@cj20424-a.reston1.va.home.com>  
            <20001026120127.B11873@snowy.squish.net> 
Message-ID: <200010261442.JAA05046@cj20424-a.reston1.va.home.com>

> I think that would be fine so long as the README file makes it clear that
> you edit the Setup file after './configure' but before 'make'.

One thing -- it's perfectly fine to edit Setup after running Make for
the first time.  You just have to run Make again.  The Makefiles are
designed for this.

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



From paul at prescod.net  Thu Oct 26 15:56:40 2000
From: paul at prescod.net (Paul Prescod)
Date: Thu, 26 Oct 2000 06:56:40 -0700
Subject: [Python-Dev] Gradual migration
References: <39F52EF1.A201C6D9@prescod.net> <39F54C0F.25798309@lemburg.com> <39F5B4DC.C226D8F6@prescod.net> <39F5E4FA.9FD6D35@lemburg.com> <39F72256.C7F93BFB@prescod.net> <39F82C97.12D04C85@lemburg.com>
Message-ID: <39F83818.38EA64AE@prescod.net>

"M.-A. Lemburg" wrote:
> 
> ...
> 
> Having Python itself written in C++ we could do *much* better.

Agree.

> ...
> 
> The slot design has serious drawbacks and should be replaced by
> something more reliable, preferably C++ methods. That way, we'll
> get some more "type" safety into Python and its extensions.

I agree that the slot stuff is broken but my solution would be to junk
it and use the same mechanism for looking up "type methods" and
"instance methods". I can think of two ways to make that perform
reasonably: one is method caching and the other is by building interface
objects where methods are invoked by index -- basically vtables. But if
the same mechanism is going to accelerate Python and C types alike then
it can't really use C++ vtables because how do you generate a vtable at
runtime for a new Python class? (you could also think of it as a COM
interface object)

> So I guess it's time for some PEPs now... the upgrade path
> PEP and the fluffy clouds PEP.

Good timing. I just finished the first draft of the upgrade path PEP.

-- 
 Paul Prescod - Not encumbered by corporate consensus
Simplicity does not precede complexity, but follows it. 
	- http://www.cs.yale.edu/homes/perlis-alan/quotes.html



From barry at wooz.org  Thu Oct 26 15:24:49 2000
From: barry at wooz.org (Barry A. Warsaw)
Date: Thu, 26 Oct 2000 09:24:49 -0400 (EDT)
Subject: [Python-Dev] getting at the current frame
References: <14837.60682.437334.797392@anthem.concentric.net>
	<Pine.LNX.4.10.10010252356410.7079-100000@skuld.kingmanhall.org>
	<14840.9409.491061.671168@beluga.mojam.com>
Message-ID: <14840.12449.241947.715016@anthem.concentric.net>

>>>>> "SM" == Skip Montanaro <skip at mojam.com> writes:

    Ping> Could i humbly re-request approval for inspect.py in the
    Ping> standard library?

    Ping> http://lfw.org/python/inspect.py

    SM> +1.  I've written functions over the years to do some small
    SM> bits of what inspect.py does.  I'd much rather have those
    SM> things in a standard place with more eyeballs checking them
    SM> for correctness.

I've downloaded it, and will take a look.



From jim at interet.com  Thu Oct 26 16:03:43 2000
From: jim at interet.com (James C. Ahlstrom)
Date: Thu, 26 Oct 2000 10:03:43 -0400
Subject: [Python-Dev] What to choose to replace Tkinter?
References: <14837.14407.954185.466011@buffalo.fnal.gov> <ECEPKNMJLHAPFFJHDOJBKEKIDOAA.MarkH@ActiveState.com> <14837.43273.24692.93965@buffalo.fnal.gov> <20001024114326.E13957@kronos.cnri.reston.va.us>  
	            <39F6B8B8.E3242929@interet.com> <200010251225.HAA22242@cj20424-a.reston1.va.home.com>
Message-ID: <39F839BF.DD1B86BF@interet.com>

Guido van Rossum wrote:

> To me this all sounds like FUD.

True, but FUD is real and I have no apologies.

> Since Python 1.6 and 2.0, you don't
> have to install Tcl/Tk or its libraries -- it is installed
> *transparently* by the Python Windows installer.

We don't use the Python Windows installer.  Our app
has to use its own installer, and I would then have to run
two installers, one of which I don't understand.

Sorry to be such an old fuddy-duddy, but you will
get the same reaction from most commercial software
vendors.  Make that nearly ALL vendors.

JimA



From jim at interet.com  Thu Oct 26 16:06:02 2000
From: jim at interet.com (James C. Ahlstrom)
Date: Thu, 26 Oct 2000 10:06:02 -0400
Subject: [Python-Dev] What to choose to replace Tkinter?
References: <Pine.LNX.4.10.10010241146450.6622-100000@akbar.nevex.com> <200010241739.MAA16414@cj20424-a.reston1.va.home.com>  
	            <39F6BA29.3CAB4C0E@interet.com> <200010251227.HAA22256@cj20424-a.reston1.va.home.com>
Message-ID: <39F83A4A.26E543A3@interet.com>

Guido van Rossum wrote:

> Even Microsoft is violating its own (boring) style guide, when they
> think it appeals to a specific audience.  Have you seen their Media
> Player?

Yes, very slick.  My daughter has an app where you click on
doors to access parts of the program.  Nice design.

JimA



From gward at mems-exchange.org  Thu Oct 26 16:18:50 2000
From: gward at mems-exchange.org (Greg Ward)
Date: Thu, 26 Oct 2000 10:18:50 -0400
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: <39F83A4A.26E543A3@interet.com>; from jim@interet.com on Thu, Oct 26, 2000 at 10:06:02AM -0400
References: <Pine.LNX.4.10.10010241146450.6622-100000@akbar.nevex.com> <200010241739.MAA16414@cj20424-a.reston1.va.home.com> <39F6BA29.3CAB4C0E@interet.com> <200010251227.HAA22256@cj20424-a.reston1.va.home.com> <39F83A4A.26E543A3@interet.com>
Message-ID: <20001026101850.A14742@ludwig.cnri.reston.va.us>

On 26 October 2000, James C. Ahlstrom said:
> Guido van Rossum wrote:
> 
> > Even Microsoft is violating its own (boring) style guide, when they
> > think it appeals to a specific audience.  Have you seen their Media
> > Player?
> 
> Yes, very slick.  My daughter has an app where you click on
> doors to access parts of the program.  Nice design.

This is generally considered Bad Form by usability types.  I think it
boils down to this: the computer is not the real world, and trying to
emulate the real world on the computer is cutesy but a dead end.

Go look for "User Interface Hall of Shame" at your friendly
neighbourhood search engine for many enjoyable rants against bad GUI
design, including the "emulate the real world" school of thought.

Anyways, this is not a usability mailing list... back to our regularly
scheduled python-dev...

        Greg
-- 
Greg Ward - software developer                gward at mems-exchange.org
MEMS Exchange / CNRI                           voice: +1-703-262-5376
Reston, Virginia, USA                            fax: +1-703-262-5367



From paul at prescod.net  Thu Oct 26 16:28:12 2000
From: paul at prescod.net (Paul Prescod)
Date: Thu, 26 Oct 2000 07:28:12 -0700
Subject: [Python-Dev] Gradual migration PEP
Message-ID: <39F83F7C.2241158F@prescod.net>

PEP: XXX 
Title: Guidelines for introducing backwards incompatibilities 
Version: $Revision: 1.0 $ 
Author: Paul Prescod <paul at prescod.net,paulp at activestate.com> 
Status: Draft Type: Standards Track 
Python-Version: All
Created: 25-Oct-2000

Abstract

    In the natural evolution of programming languages it is sometimes
    necessary to make changes that modify the behaviour of older
programs.
    This PEP proposes a policy for implementing these changes in a
manner
    respectful of the installed base of Python users.

Implementation Details

    Implementation of this PEP requires the addition of a formal warning
    and deprecation facility that will be described in another proposal.

Scope

    These guidelines apply to future versions of Python that introduce
    backward-incompatible behaviour. Backward incompatible behaviour is
    a major deviation in Python interpretation from an earlier behaviour
    described in the standard Python documentation. Removal of a feature
    also constitutes a change of behaviour.

    This PEP does not replace or preclude other compatibility strategies
    such as dynamic loading of backwards-compatible parsers. On the
    other hand, if execution of "old code" requires a special switch or
    pragma then that is indeed a change of behavior from the point of
    view of the user and that change should be implemented according to
    these guidelines.

    In general, common sense must prevail in the implementation of these
    guidelines. For instance changing "sys.copyright" does not
constitute
    a backwards-incompatible change of behavior!

Steps For Introducting Backwards-Incompatible Features

    1. Propose backwards-incompatible behavior in a PEP. The PEP must
       include a section on backwards compatibility that describes in
       detail a plan to complete the remainder of these steps.

    2. Once the PEP is accepted as a productive direction, implement an
       alternate way to accomplish the task previously provided by the
       feature that is being removed or changed. For instance if the
       addition operator were scheduled for removal, a new version of
       Python could implement an "add()" built-in function.

    3. Formally deprecate the obsolete construct in the Python
       documentation.

    4. Add an an optional warning mode to the parser that will inform
       users when the deprecated construct is used. In other words, all
       programs that will behave differently in the future must trigger
       warnings in this mode. Compile-time warnings are preferable to
       runtime warnings. The warning messages should steer people from
       the deprecated construct to the alternative construct.

    5. There must be at least a one-year transition period between
       the release of the transitional version of Python and the release
       of the backwards incompatible version. Users will have at least
       a year to test their programs and migrate them from use of the
       deprecated construct to the alternative one.


Local Variables: 
mode: indented-text 
indent-tabs-mode: nil 
End:



From paul at prescod.net  Thu Oct 26 16:35:48 2000
From: paul at prescod.net (Paul Prescod)
Date: Thu, 26 Oct 2000 07:35:48 -0700
Subject: [Python-Dev] What to choose to replace Tkinter?
References: <ECEPKNMJLHAPFFJHDOJBCEOADOAA.MarkH@ActiveState.com>
Message-ID: <39F84144.105D1754@prescod.net>

Mark Hammond wrote:
> 
>...
> 
> I don't think it will be "fixed", as it is not considered "broken".  It was
> an explicit choice to leave out Tcl/Tk.  And my recollection is that the
> "feedback" address sees more requests for wxPython than Tcl/Tk.

That's all true. We also make it very easy to find the right version of
Tcl/Tk and will probably go even farther in this direction in the
future. Built-in Tcl/Tk support is not out of the question but there are
various user confusion issues: "Why are there two GUI frameworks in this
development environment? Why are there two development environments in
this development environment? Doesn't ActiveState have yet another GUI
framework and development environment under development?" "Why do I need
Tcl at all? What is its relationship with Python?

There are clear benefits to including Tcl/Tk but there are also costs
and its possible we'll weigh them differently in the future.

BTW: ActivePython does include Tkinter.

-- 
 Paul Prescod
Simplicity does not precede complexity, but follows it. 
	- http://www.cs.yale.edu/homes/perlis-alan/quotes.html



From gmcm at hypernet.com  Thu Oct 26 16:49:20 2000
From: gmcm at hypernet.com (Gordon McMillan)
Date: Thu, 26 Oct 2000 10:49:20 -0400
Subject: [Python-Dev] Gradual migration
In-Reply-To: <39F82C97.12D04C85@lemburg.com>
Message-ID: <39F80C30.5448.52D32F94@localhost>

[Paul]
> > We could make integrating C++ and Python easier through CXX or Py_Cpp.
> > Perhaps we should ship one of those with Python 2.1. Anyhow, integrating
> > C++ and Python is not really so hard, in my experience.

... or a number of others (but SWIG falls very short when it 
comes to things like C++ references)...

[Marc-Andre]
> Ok, you can use SWIG to get most of the work done, but the interface
> between the C++ object world and the Python object world is one
> big mess -- all implementations I've seen use shadow objects
> or proxies to interface from one to the other... with lots of
> temporary objects used for the linkup.

While I agree it's messy, those are not the objectionable 
qualities. Any refcounted C++ system is going to have proxies 
(smart pointers / refcounting stack-safe "reference" objects to 
the real heap-based objects).

And while I think we'd be better off with a C++ implementation, 
I would warn that C++'s notion of inheritence is in conflict with 
Python's. It won't be "as above, so below" (unless we screw 
interpreting and go straight to native code). Assuming that the 
class / type dichotomy actually gets healed, that is.
 
> ... The real argument here is
> that we can push the type logic one layer further down. Ideal would
> be a level of integration such as the one implemented in JPython
> or Jython.

Nope. If you heal the class / type split, there's really only one 
underlying type object. Unless you go the other way, and write 
"native" code (as JPython does).

All of the existing C++ interfaces / helpers deal only with type 
objects (at least, those that I've examined, which is most of 
them). In fact, only ExtensionClass attempts to deal with the 
class / type split, and while it's a masterpiece, I think it's a 
great example of everything to avoid in Py3K.
  


- Gordon



From barry at wooz.org  Thu Oct 26 16:58:23 2000
From: barry at wooz.org (Barry A. Warsaw)
Date: Thu, 26 Oct 2000 10:58:23 -0400 (EDT)
Subject: [Python-Dev] Gradual migration
References: <39F52EF1.A201C6D9@prescod.net>
	<39F54C0F.25798309@lemburg.com>
	<39F5B4DC.C226D8F6@prescod.net>
	<39F5E4FA.9FD6D35@lemburg.com>
	<39F72256.C7F93BFB@prescod.net>
	<39F82C97.12D04C85@lemburg.com>
	<39F83818.38EA64AE@prescod.net>
Message-ID: <14840.18063.152674.534458@anthem.concentric.net>

>>>>> "PP" == Paul Prescod <paul at prescod.net> writes:

    PP> I agree that the slot stuff is broken but my solution would be
    PP> to junk it and use the same mechanism for looking up "type
    PP> methods" and "instance methods". I can think of two ways to
    PP> make that perform reasonably: one is method caching and the
    PP> other is by building interface objects where methods are
    PP> invoked by index -- basically vtables. But if the same
    PP> mechanism is going to accelerate Python and C types alike then
    PP> it can't really use C++ vtables because how do you generate a
    PP> vtable at runtime for a new Python class? (you could also
    PP> think of it as a COM interface object)

Objective-C!

:)



From effbot at telia.com  Thu Oct 26 17:14:28 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Thu, 26 Oct 2000 17:14:28 +0200
Subject: [Python-Dev] What to choose to replace Tkinter?
References: <14837.14407.954185.466011@buffalo.fnal.gov> <ECEPKNMJLHAPFFJHDOJBKEKIDOAA.MarkH@ActiveState.com> <14837.43273.24692.93965@buffalo.fnal.gov> <20001024114326.E13957@kronos.cnri.reston.va.us>              <39F6B8B8.E3242929@interet.com> <200010251225.HAA22242@cj20424-a.reston1.va.home.com> <39F839BF.DD1B86BF@interet.com>
Message-ID: <002a01c03f5f$71ca72f0$3c6340d5@hagrid>

jim wrote:
> Sorry to be such an old fuddy-duddy, but you will
> get the same reaction from most commercial software
> vendors.  Make that nearly ALL vendors.

what reaction?

are you saying that your own installer can install the
Python DLL but not the Tk DLL?

</F>




From gmcm at hypernet.com  Thu Oct 26 17:05:02 2000
From: gmcm at hypernet.com (Gordon McMillan)
Date: Thu, 26 Oct 2000 11:05:02 -0400
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: <20001026101850.A14742@ludwig.cnri.reston.va.us>
References: <39F83A4A.26E543A3@interet.com>; from jim@interet.com on Thu, Oct 26, 2000 at 10:06:02AM -0400
Message-ID: <39F80FDE.6102.52E19102@localhost>

James C. Ahlstrom said:

> > Yes, very slick.  My daughter has an app where you click on
> > doors to access parts of the program.  Nice design.

[Greg Ward] 
> This is generally considered Bad Form by usability types.  I think it
> boils down to this: the computer is not the real world, and trying to
> emulate the real world on the computer is cutesy but a dead end.

I once interviewed with a game designer (sports games - 
popular ones, too). He spent half an hour slamming MS's UI 
(his games run on Windows). Then he pulled up his latest 
(opening to a sports stadium) and said "Now here's a real UI". 
So I said "Show me how it works". 

The bozo ended up clicking on random things on the screen 
until something finally happened.

no-no-the-beer-means-OK--the-bimbo-means-CANCEL-ly y'rs

- Gordon



From barry at wooz.org  Thu Oct 26 17:36:37 2000
From: barry at wooz.org (barry at wooz.org)
Date: Thu, 26 Oct 2000 11:36:37 -0400 (EDT)
Subject: [Python-Dev] getting at the current frame
References: <14837.60682.437334.797392@anthem.concentric.net>
	<Pine.LNX.4.10.10010252356410.7079-100000@skuld.kingmanhall.org>
Message-ID: <14840.20357.734136.911927@anthem.concentric.net>

>>>>> "KY" == Ka-Ping Yee <ping at lfw.org> writes:

    >>  Okay, we all know that's a pain, right?  Lots of people have
    >> proposed solutions.  I've looked briefly at !?ng's Itpl.py, but
    >> I think it probably does too much by adding evaluation.

    KY> Do you think a variant of Itpl that only looked up variable
    KY> names would solve your problem?

I think it would calm my objections, yes.  I'll observe that I think
there may be a middle ground between my approach and Itpl.  I've found
a couple of situations where I want a minimal form of evaluation,
e.g. I want attributes to be expanded (and methods called), but not a
general evaluation facility.  So for example, I'd like to be able to
say:

    print _("The name of the mailing list is %(mlist.listname())s")

What worries me about a general evaluation framework is that we then
have to be really really careful about security and origin of the
strings we're using here.  Maybe we'd need to adopt something like
Perl's taint strings.

    KY> How about this routine to get the current frame:
    KY> inspect.currentframe().

It uses the same intentional-exception trick to get at the current
frame.  It's about 8x faster to do it in C.  I'll note that your
version raises and catches a string exception, while mine uses an
exception instance.  I don't see much difference in speed between the
two.

    KY> If there are changes that need to be made before it can be
    KY> accepted, i'd be happy to make them.

Sent under a separate private response...

-Barry



From gward at mems-exchange.org  Thu Oct 26 18:03:09 2000
From: gward at mems-exchange.org (Greg Ward)
Date: Thu, 26 Oct 2000 12:03:09 -0400
Subject: [Python-Dev] getting at the current frame
In-Reply-To: <14837.60682.437334.797392@anthem.concentric.net>; from barry@wooz.org on Tue, Oct 24, 2000 at 04:11:54PM -0400
References: <14837.60682.437334.797392@anthem.concentric.net>
Message-ID: <20001026120308.B14742@ludwig.cnri.reston.va.us>

On 24 October 2000, Barry A. Warsaw said:
> All well and good and doable in Python today, except getting the
> current frame with the exception raising trick is slooow.  A simple
> proposed addition to the sys module can improve the performance by
> about 8x:
> 
>     def _(s):
>         frame = sys.getcaller(1)
> 	d = frame.f_globals.copy()
> 	d.update(frame.f_locals())
> 	return the_translation_of(s) % d
> 
> The implementation of sys.getcaller() is given in the below patch.
> Comments?  I think this particular addition is too small for a PEP,
> although ?!ng still owns PEP 215 (which needs filling in).

+1.  Not sure if I would call that function 'getcaller()' or
'getframe()'; could go either way.

In my implementation of this (I guess everyone has one!), I also have a
couple of convenience functions:

  def get_caller_env (level=1):
      """get_caller_env(level : int = 1) -> (globals : dict, locals : dict)

      Return the environment of a caller: its dictionaries of global and
      local variables.  'level' has same meaning as for 'caller()'.
      """

  def get_frame_info (frame):
      """get_frame_info(frame)
         -> (filename : string,
             lineno : int,
             function_name : string,
             code_line : string)

      Extracts and returns a tuple of handy information from an execution
      frame.
      """

  def get_caller_info (level=1):
      """get_caller_info(level : int = 1)
         -> (filename : string,
             lineno : int,
             function_name : string,
             code_line : string)

      Extracts and returns a tuple of handy information from some caller's
      execution frame.  'level' is the same as for 'caller()', i.e.  if
      level is 1 (the default), gets this information about the caller of
      the function that is calling 'get_caller_info()'.
      """

These are mainly used by my unit-testing framework (which you'll no
doubt remember, Barry) to report where test failures originate.  Very
handy!

Looks like Ping's inspect.py has something like my 'get_frame_info()',
only it's called 'getframe()'.  Obviously this is the wrong name if
Barry's new function gets added as 'sys.getframe()'.  How 'bout this:

  sys.getframe(n)
    - return stack frame for depth 'n'
  inspect.getframeinfo(frame)
    - return (filename, line number, function name, lines-of-code)

Although I haven't grokked Ping's module enough to know if that rename
really fits his scheme.

        Greg
-- 
Greg Ward - software developer                gward at mems-exchange.org
MEMS Exchange / CNRI                           voice: +1-703-262-5376
Reston, Virginia, USA                            fax: +1-703-262-5367



From jon+sourceforge at unequivocal.co.uk  Thu Oct 26 18:57:01 2000
From: jon+sourceforge at unequivocal.co.uk (Jon Ribbens)
Date: Thu, 26 Oct 2000 17:57:01 +0100
Subject: [Python-Dev] Re: [Bug #117070] README instructions for configuring Setup are not helpful
In-Reply-To: <200010261442.JAA05046@cj20424-a.reston1.va.home.com>; from guido@python.org on Thu, Oct 26, 2000 at 09:42:40AM -0500
References: <200010251752.KAA02444@sf-web2.i.sourceforge.net> <20001025222406.A8389@snowy.squish.net> <14839.45989.450533.514732@cj42289-a.reston1.va.home.com> <200010261145.GAA04767@cj20424-a.reston1.va.home.com> <20001026120127.B11873@snowy.squish.net> <200010261442.JAA05046@cj20424-a.reston1.va.home.com>
Message-ID: <20001026175701.A4983@snowy.squish.net>

Guido van Rossum <guido at python.org> wrote:
> One thing -- it's perfectly fine to edit Setup after running Make for
> the first time.  You just have to run Make again.  The Makefiles are
> designed for this.

Mention this too ;-)



From fdrake at acm.org  Thu Oct 26 19:24:54 2000
From: fdrake at acm.org (Fred L. Drake, Jr.)
Date: Thu, 26 Oct 2000 13:24:54 -0400 (EDT)
Subject: [Python-Dev] Setup changes are checked in
Message-ID: <14840.26854.546598.565061@cj42289-a.reston1.va.home.com>

  I've checked in the changes to the handling of the Modules/Setup
file as we've discussed here.

  - Setup.in is now Setup.dist
  - Setup is created by configure
  - README and other instructions, comments, and documentation has
    been updated to reflect these changes


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at acm.org>
PythonLabs Team Member




From fdrake at acm.org  Thu Oct 26 19:30:22 2000
From: fdrake at acm.org (Fred L. Drake, Jr.)
Date: Thu, 26 Oct 2000 13:30:22 -0400 (EDT)
Subject: [Python-Dev] development version of docs online
Message-ID: <14840.27182.548970.193402@cj42289-a.reston1.va.home.com>

  Do people want to be notified when the development copy of the
documentation is update?  There was a comment from someone that they
didn't know where the online copy was.  I can send the update notice
to python-dev instead of just to myself if everyone wants it, or I can
send it to some other (appropriate) list.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at acm.org>
PythonLabs Team Member




From trentm at ActiveState.com  Thu Oct 26 19:42:30 2000
From: trentm at ActiveState.com (Trent Mick)
Date: Thu, 26 Oct 2000 10:42:30 -0700
Subject: [Python-Dev] development version of docs online
In-Reply-To: <14840.27182.548970.193402@cj42289-a.reston1.va.home.com>; from fdrake@acm.org on Thu, Oct 26, 2000 at 01:30:22PM -0400
References: <14840.27182.548970.193402@cj42289-a.reston1.va.home.com>
Message-ID: <20001026104230.B23283@ActiveState.com>

On Thu, Oct 26, 2000 at 01:30:22PM -0400, Fred L. Drake, Jr. wrote:
> 
>   Do people want to be notified when the development copy of the
> documentation is update?  There was a comment from someone that they

Yes, please.

Trent


-- 
Trent Mick
TrentM at ActiveState.com



From jim at interet.com  Thu Oct 26 21:34:03 2000
From: jim at interet.com (James C. Ahlstrom)
Date: Thu, 26 Oct 2000 15:34:03 -0400
Subject: [Python-Dev] What to choose to replace Tkinter?
References: <14837.14407.954185.466011@buffalo.fnal.gov> <ECEPKNMJLHAPFFJHDOJBKEKIDOAA.MarkH@ActiveState.com> <14837.43273.24692.93965@buffalo.fnal.gov> <20001024114326.E13957@kronos.cnri.reston.va.us>              <39F6B8B8.E3242929@interet.com> <200010251225.HAA22242@cj20424-a.reston1.va.home.com> <39F839BF.DD1B86BF@interet.com> <002a01c03f5f$71ca72f0$3c6340d5@hagrid>
Message-ID: <39F8872B.92D69403@interet.com>

Fredrik Lundh wrote:
> 
> jim wrote:
> > Sorry to be such an old fuddy-duddy, but you will
> > get the same reaction from most commercial software
> > vendors.  Make that nearly ALL vendors.
> 
> what reaction?
> 
> are you saying that your own installer can install the
> Python DLL but not the Tk DLL?

Not exactly.  I am saying I don't want to use the standard
Python Windows installer.  And I am saying I don't want to install
Tk because it is big, complicated, and requires Tcl and its libraries.

My installer does install the Python DLL python15.dll, so
I guess I could study how to install Tk and duplicate the
functionality of the Windows installer, and install Tk too.
But why would I want to?

JimA



From jim at interet.com  Thu Oct 26 21:38:40 2000
From: jim at interet.com (James C. Ahlstrom)
Date: Thu, 26 Oct 2000 15:38:40 -0400
Subject: [Python-Dev] What to choose to replace Tkinter?
References: <Pine.LNX.4.10.10010241146450.6622-100000@akbar.nevex.com> <200010241739.MAA16414@cj20424-a.reston1.va.home.com> <39F6BA29.3CAB4C0E@interet.com> <200010251227.HAA22256@cj20424-a.reston1.va.home.com> <39F83A4A.26E543A3@interet.com> <20001026101850.A14742@ludwig.cnri.reston.va.us>
Message-ID: <39F88840.3F619707@interet.com>

Greg Ward wrote:

> This is generally considered Bad Form by usability types.  I think it
> boils down to this: the computer is not the real world, and trying to
> emulate the real world on the computer is cutesy but a dead end.

I agree up to a point, and my own app doesn't use doors.

But kids like this kind of design, have no trouble
understanding it, and people wouldn't write this if
they didn't think it would sell.

I just meant that people have a larger tolerance for
non-Microsoft GUI design ideas than I thought up to now.

JimA



From skip at mojam.com  Thu Oct 26 22:10:33 2000
From: skip at mojam.com (Skip Montanaro)
Date: Thu, 26 Oct 2000 15:10:33 -0500 (CDT)
Subject: [Python-Dev] A possible bit for a README or FAQ?
Message-ID: <14840.36793.19348.903534@beluga.mojam.com>

Just came across this error while running configure:

    checking for gcc... gcc
    checking whether the C compiler (gcc   ) works... no
    configure: error: installation or configuration problem: C compiler cannot create executables.

The problem was that /tmp was full - sort of.  The system says there's no
space: 

    % cat /etc/termcap > /tmp/termcap
    bash: /tmp/termcap: No space left on device

but df disagrees:

    % df /tmp
    Filesystem           1k-blocks      Used Available Use% Mounted on
    /dev/hda5               153667     88796     56935  61% /

Short term workaround is to run configure with TMPDIR set somewhere else.
Perhaps this is something to put in a gcc-specific or Unix-specific section
of the README file.  I didn't see anything, and the message emitted by
configure gave no hint at the cause of the problem.  I realized what it was
because I've been scratching my head about this problem for a couple weeks.

If this is deemed useful I'll modify README and check it in.  If not, no big
deal.

(I have no idea why the system thinks /tmp is full... sigh ...)

Skip



From cgw at fnal.gov  Thu Oct 26 22:14:53 2000
From: cgw at fnal.gov (Charles G Waldman)
Date: Thu, 26 Oct 2000 15:14:53 -0500 (CDT)
Subject: [Python-Dev] A possible bit for a README or FAQ?
In-Reply-To: <14840.36793.19348.903534@beluga.mojam.com>
References: <14840.36793.19348.903534@beluga.mojam.com>
Message-ID: <14840.37053.829696.379140@buffalo.fnal.gov>

Skip Montanaro writes:
 > 
 > Just came across this error while running configure:
 > 
 >     checking for gcc... gcc
 >     checking whether the C compiler (gcc   ) works... no
 >     configure: error: installation or configuration problem: C compiler cannot create executables.

 > If this is deemed useful I'll modify README and check it in.  If not, no big
 > deal.

Personally,  I don't think this is useful.  I don't think the Python
README is the place to list everything that can go wrong during
./configure.

The generic advice is "If something goes wrong during ./configure, 
read through config.log to see what went wrong"

I'm curious what is in your config.log when this error occurs!



From nas at arctrix.com  Thu Oct 26 15:29:49 2000
From: nas at arctrix.com (Neil Schemenauer)
Date: Thu, 26 Oct 2000 06:29:49 -0700
Subject: [Python-Dev] A possible bit for a README or FAQ?
In-Reply-To: <14840.36793.19348.903534@beluga.mojam.com>; from skip@mojam.com on Thu, Oct 26, 2000 at 03:10:33PM -0500
References: <14840.36793.19348.903534@beluga.mojam.com>
Message-ID: <20001026062949.A14618@glacier.fnational.com>

> The problem was that /tmp was full - sort of.

You might try "df -i".  You could be out inodes but still have
blocks.

  Neil



From guido at python.org  Thu Oct 26 23:29:33 2000
From: guido at python.org (Guido van Rossum)
Date: Thu, 26 Oct 2000 16:29:33 -0500
Subject: [Python-Dev] Gradual migration PEP
In-Reply-To: Your message of "Thu, 26 Oct 2000 07:28:12 MST."
             <39F83F7C.2241158F@prescod.net> 
References: <39F83F7C.2241158F@prescod.net> 
Message-ID: <200010262129.QAA14206@cj20424-a.reston1.va.home.com>

Paul,

Your deprecation PEP looks good.  A few comments:

- I think that the one-year period may depend on the feature.  Some
may require an even longer time.  Others less.

- I think there will be cases where run-time checks are the only way
to detect use of the old feature (e.g. I'm still struggling with how
to change the division semantics).

But this shouldn't stop it from becoming a PEP.

Please arrange for a PEP number with Barry, the PEPmaster.

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



From thomas at xs4all.net  Fri Oct 27 00:58:41 2000
From: thomas at xs4all.net (Thomas Wouters)
Date: Fri, 27 Oct 2000 00:58:41 +0200
Subject: [Python-Dev] A possible bit for a README or FAQ?
In-Reply-To: <20001026062949.A14618@glacier.fnational.com>; from nas@arctrix.com on Thu, Oct 26, 2000 at 06:29:49AM -0700
References: <14840.36793.19348.903534@beluga.mojam.com> <20001026062949.A14618@glacier.fnational.com>
Message-ID: <20001027005841.R12812@xs4all.nl>

On Thu, Oct 26, 2000 at 06:29:49AM -0700, Neil Schemenauer wrote:
> > The problem was that /tmp was full - sort of.

> You might try "df -i".  You could be out inodes but still have
> blocks.

Or failing that, it could be out of 'indirect' or 'doubly-indirect' blocks,
or some other filesystem resource. Not often the case for something like
/tmp, but definately possible on some filesystems.

-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!



From thomas at xs4all.net  Fri Oct 27 01:02:24 2000
From: thomas at xs4all.net (Thomas Wouters)
Date: Fri, 27 Oct 2000 01:02:24 +0200
Subject: [Python-Dev] A possible bit for a README or FAQ?
In-Reply-To: <14840.36793.19348.903534@beluga.mojam.com>; from skip@mojam.com on Thu, Oct 26, 2000 at 03:10:33PM -0500
References: <14840.36793.19348.903534@beluga.mojam.com>
Message-ID: <20001027010224.S12812@xs4all.nl>

On Thu, Oct 26, 2000 at 03:10:33PM -0500, Skip Montanaro wrote:

> Short term workaround is to run configure with TMPDIR set somewhere else.
> Perhaps this is something to put in a gcc-specific or Unix-specific section
> of the README file.  I didn't see anything, and the message emitted by
> configure gave no hint at the cause of the problem.  I realized what it was
> because I've been scratching my head about this problem for a couple weeks.

> If this is deemed useful I'll modify README and check it in.  If not, no big
> deal.

If you start adding things like that, also consider all the other
possibilities of configure being wrong. I hinted at one of them a couple of
weeks back, I think. (Somehow, 'last saturday', when I headed for London for
the Apachecon, feels like about two months ago :P) It's perfectly possible
for configure to be able to run gcc, gcc to be able to create working
binaries, but every check for a function or datatype failing because the
more 'involved' include files are missing. This is easy to do on Linux,
(removing /usr/src/linux, for instance) but not impossible on other systems
either.

-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!



From greg at cosc.canterbury.ac.nz  Fri Oct 27 02:21:26 2000
From: greg at cosc.canterbury.ac.nz (Greg Ewing)
Date: Fri, 27 Oct 2000 13:21:26 +1300 (NZDT)
Subject: [Python-Dev] A possible bit for a README or FAQ?
In-Reply-To: <20001027005841.R12812@xs4all.nl>
Message-ID: <200010270021.NAA28528@s454.cosc.canterbury.ac.nz>

Thomas Wouters <thomas at xs4all.net>:

> Or failing that, it could be out of 'indirect' or 'doubly-indirect'
> blocks,

I think they're allocated from the same pool as data blocks.

What *can* happen is that you can run out of "large" blocks.  The
BSD-style filesystem stores files bigger than 8k in blocks made up of
8 contiguous 1k blocks. If the filesystem is nearly full, or contains
a large number of small files, you can find that it's impossible to
create any more files > 8k, even though there appears to be plenty of
free space, because the space is too fragmented.

I don't think that's what's happening here, though, since I've
only ever seen it happen when the filesystem was about 99% full.

Greg Ewing, Computer Science Dept, +--------------------------------------+
University of Canterbury,	   | A citizen of NewZealandCorp, a	  |
Christchurch, New Zealand	   | wholly-owned subsidiary of USA Inc.  |
greg at cosc.canterbury.ac.nz	   +--------------------------------------+



From tim_one at email.msn.com  Fri Oct 27 03:13:02 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Thu, 26 Oct 2000 21:13:02 -0400
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: <39F8872B.92D69403@interet.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCEECGHNAA.tim_one@email.msn.com>

[Guido]
> are you saying that your own installer can install the
> Python DLL but not the Tk DLL?

[James Ahlstrom]
> Not exactly.  I am saying I don't want to use the standard
> Python Windows installer.  And I am saying I don't want to install
> Tk because it is big, complicated, and requires Tcl and its libraries.
>
> My installer does install the Python DLL python15.dll, so
> I guess I could study how to install Tk and duplicate the
> functionality of the Windows installer, and install Tk too.
> But why would I want to?

That's up to you and your customers.  What Guido has been telling you is
that what the Windows installer does now (as of 1.6) to "install" Tcl/Tk is
trivial:  it merely copies some Tcl/Tk files into the Python installation
tree.  It no longer runs the Scriptics installer, mucks with the path,
changes any envars, copies any files to outside of the Python tree, or even
sets anything up in the registry for Tcl/Tk.  You may not *want* to install
Tcl/Tk, but, if you would like to, there's no longer any basis for fearing
it's difficult, obscure, delicate or error-prone.

don't-know-about-those-wrt-other-gui-pkgs-ly y'rs  - tim





From skip at mojam.com  Fri Oct 27 05:54:51 2000
From: skip at mojam.com (Skip Montanaro)
Date: Thu, 26 Oct 2000 22:54:51 -0500 (CDT)
Subject: [Python-Dev] A possible bit for a README or FAQ?
In-Reply-To: <14840.37053.829696.379140@buffalo.fnal.gov>
References: <14840.36793.19348.903534@beluga.mojam.com>
	<14840.37053.829696.379140@buffalo.fnal.gov>
Message-ID: <14840.64651.444849.757658@beluga.mojam.com>

    Charles> The generic advice is "If something goes wrong during
    Charles> ./configure, read through config.log to see what went wrong"

Agreed.

    Charles> I'm curious what is in your config.log when this error occurs!

That's why I was thinking ("hmmm... perhaps a README bit").  It wasn't
giving me obvious "no space" messages.

I've concluded that it's probably best to forget it anyway.  If it's a
problem with configure or gcc messages, it's best addressed there.

Skip




From skip at mojam.com  Fri Oct 27 05:57:00 2000
From: skip at mojam.com (Skip Montanaro)
Date: Thu, 26 Oct 2000 22:57:00 -0500 (CDT)
Subject: [Python-Dev] A possible bit for a README or FAQ?
In-Reply-To: <20001026062949.A14618@glacier.fnational.com>
References: <14840.36793.19348.903534@beluga.mojam.com>
	<20001026062949.A14618@glacier.fnational.com>
Message-ID: <14840.64780.673428.672300@beluga.mojam.com>

    Neil> You might try "df -i".  You could be out inodes but still have
    Neil> blocks.

Thanks, that indeed seems to be the problem:

    % df -i /tmp
    Filesystem            Inodes   IUsed   IFree IUse% Mounted on
    /dev/hda5                39k     39k       7  100% /

I don't believe in all my years of fiddling with Unix systems I've ever run
out of inodes with a third of the disk space left.  Now to identify the
culprit.

Skip




From mal at lemburg.com  Fri Oct 27 12:15:53 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Fri, 27 Oct 2000 12:15:53 +0200
Subject: [Python-Dev] Starship is still down...
Message-ID: <39F955D9.279864FD@lemburg.com>

It's been over a week since I posted my last gripe about
our community server starship being unreachable. Nothing has
happened so far... is there any chance on getting the server
up and running again ?

I am a bit concerned about the lack of support here: starship
should be considered a very important part in the Python
universe (after all, many Python extension packages and goodies
are available from that site). With the frequent downtimes
we recently had, I think people will get a wrong picture about
the Python community support.

Here's a traceroute from Germany to starship:
traceroute to starship.python.net (208.185.174.112), 30 hops max, 40 byte packets
 1  193.158.137.129 (193.158.137.129)  24 ms  23 ms  23 ms
 2  193.158.137.130 (193.158.137.130)  24 ms  35 ms  25 ms
 3  D-gw13.D.net.DTAG.DE (212.185.10.22)  67 ms  24 ms  35 ms
 4  K-gw13.K.net.DTAG.DE (194.25.124.137)  26 ms  25 ms  25 ms
 5  F-gw13.F.net.DTAG.DE (194.25.121.101)  32 ms  33 ms  33 ms
 6  TysonsC-gw12.USA.net.DTAG.DE (194.25.6.98)  113 ms  127 ms  131 ms
 7  TysonsC-gw1.USA.net.DTAG.DE (194.25.6.113)  115 ms  117 ms  134 ms
 8  mae-east-switch0.maee.above.net (208.184.210.9)  134 ms  114 ms  123 ms
 9  core1-mae-east-oc3-1.iad.above.net (209.133.31.225)  122 ms  116 ms  115 ms
10  sjc2-iad-oc48.sjc2.above.net (216.200.127.26)  184 ms  186 ms  185 ms
11  core5-core3-oc48.sjc2.above.net (208.185.156.66)  183 ms  184 ms  186 ms
12  sjc2-gige-main1.colo6.sjc2.above.net (208.185.156.37)  299 ms  183 ms !H  188 ms !H
13  * * *
14  * * *
...

It looks as if ABOVE.NET is having some serious routing problems.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From tim_one at email.msn.com  Fri Oct 27 12:43:22 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Fri, 27 Oct 2000 06:43:22 -0400
Subject: [Python-Dev] Starship is still down...
In-Reply-To: <39F955D9.279864FD@lemburg.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCAEDHHNAA.tim_one@email.msn.com>

[MAL]
> It's been over a week since I posted my last gripe about
> our community server starship being unreachable.

Afraid Manus Head still gets the Most Outraged award for this one.

> Nothing has happened so far... is there any chance on getting the server
> up and running again ?

Works for me, but only very recently.  OTOH, my posts to python.org mailing
lists started black-holing, so it's not like Python-Dev will actually see
this post <wink>.  Here's a trace from my box (in Virginia); it may take a
while for recent routing changes to propagate:

  1   tnt32.tco2.da.uu.net [206.115.222.61]
  2   GigabitEthernet4-0.DR4.TCO2.Alter.Net [206.115.243.2]
  3   156.at-3-0-0.HR4.DCA1.ALTER.NET [152.63.34.50]
  4   517.ATM1-0.XR2.DCA1.ALTER.NET [152.63.36.198]
  5   294.at-7-1-0.XR2.DCA8.ALTER.NET [146.188.163.26]
  6   POS7-0.BR4.DCA8.ALTER.NET [152.63.36.25]
  7   137.39.52.102
  8   beth1br2-ge-1-0-0-0.md.us.prserv.net [165.87.29.139]
  9   sfra1br1-so-2-1-0-0.ca.us.prserv.net [165.87.233.42]
 10   sfra1sr3-ge-0-3-0-0.ca.us.prserv.net [165.87.33.139]
 11   pacbellpsfoc3.ca.us.prserv.net [165.87.161.5]
 12   core3-g2-0.snfc21.pbi.net [209.232.130.78]
 13   rback26-fe2-0.snfc21.pbi.net [216.102.187.153]
 14   adsl-63-202-160-65.dsl.snfc21.pacbell.net [63.202.160.65]
 15   starship.python.net [63.202.160.91]

> I am a bit concerned about the lack of support here: starship
> should be considered a very important part in the Python
> universe (after all, many Python extension packages and goodies
> are available from that site). With the frequent downtimes
> we recently had, I think people will get a wrong picture about
> the Python community support.

They're getting an accurate view of current Starship support.  So it goes.
Plans for better support *are* in progress, but for reasons that won't
become clear until later, you haven't heard anything about them yet.

for-that-matter-i'm-not-entirely-sure-i-have-either-ly y'rs  - tim





From jim at interet.com  Fri Oct 27 14:23:11 2000
From: jim at interet.com (James C. Ahlstrom)
Date: Fri, 27 Oct 2000 08:23:11 -0400
Subject: [Python-Dev] What to choose to replace Tkinter?
References: <LNBBLJKPBEHFEDALKOLCEECGHNAA.tim_one@email.msn.com>
Message-ID: <39F973AF.80D3BDBE@interet.com>

Tim Peters wrote:

> That's up to you and your customers.  What Guido has been telling you is
> that what the Windows installer does now (as of 1.6) to "install" Tcl/Tk is
> trivial:  it merely copies some Tcl/Tk files into the Python installation
> tree.  It no longer runs the Scriptics installer, mucks with the path,

Oh, OK.  That is much better.

JimA



From skip at mojam.com  Fri Oct 27 18:15:55 2000
From: skip at mojam.com (Skip Montanaro)
Date: Fri, 27 Oct 2000 11:15:55 -0500 (CDT)
Subject: [Python-Dev] Starship is still down...
In-Reply-To: <LNBBLJKPBEHFEDALKOLCAEDHHNAA.tim_one@email.msn.com>
References: <39F955D9.279864FD@lemburg.com>
	<LNBBLJKPBEHFEDALKOLCAEDHHNAA.tim_one@email.msn.com>
Message-ID: <14841.43579.261191.986406@beluga.mojam.com>

    Tim> Here's a trace from my box (in Virginia); ...

Tim's trace doesn't show times.  Looks to me like Pacbell is having trouble
(note the huge leap in response time):

    ...
    13  beth1sr3-so-5-1-3-0.md.us.prserv.net (165.87.99.50)  30.387 ms  27.426 ms  28.392 ms
    14  beth1br2-ge-1-0-0-0.md.us.prserv.net (165.87.29.139)  27.614 ms  27.349 ms  27.250 ms
    15  sfra1br1-so-2-1-0-0.ca.us.prserv.net (165.87.233.42)  71.581 ms  72.535 ms  72.429 ms
    16  sfra1sr3-ge-0-3-0-0.ca.us.prserv.net (165.87.33.139)  71.635 ms  71.420 ms  71.483 ms
    17  pacbellpsfoc3.ca.us.prserv.net (165.87.161.5)  71.070 ms  71.606 ms  71.301 ms
    18  core4-g2-0.snfc21.pbi.net (209.232.130.77)  70.986 ms  71.129 ms  73.628 ms
    19  rback26-fe2-0.snfc21.pbi.net (216.102.187.153)  72.696 ms  77.658 ms  83.046 ms
    20  adsl-63-202-160-65.dsl.snfc21.pacbell.net (63.202.160.65)  3841.343 ms  3705.648 ms  3911.584 ms
    21  adsl-63-202-160-91.dsl.snfc21.pacbell.net (63.202.160.91)  3683.340 ms  3867.550 ms  3653.732 ms

Skip



From petrilli at amber.org  Fri Oct 27 22:15:18 2000
From: petrilli at amber.org (Christopher Petrilli)
Date: Fri, 27 Oct 2000 16:15:18 -0400
Subject: GUI-Discussion; MacOS vs. MacOS X (was Re: [Python-Dev] Miscellaneous comments on Tkinter and related...)
In-Reply-To: <m13oTwr-000Dm8C@artcom0.artcom-gmbh.de>; from pf@artcom-gmbh.de on Wed, Oct 25, 2000 at 07:02:45PM +0200
References: <14838.64730.225260.148853@buffalo.fnal.gov> <m13oTwr-000Dm8C@artcom0.artcom-gmbh.de>
Message-ID: <20001027161518.B3942@trump.amber.org>

Peter Funk [pf at artcom-gmbh.de] wrote:
> 
> It will take years, before MacOS X will find its way onto the desk
> of the average Apple Mac user.  The Mac s mostly used in the graphics 
> and printing industry (our cutsomers) where people normally don't 
> even think about a OS upgrade, if they don't have to.  They usually
> run a mix of Photoshop, Quark XPRess, Artwork, illustrator or other 
> so called creative software on the version of the OS they had on 
> the machine when they bought it.  THese machines are usually used
> through a period of at least four years.

I think this is a bit incorrect.  Almost every Mac user that I
interact with (including all the users hre at Digital Creations) have
OS X running and using it at various levels.  Mostly it's waiting for
people like Adobe to release Carbon applications.  

Graphics designers will be the first to move to OS X, not thel ast, as 
they will ge the most fromt he increased stability and performance. It 
all depends on your market.

The best goal for Mac OS would be to aim at full Carbon compliance,
and not write to Cocoa, or to the original MacOS toolkit.  This would
let you run on all releases after 8.0 I believe (maybe even 7.6).

Chris
-- 
| Christopher Petrilli
| petrilli at amber.org



From guido at python.org  Sat Oct 28 03:42:42 2000
From: guido at python.org (Guido van Rossum)
Date: Fri, 27 Oct 2000 20:42:42 -0500
Subject: [Python-Dev] PythonLabs Team Moves to Digital Creations
Message-ID: <200010280142.UAA05020@cj20424-a.reston1.va.home.com>

To all Python users and developers:

Less than half a year ago, I moved with my team to BeOpen.com, in the
hope of finding a new permanent home for Python development.  At
BeOpen, we've done several good things for Python, such as moving the
Python and Jython development process to SourceForge, and the
successful release of Python 2.0.

Unfortunately, BeOpen.com's original plans for PythonLabs didn't work
out as hoped, and we weren't able to reach mutual agreement on
workable alternative plans -- despite trying for months.

I am proud to have found a new home for my entire team: starting
today, Tim Peters, Barry Warsaw, Jeremy Hylton, Fred Drake and myself
are working for Digital Creations.  We will be spending part of our
time on core Python development (including Jython and Mailman) and
part of our time on Python infrastructure improvements that also
benefit Zope.

Python will remain Open Source; Digital Creations has no desire to
monetize or brand the Python language or specific Python
distributions.  All future work we do on Python as Digital Creations
employees will be owned by a non-profit organization yet to be
created.  We think of this new organization as the Python Software
Foundation.  In the meantime (while the PSF is under construction) I
will own such copyrights personally.

We're excited to be working for Digital Creations: they are one of the
oldest companies active in the Python community, one of the companies
most committed to Python, and they have a great product!  Plus, we
know they have deep financial backing.  We trust that Digital
Creations will provide a stable home for Python for many years.

Digital Creations has also offered to take over hosting of the
python.org and starship sites.  On behalf of the Python community,
we're grateful for this support of the two prime community sites for
Python, and we expect to be implementing the transitions shortly.

These are exciting times for the PythonLabs team -- and also for
Python and its community.  Mainstream successes for Python are showing
up everywhere, and we're proud to be a part of such a smart and
friendly community.  A great year lies ahead!

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



From jim at digicool.com  Sat Oct 28 04:45:02 2000
From: jim at digicool.com (Jim Fulton)
Date: Fri, 27 Oct 2000 22:45:02 -0400
Subject: [Python-Dev] Re: PythonLabs Team Moves to Digital Creations
References: <mailman.972693760.7272.python-list@python.org>
Message-ID: <39FA3DAE.ADB2C8B1@digicool.com>

Guido van Rossum wrote:
> 
(snip)
> I am proud to have found a new home for my entire team: starting
> today, Tim Peters, Barry Warsaw, Jeremy Hylton, Fred Drake and myself
> are working for Digital Creations.  We will be spending part of our
> time on core Python development (including Jython and Mailman) and
> part of our time on Python infrastructure improvements that also
> benefit Zope.

Needless to say (but I'll say it anyway), Digital Creations is
proud and thrilled that the this team has joined us. 

These are indeed exciting times! 

Jim

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



From martin at loewis.home.cs.tu-berlin.de  Sat Oct 28 12:14:00 2000
From: martin at loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Sat, 28 Oct 2000 12:14:00 +0200
Subject: [Python-Dev] getting at the current frame
Message-ID: <200010281014.MAA01045@loewis.home.cs.tu-berlin.de>

> which actually will look something like this in real code:
>
>    def trade(yours, mine):
>        print _('if you give me %(yours)s, i will give you %(mine)s') % {
>            'yours': yours,
>            'mine' : mine,
>            }
>
> The string wrapped in _() is what gets translated here.
>
> Okay, we all know that's a pain, right?

What's wrong with

    def trade(yours, mine):
        print _('if you give me %(yours)s, i will give you %(mine)s') % vars()

Look Ma, no magic!

Regards,
Martin



From effbot at telia.com  Sat Oct 28 12:43:05 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Sat, 28 Oct 2000 12:43:05 +0200
Subject: [Python-Dev] Re: [Python-checkins] SourceForge problems
References: <14839.26627.968974.44752@cj42289-a.reston1.va.home.com>
Message-ID: <012e01c040cb$dc501b30$3c6340d5@hagrid>

fred wrote:
>   At any rate, there has been activity in the source tree; you just
> might want to do a CVS update to see what's changed.  There have been
> a number of bug fixes, a fair number of documentation updates, and
> many of the modules in the standard library have been passed through
> Tim Peter's reindent.py script (look in Tools/scripts/).

now that this has been done, emacs users might want to
add something like the following to their local configuration
(based on code by jwz, so it should work...)

:::

(defun python-mode-untabify ()
  (save-excursion
    (goto-char (point-min))
    (while (re-search-forward "[ \t]+$" nil t)
      (delete-region (match-beginning 0) (match-end 0)))
    (goto-char (point-min))
    (if (search-forward "\t" nil t)
        (untabify (1- (point)) (point-max))))
  nil)
 (add-hook 'python-mode-hook 
          '(lambda ()
             (make-local-variable 'write-contents-hooks)
             (add-hook 'write-contents-hooks 'python-mode-untabify)))

</F>




From martin at loewis.home.cs.tu-berlin.de  Sat Oct 28 12:51:20 2000
From: martin at loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Sat, 28 Oct 2000 12:51:20 +0200
Subject: [Python-Dev] build problems under Solaris
Message-ID: <200010281051.MAA01290@loewis.home.cs.tu-berlin.de>

> I don't have access to a Solaris machine, so I can't do anything to
> help these users.

The patch in 117606 looks right to me: gcc on Solaris (and on any
other platform) needs -shared to build shared library; configure
currently passes -G. I haven't actually tried the patch, since it is a
pain to extract it from the SF bug report page. What happens is that
gcc passes -G to the linker, which correctly produces a shared
library.  However, gcc also links crt1/crti into the library, which
causes the reference to main.

117508 looks like a user error to me. On its own, configure would not
try to link -ldb, unless it detects the presence of db.h. My guess is
that there is a libdb in /usr/local, so a gcc configure finds it,
whereas the native compiler doesn't. Later, the linker even finds a
-ldb library, but somehow this doesn't have dbopen. So it could be
that the BSDDB installation on that system is screwed.

Regards,
Martin




From barry at scottb.demon.co.uk  Sat Oct 28 13:14:45 2000
From: barry at scottb.demon.co.uk (Barry Scott)
Date: Sat, 28 Oct 2000 12:14:45 +0100
Subject: [Python-Dev] Gradual migration
In-Reply-To: <39F82C97.12D04C85@lemburg.com>
Message-ID: <000601c040d0$474ce1d0$060210ac@private>

> > We could make integrating C++ and Python easier through CXX or Py_Cpp.
> > Perhaps we should ship one of those with Python 2.1. Anyhow, integrating
> > C++ and Python is not really so hard, in my experience.

	Integrating C++ and Python well is hard in a general library.

	CXX tries to make objects that look and feel like Python objects.
	But to do that we have to figure out the details of how python uses
	objects. You have no docs on the subject so we read the source code.

		Barry
		CXX maintainer




From barry at scottb.demon.co.uk  Sat Oct 28 13:23:50 2000
From: barry at scottb.demon.co.uk (Barry Scott)
Date: Sat, 28 Oct 2000 12:23:50 +0100
Subject: [Python-Dev] Gradual migration
In-Reply-To: <39F80C30.5448.52D32F94@localhost>
Message-ID: <000701c040d1$8beecf00$060210ac@private>

[Gordon wrote]
> All of the existing C++ interfaces / helpers deal only with type 
> objects (at least, those that I've examined, which is most of 
> them). In fact, only ExtensionClass attempts to deal with the 
> class / type split, and while it's a masterpiece, I think it's a 
> great example of everything to avoid in Py3K.

	Py_Cpp support C++ classes you can derived from in Python.
	Once I get my head around the proxy interface I'll try and
	add that to CXX. CXX today allows you to create C++ class
	that you can use from Python, but not derive from.

		Barry
		CXX maintainer





From moshez at math.huji.ac.il  Sun Oct 29 08:59:11 2000
From: moshez at math.huji.ac.il (Moshe Zadka)
Date: Sun, 29 Oct 2000 09:59:11 +0200 (IST)
Subject: [Python-Dev] development version of docs online
In-Reply-To: <14840.27182.548970.193402@cj42289-a.reston1.va.home.com>
Message-ID: <Pine.GSO.4.10.10010290956420.7911-100000@sundial>

On Thu, 26 Oct 2000, Fred L. Drake, Jr. wrote:

>   Do people want to be notified when the development copy of the
> documentation is update?  There was a comment from someone that they
> didn't know where the online copy was.  I can send the update notice
> to python-dev instead of just to myself if everyone wants it, or I can
> send it to some other (appropriate) list.

I'm for Python-Dev + doc-sig (I'm shooting myself in the foot, cause that
means I'm getting it twice. My foot is used to being shot at though)
--
Moshe Zadka <moshez at math.huji.ac.il> -- 95855124
http://advogato.org/person/moshez




From barry at wooz.org  Mon Oct 30 17:14:53 2000
From: barry at wooz.org (barry at wooz.org)
Date: Mon, 30 Oct 2000 11:14:53 -0500 (EST)
Subject: [Python-Dev] Re: getting at the current frame
References: <200010281014.MAA01045@loewis.home.cs.tu-berlin.de>
Message-ID: <14845.40573.917058.905009@anthem.concentric.net>

>>>>> "MvL" == Martin v Loewis <martin at loewis.home.cs.tu-berlin.de> writes:

    MvL> What's wrong with

    MvL>     def trade(yours, mine): print _('if you give me
    MvL> %(yours)s, i will give you %(mine)s') % vars()

    MvL> Look Ma, no magic!

Except that I also want globals() to be included and vars() doesn't
include that.  I really want:

    d = globals().copy()
    d.update(locals())

but I've also noticed that you sometimes want attribute following so
you can do things like

    _('the name of the list is %(mlist.listname)')

-Barry



From barry at wooz.org  Mon Oct 30 18:35:25 2000
From: barry at wooz.org (Barry A. Warsaw)
Date: Mon, 30 Oct 2000 12:35:25 -0500 (EST)
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Python ceval.c,2.212,2.213
References: <200010301715.JAA32564@slayer.i.sourceforge.net>
Message-ID: <14845.45405.867829.722598@anthem.concentric.net>

Well, it looks like checkin messages are flowing again.  Yay!



From mal at lemburg.com  Mon Oct 30 18:54:50 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Mon, 30 Oct 2000 18:54:50 +0100
Subject: [Python-Dev] Re: Python Call Mechanism ([Python-checkins] CVS: python/dist/src/Python
 ceval.c,2.212,2.213)
References: <200010301715.JAA32564@slayer.i.sourceforge.net>
Message-ID: <39FDB5EA.B60EA39A@lemburg.com>

Jeremy Hylton wrote:
> 
> Update of /cvsroot/python/python/dist/src/Python
> In directory slayer.i.sourceforge.net:/tmp/cvs-serv32349/Python
> 
> Modified Files:
>         ceval.c
> ...
> N.B. The CALL_FUNCTION implementation is getting really hairy; should
> review it to see if it can be simplified.

How about a complete redesign of the whole call mechanism ?!

I have an old patch somewhere which reorganizes the Python
calling mechanism into something more sane than what we
have in ceval.c now.

Should I try to find it for someone to use as basis for the
reorg (don't have time for this myself) ?

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From jeremy at alum.mit.edu  Mon Oct 30 15:59:00 2000
From: jeremy at alum.mit.edu (Jeremy Hylton)
Date: Mon, 30 Oct 2000 09:59:00 -0500 (EST)
Subject: [Python-Dev] Re: Python Call Mechanism ([Python-checkins] CVS: python/dist/src/Python
 ceval.c,2.212,2.213)
In-Reply-To: <39FDB5EA.B60EA39A@lemburg.com>
References: <200010301715.JAA32564@slayer.i.sourceforge.net>
	<39FDB5EA.B60EA39A@lemburg.com>
Message-ID: <14845.36020.17063.951147@bitdiddle.concentric.net>

>>>>> "MAL" == M -A Lemburg <mal at lemburg.com> writes:

  MAL> Jeremy Hylton wrote:
  >>
  >> Update of /cvsroot/python/python/dist/src/Python In directory
  >> slayer.i.sourceforge.net:/tmp/cvs-serv32349/Python
  >>
  >> Modified Files: ceval.c ...  N.B. The CALL_FUNCTION
  >> implementation is getting really hairy; should review it to see
  >> if it can be simplified.

  MAL> How about a complete redesign of the whole call mechanism ?!

  MAL> I have an old patch somewhere which reorganizes the Python
  MAL> calling mechanism into something more sane than what we have in
  MAL> ceval.c now.

  MAL> Should I try to find it for someone to use as basis for the
  MAL> reorg (don't have time for this myself) ?

I'd be interested in looking at it.

Jeremy



From tim_one at email.msn.com  Mon Oct 30 20:36:55 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Mon, 30 Oct 2000 14:36:55 -0500
Subject: [Python-Dev] New test_extcall fails on Windows -- elsewhere?  Expected?  Bug?
Message-ID: <LNBBLJKPBEHFEDALKOLCIEKPHNAA.tim_one@email.msn.com>

C:\Code\python\dist\src\PCbuild>python ../lib/test/regrtest.py test_extcall

test_extcall
test test_extcall failed -- Writing: '3', expected: ''
1 test failed: test_extcall

C:\Code\python\dist\src\PCbuild>python ../lib/test/regrtest.py -v
test_extcall

test_extcall
test_extcall
() {}
(1,) {}
(1, 2) {}
(1, 2, 3) {}
(1, 2, 3, 4, 5) {}
(1, 2, 3, 4, 5) {}
(1, 2, 3, 4, 5) {}
(1, 2, 3) {'b': 5, 'a': 4}
(1, 2, 3, 4, 5) {'b': 7, 'a': 6}
(1, 2, 3, 6, 7) {'y': 5, 'b': 9, 'x': 4, 'a': 8}
TypeError: not enough arguments to g(); expected 1, got 0
TypeError: not enough arguments to g(); expected 1, got 0
TypeError: not enough arguments to g(); expected 1, got 0
1 () {}
1 (2,) {}
1 (2, 3) {}
1 (2, 3, 4, 5) {}
0 (1, 2) {}
1 () {'d': 4, 'b': 2, 'c': 3, 'a': 1}
{'b': 2, 'c': 3, 'a': 1}
{'b': 2, 'c': 3, 'a': 1}
keyword parameter 'x' redefined in call to g()
keyword parameter 'b' redefined in function call
keywords must be strings
h() got an unexpected keyword argument 'e'
* argument must be a sequence
** argument must be a dictionary
3 512 1
3
3
unbound method must be called with instance as first argument
unbound method must be called with instance as first argument
1 test OK.





From fdrake at acm.org  Mon Oct 30 21:38:09 2000
From: fdrake at acm.org (Fred L. Drake, Jr.)
Date: Mon, 30 Oct 2000 15:38:09 -0500 (EST)
Subject: [Python-Dev] New test_extcall fails on Windows -- elsewhere?  Expected?  Bug?
In-Reply-To: <LNBBLJKPBEHFEDALKOLCIEKPHNAA.tim_one@email.msn.com>
References: <LNBBLJKPBEHFEDALKOLCIEKPHNAA.tim_one@email.msn.com>
Message-ID: <14845.56369.361598.655506@cj42289-a.reston1.va.home.com>

Tim Peters writes:
 > C:\Code\python\dist\src\PCbuild>python ../lib/test/regrtest.py test_extcall
 > 
 > test_extcall
 > test test_extcall failed -- Writing: '3', expected: ''
 > 1 test failed: test_extcall

  I get the same thing on Linux.  The output appears identical to what
Tim got.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at acm.org>
PythonLabs at Digital Creations




From jeremy at alum.mit.edu  Mon Oct 30 17:48:08 2000
From: jeremy at alum.mit.edu (Jeremy Hylton)
Date: Mon, 30 Oct 2000 11:48:08 -0500 (EST)
Subject: [Python-Dev] New test_extcall fails on Windows -- elsewhere?  Expected?  Bug?
In-Reply-To: <LNBBLJKPBEHFEDALKOLCIEKPHNAA.tim_one@email.msn.com>
References: <LNBBLJKPBEHFEDALKOLCIEKPHNAA.tim_one@email.msn.com>
Message-ID: <14845.42568.358062.805095@bitdiddle.concentric.net>

This output matches the output file I just checked in under
Lib/test/output/test_extcall.  Looks like I failed to check in this
change.

Jeremy



From tim_one at email.msn.com  Mon Oct 30 20:54:14 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Mon, 30 Oct 2000 14:54:14 -0500
Subject: [Python-Dev] New test_extcall fails on Windows -- elsewhere?  Expected?  Bug?
In-Reply-To: <14845.42568.358062.805095@bitdiddle.concentric.net>
Message-ID: <LNBBLJKPBEHFEDALKOLCMELAHNAA.tim_one@email.msn.com>

[Jeremy]
> This output matches the output file I just checked in under
> Lib/test/output/test_extcall.  Looks like I failed to check in this
> change.

Thank you -- works on Windows now.  It should work on Linux too, if Linux
knows what's good for it <wink>.





From fdrake at acm.org  Mon Oct 30 21:56:13 2000
From: fdrake at acm.org (Fred L. Drake, Jr.)
Date: Mon, 30 Oct 2000 15:56:13 -0500 (EST)
Subject: [Python-Dev] New test_extcall fails on Windows -- elsewhere?  Expected?  Bug?
In-Reply-To: <LNBBLJKPBEHFEDALKOLCMELAHNAA.tim_one@email.msn.com>
References: <14845.42568.358062.805095@bitdiddle.concentric.net>
	<LNBBLJKPBEHFEDALKOLCMELAHNAA.tim_one@email.msn.com>
Message-ID: <14845.57453.54059.671795@cj42289-a.reston1.va.home.com>

Tim Peters writes:
 > Thank you -- works on Windows now.  It should work on Linux too, if Linux
 > knows what's good for it <wink>.

  It does.  ;)


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at acm.org>
PythonLabs at Digital Creations




From guido at python.org  Sun Oct  1 07:31:43 2000
From: guido at python.org (Guido van Rossum)
Date: Sun, 01 Oct 2000 00:31:43 -0500
Subject: [Python-Dev] Release candidate followed by feature freeze?
Message-ID: <200010010531.AAA15697@cj20424-a.reston1.va.home.com>

I'm considering to issue a release candidate before the final 2.0
release.  I'd like to poll opinions about this (we haven't had a
PythonLabs group meeting about this yet).

The importance of a release candidate (RC) is twofold: we announce it
widely so it (hopefully) gets a lot of testing -- necessary since a
lot of things have changed again since beta2; and we impose a checkin
stop once the RC is out, with exceptions only allowed by the release
manager to fix showstopper bugs found in the RC.

This will hopefully avoid a disaster like we had with the buggy
last-minute changes in beta2 (for which I take full responsibility).

If the idea of a RC sounds okay, I'd like to propose to release it on
October 5.  The final release would still be on October 10, or perhaps
1-2 days later.  Much less than a week between the RC and the final
release is not good because it doesn't give testers enough time to try
out the RC; much more than a week is bad because the developers get
antsy when they can't check in their changes!

This means that any current bug reports and patches that aren't in the
RC, WON'T BE FIXED in the final release!  Think about it.  This is a
good thing, so we won't be able to screw up the final release at the
last moment.

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



From thomas at xs4all.net  Sun Oct  1 14:06:48 2000
From: thomas at xs4all.net (Thomas Wouters)
Date: Sun, 1 Oct 2000 14:06:48 +0200
Subject: [Python-Dev] Changes in semantics to str()?
In-Reply-To: <200009302056.PAA14718@cj20424-a.reston1.va.home.com>; from guido@python.org on Sat, Sep 30, 2000 at 03:56:18PM -0500
References: <200009302056.PAA14718@cj20424-a.reston1.va.home.com>
Message-ID: <20001001140648.A12812@xs4all.nl>

On Sat, Sep 30, 2000 at 03:56:18PM -0500, Guido van Rossum wrote:

> Below I have included changes to listobject.c, tupleobject.c and
> dictobject.c that fix this.  The fixes change the print and str()
> callbacks for these objects to use PyObject_Str() on the contained
> items -- except if the item is a string or Unicode string.  I made
> these exceptions because I don't like the idea of str(["abc"])
> yielding [abc] -- I'm too used to the idea of seeing ['abc'] here.
> And str() of a Unicode object fails when it contains non-ASCII
> characters, so that's no good either -- it would break too much code.

Personally, I'm -0, or perhaps -1 (I'll make up my mind while going out for
some lunch/breakfast ;) I would be in favor if the str() output were only
used to display something to a user, but that's not the case. And too many
people are under the impression that the 'print' handler is the same as the
'str' handler to make that distinction now, I'm afraid. My main gripe with
this change is that it makes str() for container objects unreliable...
Strings are a special case, but class-instances are not -- so something like
UserString will be displayed without quotes. I don't like the idea of
sometimes doing 'str' and sometimes doing 'repr'.

I understand what it's trying to solve, but I don't think that's a worse
inconsistency than the one this change introduces. It's also easy to
explain: 'str(list or dict) is the same as repr(list or dict)'. The new
phrase would be something like 'str(list or dict) calls str() on the objects
it contains, except for string and unicode objects.'. And even that breaks
when you mix in instances that wrap a container. A list containing a
UserList containing a set of (unicode-)strings would display the strings
without quotes. And you can't see that the second container is a UserList.

I also don't think this change should be made between the final beta and
2.0. Jeremy, don't let him ruin your feature freeze! :-)

-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!



From jim at digicool.com  Sun Oct  1 16:32:27 2000
From: jim at digicool.com (Jim Fulton)
Date: Sun, 01 Oct 2000 10:32:27 -0400
Subject: [Python-Dev] select, signals, and "interrupted system call" (EINTR)
Message-ID: <39D74AFB.322E5187@digicool.com>

If a select-based (or, presumably, poll-based) server wants to
use signals for anything other than shutdown (e.g. closing and
reopening log files, rereading configs, etc.), then, on some 
platforms, a select call can fail with an "interrupted system
call" (EINTR) error that should be ignored.  The asyncore 
main loop should check for this error in it's select call
and the select module should make this error easier to check for.

In Python 1.5.2, the medusa select call can be changed from

        r,w,e = select.select (r,w,e, timeout)

to:

        while 1:
            try: r,w,e = select.select (r,w,e, timeout)
            except select.error, v:
                if v[0] != EINTR: raise
            else: break

I presume that this works in Python 1.6/2.0, but I
haven't tried it yet?

This depends on the structure of select.error values
and requires that we get EINTR from somewhere. (What
should the value be on NT?) 

I wonder if there should be an InterruptedSystemCall
exception somewhere that select raises in this case?

At a minimum, code like the above should be added to 
asyncore.

Thoughts?

Jim

--
Jim Fulton           mailto:jim at digicool.com
Technical Director   (888) 344-4332              Python Powered!
Digital Creations    http://www.digicool.com     http://www.python.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 rushing at nightmare.com  Sun Oct  1 21:07:59 2000
From: rushing at nightmare.com (Sam Rushing)
Date: Sun, 1 Oct 2000 12:07:59 -0700 (PDT)
Subject: [Python-Dev] [medusa] select, signals, and "interrupted system call" (EINTR)
In-Reply-To: <39D74AFB.322E5187@digicool.com>
References: <39D74AFB.322E5187@digicool.com>
Message-ID: <14807.35727.423642.721873@seattle.nightmare.com>

Jim Fulton writes:
 > The asyncore main loop should check for this error in it's select
 > call and the select module should make this error easier to check
 > for.

It might go better into the event_loop function, which I think of as a
more user-serviceable part.  [for example, the default loop vs. the
one in medusa/event_loop.py that supports schedulable events]

 > I presume that this works in Python 1.6/2.0, but I
 > haven't tried it yet?
 > 
 > This depends on the structure of select.error values
 > and requires that we get EINTR from somewhere. (What
 > should the value be on NT?) 

If it's a big problem, I guess we could use a different default
event_loop() function for win32 vs. unix.

 > At a minimum, code like the above should be added to asyncore.
 > 
 > Thoughts?

This has been asked for several times, I agree it'd be nice to have at
least a note in the docs..

-Sam




From loewis at informatik.hu-berlin.de  Sun Oct  1 21:13:41 2000
From: loewis at informatik.hu-berlin.de (Martin von Loewis)
Date: Sun, 1 Oct 2000 21:13:41 +0200 (MET DST)
Subject: [Python-Dev] Release candidate followed by feature freeze?
Message-ID: <200010011913.VAA01107@pandora.informatik.hu-berlin.de>

> I'd like to poll opinions about this (we haven't had a PythonLabs
> group meeting about this yet).

YES! I was hoping somebody would propose such a thing; I was quite
concerned that check-in procedures are still that liberate.

To report how similar projects operate: In gcc, a CVS release branch
is created at some point in time (usually months before the
release). When the code is declared frozen, all changes to the release
branch have to go through the release manager. After the release,
"important" changes to the mainline branch are manually propagated to
the release branch for subminor releases.

Regards,
Martin



From dkwolfe at pacbell.net  Sun Oct  1 23:23:03 2000
From: dkwolfe at pacbell.net (Dan Wolfe)
Date: Sun, 01 Oct 2000 14:23:03 -0700
Subject: [Python-Dev] FW: regarding the Python Developer posting...
Message-ID: <0G1R0061USP9TT@mta5.snfc21.pbi.net>

>> [commented out code that was causing seg fault in test_sre.py]

>you could try adding a Mac OS clause to the recursion limit stuff
>in Modules/_sre.c:
>
>#if !defined(USE_STACKCHECK)
>#if defined(...whatever's needed to detect Max OS X...)
[....]
>
>replace "...whatever...", and try larger values than 5000 (or smaller,
>if necessary.  10000 is clearly too large for your platform).
>
>(alternatively, you can increase the stack size.  maybe it's very small
>by default?)

the stack size is quite small by default - 512K.  After some testing I 
was able to figure out that it fails around 440 recursions... probably a 
bit too small in comparison to the other *nixes.... but then I'll defer 
to the experts in sre.

I was reading the August developer archives on the getrlimit and since 
that seem to be available, it's probably the right way to implement the 
stack check on Mac OS X.

Sure I can increase the default stack size - just a simple limit -h 
before running it in the shell... I let it run until about 7K 
recursions... even then it was only about 11MB and bumping the stack up 
by 30K or so per recursion... and I still had nearly 100MB free... and 
places to go. :-)

I'm going to write a bug report against Mac OS X and we'll see what 
happens.  In the meantime, you can hard code it to 440 and it will pass 
the test...  I've placed a patch on sourceforge that give the initial 
support for detecting Mac OS X as part of the make file but I still have 
to figure out how/where you defined MS_WIN64.... 

- Dan 




From barry at scottb.demon.co.uk  Mon Oct  2 00:19:21 2000
From: barry at scottb.demon.co.uk (Barry Scott)
Date: Sun, 1 Oct 2000 23:19:21 +0100
Subject: [Python-Dev] Patch to avoid conflict with older versions of Python.
In-Reply-To: <ECEPKNMJLHAPFFJHDOJBEEIHDLAA.MarkH@ActiveState.com>
Message-ID: <000b01c02bf5$a5edf070$060210ac@private>

I still think that Python needs to fix the problem with the API between
the core and the extensions. That way all the version checking would work
for Windows and Unix.

But since that approach has been rejected I'd take any change to python
that reduces support calls.

		BArry


> -----Original Message-----
> From: python-dev-admin at python.org [mailto:python-dev-admin at python.org]On
> Behalf Of Mark Hammond
> Sent: 29 September 2000 02:36
> To: python-dev at python.org
> Subject: [Python-Dev] Patch to avoid conflict with older versions of
> Python.
> 
> 
> Hi all,
> 	I'd like some feedback on a patch assigned to me.  It is designed to
> prevent Python extensions built for an earlier version of Python from
> crashing the new version.
> 
> I haven't actually tested the patch, but I am sure it works as advertised
> (who is db31 anyway?).
> 
> My question relates more to the "style" - the patch locates the new .pyd's
> address in memory, and parses through the MS PE/COFF format, locating the
> import table.  If then scans the import table looking for Pythonxx.dll, and
> compares any found entries with the current version.
> 
> Quite clever - a definite plus is that is should work for all old and
> future versions (of Python - dunno about Windows ;-) - but do we want this
> sort of code in Python?  Is this sort of hack, however clever, going to
> some back and bite us?
> 
> Second related question:  if people like it, is this feature something we
> can squeeze in for 2.0?
> 
> If there are no objections to any of this, I am happy to test it and check
> it in - but am not confident of doing so without some feedback.
> 
> Thanks,
> 
> Mark.
> 
> 
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://www.python.org/mailman/listinfo/python-dev
> 



From mal at lemburg.com  Mon Oct  2 09:36:49 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Mon, 02 Oct 2000 09:36:49 +0200
Subject: [Python-Dev] Release candidate followed by feature freeze?
References: <200010011913.VAA01107@pandora.informatik.hu-berlin.de>
Message-ID: <39D83B11.C1DE9EE8@lemburg.com>

Martin von Loewis wrote:
> 
> > I'd like to poll opinions about this (we haven't had a PythonLabs
> > group meeting about this yet).
> 
> YES! I was hoping somebody would propose such a thing; I was quite
> concerned that check-in procedures are still that liberate.
> 
> To report how similar projects operate: In gcc, a CVS release branch
> is created at some point in time (usually months before the
> release). When the code is declared frozen, all changes to the release
> branch have to go through the release manager. After the release,
> "important" changes to the mainline branch are manually propagated to
> the release branch for subminor releases.

+1

I think this is very good approach to the problem which we should
consider to apply to Python too.

BTW, could the nightly snapshots of the CVS tree that Jeremy
installed be made official ? 

This would be a great way to attract more beta-tester since not
everyone is willing to first set CVS on their machine just
to download the current Python development version.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From martin at loewis.home.cs.tu-berlin.de  Mon Oct  2 09:39:09 2000
From: martin at loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Mon, 2 Oct 2000 09:39:09 +0200
Subject: [Python-Dev] What is --with-next-framework
Message-ID: <200010020739.JAA01243@loewis.home.cs.tu-berlin.de>

I've been trying to understand how --with-next-framework is supposed
to work, and on what systems it is supposed to work - with little
success.

From what I understand, it will create a python2.0.dylib, and it will
pass that to the linker when linking extension modules. Fine.

What confuses me is the snippet in Modules/getpath.c, where it somehow
assumes that the Python library will live in an unversioned lib
directory relative to the location of the Python framework. How is
that supposed to work? Is anybody here willing to claim that this code
is not entirely broken?

Regards,
Martin



From mal at lemburg.com  Mon Oct  2 09:51:37 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Mon, 02 Oct 2000 09:51:37 +0200
Subject: [Python-Dev] Changes in semantics to str()?
References: <200009302056.PAA14718@cj20424-a.reston1.va.home.com>
Message-ID: <39D83E89.62F57D79@lemburg.com>

Guido van Rossum wrote:
> 
> When we changed floats to behave different on repr() than on str(), we
> briefly discussed changes to the container objects as well, but
> nothing came of it.
> 
> Currently, str() of a tuple, list or dictionary is the same as repr()
> of those objects.  This is not very consistent.  For example, when we
> have a float like 1.1 which can't be represented exactly, str() yields
> "1.1" but repr() yields "1.1000000000000001".  But if we place the
> same number in a list, it doesn't matter which function we use: we
> always get "[1.1000000000000001]".
> 
> Below I have included changes to listobject.c, tupleobject.c and
> dictobject.c that fix this.  The fixes change the print and str()
> callbacks for these objects to use PyObject_Str() on the contained
> items -- except if the item is a string or Unicode string.  I made
> these exceptions because I don't like the idea of str(["abc"])
> yielding [abc] -- I'm too used to the idea of seeing ['abc'] here.
> And str() of a Unicode object fails when it contains non-ASCII
> characters, so that's no good either -- it would break too much code.
> 
> Is it too late to check this in?  Another negative consequence would
> be that for user-defined or 3rd party extension objects that have
> different repr() and str(), like NumPy arrays, it might break some
> code -- but I think this is not very likely.

-1

I don't think that such a change is really worth breaking
code which relies on the current output of repr(list) or
str(list). As the test script from Fredrik for the Unicode
database showed there are some very subtle implications to
changes in str() and repr() -- e.g. in the mentioned case
the hash value would change.

Also, if I understand the patch correctly, str(list) would
be almost the same as '[' + ', '.join(map(str, entries)) + ']'
and '[' + ', '.join(map(repr, entries)) + ']' for repr().

While this may seem more transparent, I think it will cause
problems in practice: e.g. for large data buffers,
str(list) would now return the contents of the buffers
rather than just an abstract note about a buffer containing
the memory mapped data of file xyz.txt. As consequence, you'd
suddenly get a few MBs of output instead of a 100 char string...

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From martin at loewis.home.cs.tu-berlin.de  Mon Oct  2 09:48:37 2000
From: martin at loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Mon, 2 Oct 2000 09:48:37 +0200
Subject: [Python-Dev] Usage of --with- configure options
Message-ID: <200010020748.JAA01293@loewis.home.cs.tu-berlin.de>

I noticed that Python's configure.in does not follow the autoconf
style for using --enable- options. The autoconf documentation says

#   Some packages require, or can optionally use, other software packages
# which are already installed.  The user can give `configure' command
# line options to specify which such external software to use.  The
#  options have one of these forms:
#
#     --with-PACKAGE[=ARG]
#     --without-PACKAGE
...
#    If a software package has optional compile-time features, the user
# can give `configure' command line options to specify whether to compile
# them.  The options have one of these forms:
#
#     --enable-FEATURE[=ARG]
#     --disable-FEATURE

So --with- options should be used for integrating 3rd party libraries,
--enable- options for features that that can be independently turned
on or off.

I'd conclude that the following options are provided incorrectly in
Python 2.0: --with-pydebug (should be --enable-pydebug),
--with(out)-cycle-gc (should be --disable-cycle-gc). Is this something
that should change?

Regards,
Martin




From guido at python.org  Mon Oct  2 13:30:45 2000
From: guido at python.org (Guido van Rossum)
Date: Mon, 02 Oct 2000 06:30:45 -0500
Subject: [Python-Dev] Usage of --with- configure options
In-Reply-To: Your message of "Mon, 02 Oct 2000 09:48:37 +0200."
             <200010020748.JAA01293@loewis.home.cs.tu-berlin.de> 
References: <200010020748.JAA01293@loewis.home.cs.tu-berlin.de> 
Message-ID: <200010021130.GAA23606@cj20424-a.reston1.va.home.com>

> I noticed that Python's configure.in does not follow the autoconf
> style for using --enable- options. The autoconf documentation says
> 
> #   Some packages require, or can optionally use, other software packages
> # which are already installed.  The user can give `configure' command
> # line options to specify which such external software to use.  The
> #  options have one of these forms:
> #
> #     --with-PACKAGE[=ARG]
> #     --without-PACKAGE
> ...
> #    If a software package has optional compile-time features, the user
> # can give `configure' command line options to specify whether to compile
> # them.  The options have one of these forms:
> #
> #     --enable-FEATURE[=ARG]
> #     --disable-FEATURE
> 
> So --with- options should be used for integrating 3rd party libraries,
> --enable- options for features that that can be independently turned
> on or off.
> 
> I'd conclude that the following options are provided incorrectly in
> Python 2.0: --with-pydebug (should be --enable-pydebug),
> --with(out)-cycle-gc (should be --disable-cycle-gc). Is this something
> that should change?

I noticed that too.  (Arguably also for --with-thread?)  I think it's
a forgiveable sin against the autoconf style guide, and not worth the
work of fixing it.

Either way the autoconf --with- or --enable- syntax is stupid because
it doesn't check for spelling errors in the options.  The rationale
for that is that some folks like to pass in unsupported options to a
whole tree of configure scripts.  I think that stinks, but what can I
do.  This would make the fix even more work, because we would have to
trap --with*-pydebug and --with*-cycle-gc to give an error message,
else developers used to the old syntax would never notice the change.

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




From guido at python.org  Mon Oct  2 13:35:40 2000
From: guido at python.org (Guido van Rossum)
Date: Mon, 02 Oct 2000 06:35:40 -0500
Subject: [Python-Dev] What is --with-next-framework
In-Reply-To: Your message of "Mon, 02 Oct 2000 09:39:09 +0200."
             <200010020739.JAA01243@loewis.home.cs.tu-berlin.de> 
References: <200010020739.JAA01243@loewis.home.cs.tu-berlin.de> 
Message-ID: <200010021135.GAA23630@cj20424-a.reston1.va.home.com>

> I've been trying to understand how --with-next-framework is supposed
> to work, and on what systems it is supposed to work - with little
> success.
> 
> From what I understand, it will create a python2.0.dylib, and it will
> pass that to the linker when linking extension modules. Fine.
> 
> What confuses me is the snippet in Modules/getpath.c, where it somehow
> assumes that the Python library will live in an unversioned lib
> directory relative to the location of the Python framework. How is
> that supposed to work? Is anybody here willing to claim that this code
> is not entirely broken?

It's most likely broken.  Which suggests that nobody has tried it in a
*looooooong* time.  I have no idea what the --with-next-framework
option does, and I have no idea what a NeXT framework is.

Why are we still trying to support NeXT?  Isn't it completely
obsolete?

I propose to rip out --with-next-framework and be done with it.  If
you feel --with-next-framework is worth having, feel free to propose
platform-specific fixes to getpathp.c.

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



From fdrake at beopen.com  Mon Oct  2 15:22:19 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Mon, 2 Oct 2000 09:22:19 -0400 (EDT)
Subject: [Python-Dev] Usage of --with- configure options
In-Reply-To: <200010020748.JAA01293@loewis.home.cs.tu-berlin.de>
References: <200010020748.JAA01293@loewis.home.cs.tu-berlin.de>
Message-ID: <14808.35851.589320.360123@cj42289-a.reston1.va.home.com>

Martin v. Loewis writes:
 > I'd conclude that the following options are provided incorrectly in
 > Python 2.0: --with-pydebug (should be --enable-pydebug),
 > --with(out)-cycle-gc (should be --disable-cycle-gc). Is this something
 > that should change?

  Yes, if only to make it more consistent with existing practice.  A
harder one to change would be --enable-threads, because we've used
that for so long already.  Perhaps --enable-threads should be added,
and use that in the README instead of --with-threads.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From fredrik at pythonware.com  Mon Oct  2 15:41:21 2000
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Mon, 2 Oct 2000 15:41:21 +0200
Subject: [Python-Dev] Release candidate followed by feature freeze?
References: <200010010531.AAA15697@cj20424-a.reston1.va.home.com>
Message-ID: <001601c02c76$73a1cac0$0900a8c0@SPIFF>

guido wrote:
> If the idea of a RC sounds okay

Sure does.

> I'd like to propose to release it on October 5. 

Hmm.  My plan was to to work on the remaining SRE issues on
Saturday, leaving Sunday-Tuesday for final "burn-in"...

</F>




From petrilli at amber.org  Mon Oct  2 16:14:23 2000
From: petrilli at amber.org (Christopher Petrilli)
Date: Mon, 2 Oct 2000 10:14:23 -0400
Subject: [Python-Dev] What is --with-next-framework
In-Reply-To: <200010021135.GAA23630@cj20424-a.reston1.va.home.com>; from guido@python.org on Mon, Oct 02, 2000 at 06:35:40AM -0500
References: <200010020739.JAA01243@loewis.home.cs.tu-berlin.de> <200010021135.GAA23630@cj20424-a.reston1.va.home.com>
Message-ID: <20001002101423.A18958@trump.amber.org>

Guido van Rossum [guido at python.org] wrote:
> > I've been trying to understand how --with-next-framework is supposed
> > to work, and on what systems it is supposed to work - with little
> > success.
> > 
> > From what I understand, it will create a python2.0.dylib, and it will
> > pass that to the linker when linking extension modules. Fine.
> > 
> > What confuses me is the snippet in Modules/getpath.c, where it somehow
> > assumes that the Python library will live in an unversioned lib
> > directory relative to the location of the Python framework. How is
> > that supposed to work? Is anybody here willing to claim that this code
> > is not entirely broken?
> 
> It's most likely broken.  Which suggests that nobody has tried it in a
> *looooooong* time.  I have no idea what the --with-next-framework
> option does, and I have no idea what a NeXT framework is.

A NeXT Framework is a way of building software on NeXTstep/OpenStep
machines, and as far as I can tell, it continues largely unmodified on 
MacOS X (which is more OpenStep than MacOS at many layers).  We just
got our development copies of MacOS X here at Digital Creations, so we 
can take a look, but... as I recall, Jeffrey Shell wasn't able to get
Python running without using these options.

> Why are we still trying to support NeXT?  Isn't it completely
> obsolete?

I know of a few dozen large organizations still on OpenStep, and with
MacOS X I'd say it's far frrom obsolete, if anything it's more likely
than ever to be a"strong platform".

> I propose to rip out --with-next-framework and be done with it.  If
> you feel --with-next-framework is worth having, feel free to propose
> platform-specific fixes to getpathp.c.

I think it should be auto-detected, there's just no reason not to.
The uname of a MacOS X box is quite different than a Mac OX 9 box
(which has no uname :-).  Hopefully we can get a chance to look at
this at work this week.

Chris
-- 
| Christopher Petrilli
| petrilli at amber.org



From thomas at xs4all.net  Mon Oct  2 19:23:19 2000
From: thomas at xs4all.net (Thomas Wouters)
Date: Mon, 2 Oct 2000 19:23:19 +0200
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules readline.c,2.32,2.33
In-Reply-To: <200010021553.IAA01251@slayer.i.sourceforge.net>; from gvanrossum@users.sourceforge.net on Mon, Oct 02, 2000 at 08:53:12AM -0700
References: <200010021553.IAA01251@slayer.i.sourceforge.net>
Message-ID: <20001002192319.C12812@xs4all.nl>

On Mon, Oct 02, 2000 at 08:53:12AM -0700, Guido van Rossum wrote:

> Update of /cvsroot/python/python/dist/src/Modules
> In directory slayer.i.sourceforge.net:/tmp/cvs-serv1200

> Modified Files:
> 	readline.c 
> Log Message:
> Supporting rl_library_version is more trouble than it's worth --
> readline doesn't have it before readline 2.2 and there's no
> compile-time way to find out which readline version is in use.

But we can detect whether readline has rl_library_version during runtime,
and #ifdef it ;) I think the readline version info is useful enough to
warrant the extra #define and #ifdef... I can whip it up tonight, if the
autoconf check is desired ;P

-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!



From guido at python.org  Mon Oct  2 20:54:31 2000
From: guido at python.org (Guido van Rossum)
Date: Mon, 02 Oct 2000 13:54:31 -0500
Subject: [Python-Dev] What is --with-next-framework
In-Reply-To: Your message of "Mon, 02 Oct 2000 10:14:23 -0400."
             <20001002101423.A18958@trump.amber.org> 
References: <200010020739.JAA01243@loewis.home.cs.tu-berlin.de> <200010021135.GAA23630@cj20424-a.reston1.va.home.com>  
            <20001002101423.A18958@trump.amber.org> 
Message-ID: <200010021854.NAA01120@cj20424-a.reston1.va.home.com>

[Argument for the continued viability of OpenStep noted.]

> I think it should be auto-detected, there's just no reason not to.
> The uname of a MacOS X box is quite different than a Mac OX 9 box
> (which has no uname :-).  Hopefully we can get a chance to look at
> this at work this week.

Hm...  That might not get there in time for the 2.0 Release Candidate,
and after that it's an absolute code freeze (with exceptions only for
showstopper bugfixes) until 2.0 is released.

I guess MacOS X itself is still in beta, so we can afford to require
the creation of additional patches to fully support it after 2.0 is
released.

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




From petrilli at trump.amber.org  Mon Oct  2 19:56:03 2000
From: petrilli at trump.amber.org (Christopher Petrilli)
Date: Mon, 2 Oct 2000 13:56:03 -0400
Subject: [Python-Dev] What is --with-next-framework
In-Reply-To: <200010021854.NAA01120@cj20424-a.reston1.va.home.com>; from guido@python.org on Mon, Oct 02, 2000 at 01:54:31PM -0500
References: <200010020739.JAA01243@loewis.home.cs.tu-berlin.de> <200010021135.GAA23630@cj20424-a.reston1.va.home.com> <20001002101423.A18958@trump.amber.org> <200010021854.NAA01120@cj20424-a.reston1.va.home.com>
Message-ID: <20001002135603.C18958@trump.amber.org>

Guido van Rossum [guido at python.org] wrote:
> [Argument for the continued viability of OpenStep noted.]
> 
> > I think it should be auto-detected, there's just no reason not to.
> > The uname of a MacOS X box is quite different than a Mac OX 9 box
> > (which has no uname :-).  Hopefully we can get a chance to look at
> > this at work this week.
> 
> Hm...  That might not get there in time for the 2.0 Release Candidate,
> and after that it's an absolute code freeze (with exceptions only for
> showstopper bugfixes) until 2.0 is released.
> 
> I guess MacOS X itself is still in beta, so we can afford to require
> the creation of additional patches to fully support it after 2.0 is
> released.

MacOS X is in beta until Q1 (and I'd bet the END of Q1), so if there's 
a 2.1 planned sometime around there, which I believe there is, then
it'd be fine to roll it into that level in my opinion.

Chris
-- 
| Christopher Petrilli
| petrilli at amber.org



From guido at python.org  Mon Oct  2 21:15:37 2000
From: guido at python.org (Guido van Rossum)
Date: Mon, 02 Oct 2000 14:15:37 -0500
Subject: [Python-Dev] Changes in semantics to str()?
In-Reply-To: Your message of "Sun, 01 Oct 2000 14:06:48 +0200."
             <20001001140648.A12812@xs4all.nl> 
References: <200009302056.PAA14718@cj20424-a.reston1.va.home.com>  
            <20001001140648.A12812@xs4all.nl> 
Message-ID: <200010021915.OAA01219@cj20424-a.reston1.va.home.com>

I guess Thomas has settled the fate of my str() patch -- UserString
won't be dealt with properly.  I hereby withdraw the patch.

(I'm not sure what Marc-Andre means by buffer objects whose str() is
long but whose repr() is short, but it's probably a similar issue.)

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



From guido at python.org  Mon Oct  2 21:19:24 2000
From: guido at python.org (Guido van Rossum)
Date: Mon, 02 Oct 2000 14:19:24 -0500
Subject: [Python-Dev] Release candidate followed by feature freeze?
In-Reply-To: Your message of "Sun, 01 Oct 2000 21:13:41 +0200."
             <200010011913.VAA01107@pandora.informatik.hu-berlin.de> 
References: <200010011913.VAA01107@pandora.informatik.hu-berlin.de> 
Message-ID: <200010021919.OAA01232@cj20424-a.reston1.va.home.com>

> YES! I was hoping somebody would propose such a thing; I was quite
> concerned that check-in procedures are still that liberate.

Good.  We will have a release candidate then.

> To report how similar projects operate: In gcc, a CVS release branch
> is created at some point in time (usually months before the
> release). When the code is declared frozen, all changes to the release
> branch have to go through the release manager. After the release,
> "important" changes to the mainline branch are manually propagated to
> the release branch for subminor releases.

I am reluctant to use CVS branches (my experience with the branch for
1.6 suggests again that this is not at all smooth).

About the timing for the release candidate (RC): I think we need a
week +/- two days between the RC and the final release; this is needed
to make sure that the RC is actually tried out by enough people and
that the bug reports (if any) have been processed.  I believe we can
refrain from checkin in for a week but not much longer.

Fredrik Lundh mentions that he can't get his final batch of SRE
patches in before Saturday.  So the only realistic timing is to do the
RC on Monday (Oct 9) and the final release a week later (Oct 16).

Everybody okay with this?

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



From mal at lemburg.com  Mon Oct  2 20:35:27 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Mon, 02 Oct 2000 20:35:27 +0200
Subject: [Python-Dev] Changes in semantics to str()?
References: <200009302056.PAA14718@cj20424-a.reston1.va.home.com>  
	            <20001001140648.A12812@xs4all.nl> <200010021915.OAA01219@cj20424-a.reston1.va.home.com>
Message-ID: <39D8D56F.F279B9E5@lemburg.com>

Guido van Rossum wrote:
> 
> I guess Thomas has settled the fate of my str() patch -- UserString
> won't be dealt with properly.  I hereby withdraw the patch.
> 
> (I'm not sure what Marc-Andre means by buffer objects whose str() is
> long but whose repr() is short, but it's probably a similar issue.)
>

Example for the record:

>>> b = buffer('long string')
>>> b
<read-only buffer for 0x82a0160, ptr 0x82a0174, size 11 at 0x82db170>
>>> l = [b]
>>> l
[<read-only buffer for 0x82a0160, ptr 0x82a0174, size 11 at 0x82db170>]
>>> [str(b)]
['long string']

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From nas at arctrix.com  Mon Oct  2 13:48:59 2000
From: nas at arctrix.com (Neil Schemenauer)
Date: Mon, 2 Oct 2000 04:48:59 -0700
Subject: [Python-Dev] Release candidate followed by feature freeze?
In-Reply-To: <200010021919.OAA01232@cj20424-a.reston1.va.home.com>; from guido@python.org on Mon, Oct 02, 2000 at 02:19:24PM -0500
References: <200010011913.VAA01107@pandora.informatik.hu-berlin.de> <200010021919.OAA01232@cj20424-a.reston1.va.home.com>
Message-ID: <20001002044859.A9639@glacier.fnational.com>

On Mon, Oct 02, 2000 at 02:19:24PM -0500, Guido van Rossum wrote:
> So the only realistic timing is to do the RC on Monday (Oct 9)
> and the final release a week later (Oct 16).
> 
> Everybody okay with this?

What is going to be the fate of the GC?  There are currently two
reported bugs which I have been unable to reproduce.  If its
going to be disabled for 2.0 then it should be disabled in the
beta release.

  Neil



From effbot at telia.com  Mon Oct  2 21:11:58 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Mon, 2 Oct 2000 21:11:58 +0200
Subject: [Python-Dev] Re: [Bug #115845] sre: maxsplit as keyword argument
References: <200010021341.GAA26413@bush.i.sourceforge.net>
Message-ID: <003e01c02ca4$a7e2ef20$766940d5@hagrid>

http://sourceforge.net/bugs/?func=detailbug&bug_id=115845&group_id=5470

> Details: Split gives TypeError when called as a method of compiled
> regular expression object with maxsplit as keyword argument.
> This error is only in sre, pre is OK.
> 
> Python 1.6 (#2, Sep  6 2000, 18:20:07) [C] on osf1V4
> >>> import re
> >>> patt = re.compile(' ')
> >>> list = patt.split("a b c",50)              # OK
> >>> list = re.split(' ',"a b c",maxsplit=50)   # OK     
> >>> list = patt.split("a b c",maxsplit=50)     # ERROR
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
> TypeError: this function takes no keyword arguments
> 
> >>> import pre
> >>> patt = pre.compile(' ')
> >>> list = patt.split("a b c",maxsplit=50)     # OK

is this really a bug?  should users expect to be able to use
keyword arguments anywhere?

</F>




From guido at python.org  Mon Oct  2 22:09:32 2000
From: guido at python.org (Guido van Rossum)
Date: Mon, 02 Oct 2000 15:09:32 -0500
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules readline.c,2.32,2.33
In-Reply-To: Your message of "Mon, 02 Oct 2000 19:23:19 +0200."
             <20001002192319.C12812@xs4all.nl> 
References: <200010021553.IAA01251@slayer.i.sourceforge.net>  
            <20001002192319.C12812@xs4all.nl> 
Message-ID: <200010022009.PAA01439@cj20424-a.reston1.va.home.com>

> But we can detect whether readline has rl_library_version during runtime,
> and #ifdef it ;) I think the readline version info is useful enough to
> warrant the extra #define and #ifdef... I can whip it up tonight, if the
> autoconf check is desired ;P

Actually, I'm not sure what difference the readline version makes --
why would you need it?

Also, I'm not sure that the configure check is enough -- it's possible
that readline lives in a non-standard place where configure can't find
it but ppointed to by the Setup file.

I think it's just not worth it.

Please don't.

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



From guido at python.org  Mon Oct  2 22:18:57 2000
From: guido at python.org (Guido van Rossum)
Date: Mon, 02 Oct 2000 15:18:57 -0500
Subject: [Python-Dev] Re: [Bug #115845] sre: maxsplit as keyword argument
In-Reply-To: Your message of "Mon, 02 Oct 2000 21:11:58 +0200."
             <003e01c02ca4$a7e2ef20$766940d5@hagrid> 
References: <200010021341.GAA26413@bush.i.sourceforge.net>  
            <003e01c02ca4$a7e2ef20$766940d5@hagrid> 
Message-ID: <200010022018.PAA01525@cj20424-a.reston1.va.home.com>

> http://sourceforge.net/bugs/?func=detailbug&bug_id=115845&group_id=5470
> 
> > Details: Split gives TypeError when called as a method of compiled
> > regular expression object with maxsplit as keyword argument.
> > This error is only in sre, pre is OK.
> > 
> > Python 1.6 (#2, Sep  6 2000, 18:20:07) [C] on osf1V4
> > >>> import re
> > >>> patt = re.compile(' ')
> > >>> list = patt.split("a b c",50)              # OK
> > >>> list = re.split(' ',"a b c",maxsplit=50)   # OK     
> > >>> list = patt.split("a b c",maxsplit=50)     # ERROR
> > Traceback (most recent call last):
> >   File "<stdin>", line 1, in ?
> > TypeError: this function takes no keyword arguments
> > 
> > >>> import pre
> > >>> patt = pre.compile(' ')
> > >>> list = patt.split("a b c",maxsplit=50)     # OK
> 
> is this really a bug?  should users expect to be able to use
> keyword arguments anywhere?

Unclear, but the names were documented, and it worked before (when
pattern objects were Python instances) -- so who knows how much code
there's lying around that assumes this.  Well, we know it's more than
zero, because the bug report came from soemone who ran into this. :-)

Can we at PythonLabs help by adding keyword arguments to all of the
_sre.c functions?  I presume it's a pretty straightforward change.

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



From effbot at telia.com  Mon Oct  2 21:35:45 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Mon, 2 Oct 2000 21:35:45 +0200
Subject: [Python-Dev] Re: [Bug #115845] sre: maxsplit as keyword argument
References: <200010021341.GAA26413@bush.i.sourceforge.net>              <003e01c02ca4$a7e2ef20$766940d5@hagrid>  <200010022018.PAA01525@cj20424-a.reston1.va.home.com>
Message-ID: <014001c02ca8$44f7eb00$766940d5@hagrid>

> Can we at PythonLabs help by adding keyword arguments to all of the
> _sre.c functions?  I presume it's a pretty straightforward change.

if anyone can post (or point me to) an example showing
how to use the keyword API, I can take if from there.

</F>




From guido at python.org  Mon Oct  2 23:06:00 2000
From: guido at python.org (Guido van Rossum)
Date: Mon, 02 Oct 2000 16:06:00 -0500
Subject: [Python-Dev] Re: [Bug #115845] sre: maxsplit as keyword argument
In-Reply-To: Your message of "Mon, 02 Oct 2000 21:35:45 +0200."
             <014001c02ca8$44f7eb00$766940d5@hagrid> 
References: <200010021341.GAA26413@bush.i.sourceforge.net> <003e01c02ca4$a7e2ef20$766940d5@hagrid> <200010022018.PAA01525@cj20424-a.reston1.va.home.com>  
            <014001c02ca8$44f7eb00$766940d5@hagrid> 
Message-ID: <200010022106.QAA01620@cj20424-a.reston1.va.home.com>

> if anyone can post (or point me to) an example showing
> how to use the keyword API, I can take if from there.

Grep the Modules directory for PyArg_ParseTupleAndKeywords.  It's used
in the mmap, parser, pyexpat and sha modules.

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



From fdrake at beopen.com  Mon Oct  2 22:04:30 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Mon, 2 Oct 2000 16:04:30 -0400 (EDT)
Subject: [Python-Dev] Re: [Bug #115845] sre: maxsplit as keyword argument
In-Reply-To: <014001c02ca8$44f7eb00$766940d5@hagrid>
References: <200010021341.GAA26413@bush.i.sourceforge.net>
	<003e01c02ca4$a7e2ef20$766940d5@hagrid>
	<200010022018.PAA01525@cj20424-a.reston1.va.home.com>
	<014001c02ca8$44f7eb00$766940d5@hagrid>
Message-ID: <14808.59982.32731.732799@cj42289-a.reston1.va.home.com>

Fredrik Lundh writes:
 > if anyone can post (or point me to) an example showing
 > how to use the keyword API, I can take if from there.

  This is documented in the Extending & Embedding manual.  The parser
module (Modules/parsermodule.c) uses this.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From MarkH at ActiveState.com  Tue Oct  3 00:37:13 2000
From: MarkH at ActiveState.com (Mark Hammond)
Date: Tue, 3 Oct 2000 09:37:13 +1100
Subject: [Python-Dev] Release candidate followed by feature freeze?
In-Reply-To: <001601c02c76$73a1cac0$0900a8c0@SPIFF>
Message-ID: <ECEPKNMJLHAPFFJHDOJBGEOBDLAA.MarkH@ActiveState.com>

> guido wrote:
> > If the idea of a RC sounds okay
>
> Sure does.
>
> > I'd like to propose to release it on October 5.
>
> Hmm.  My plan was to to work on the remaining SRE issues on
> Saturday, leaving Sunday-Tuesday for final "burn-in"...

Also FYI, I intend applying the previous-version-crash patch tomorrow (or
late today), so those extra few days for /F would also prevent this patch
going out _too_ green...

Mark.




From fdrake at beopen.com  Tue Oct  3 02:23:13 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Mon, 2 Oct 2000 20:23:13 -0400 (EDT)
Subject: [Python-Dev] Development HTML docs online
Message-ID: <14809.9969.61986.897165@cj42289-a.reston1.va.home.com>

  I've set things up so I can easily "publish" the Python
documentation online without actually building a release.  It's not
entirely automatic, but I can push it online easily, so you'll be able
to see what I'm doing.  It can include more than just what's in CVS,
but I try not to have too much waiting to checkin at once.
  Check it out:

	ftp://python.beopen.com/pub/docco/devel/index.html


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From guido at python.org  Tue Oct  3 04:36:03 2000
From: guido at python.org (Guido van Rossum)
Date: Mon, 02 Oct 2000 21:36:03 -0500
Subject: [Python-Dev] Release candidate followed by feature freeze?
In-Reply-To: Your message of "Mon, 02 Oct 2000 04:48:59 MST."
             <20001002044859.A9639@glacier.fnational.com> 
References: <200010011913.VAA01107@pandora.informatik.hu-berlin.de> <200010021919.OAA01232@cj20424-a.reston1.va.home.com>  
            <20001002044859.A9639@glacier.fnational.com> 
Message-ID: <200010030236.VAA02702@cj20424-a.reston1.va.home.com>

> What is going to be the fate of the GC?  There are currently two
> reported bugs which I have been unable to reproduce.  If its
> going to be disabled for 2.0 then it should be disabled in the
> beta release.

Good point.  I see only the one that's assigned to you (reported by
Rob Hooft):

http://sourceforge.net/bugs/?group_id=5470&func=detailbug&bug_id=115341

What's the other?

Hooft's problem makes heavy use of Tkinter and Pmw, it seems.  Maybe
that's a clue?  Does he also use threads?  Is he willing to send his
entire program over?  (If you don't have time, we may have time at
PythonLabs!)

Anyway, I'm not yet ready to disable GC by default -- that's sensible
but also defeats the purpose...

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



From gward at python.net  Tue Oct  3 06:08:45 2000
From: gward at python.net (Greg Ward)
Date: Tue, 3 Oct 2000 00:08:45 -0400
Subject: [Python-Dev] ANNOUNCE: Distutils 1.0
Message-ID: <20001003000845.A1812@beelzebub>

                     Python Distribution Utilities
                              release 1.0
                            October 2, 2000

The Python Distribution Utilities, or Distutils for short, are a
collection of modules that aid in the development, distribution, and
installation of Python modules.  (It is intended that ultimately the
Distutils will grow up into a system for distributing and installing
whole Python applications, but for now their scope is limited to module
distributions.)

The Distutils are a standard part of Python 1.6 and 2.0; if you are running
1.6 or 2.0, you don't need to install the Distutils separately.  (However,
you might want to upgrade if you're running Python 1.6.)  This release is
primarily so that you can add the Distutils to a Python 1.5.2 installation
-- you will then be able to install modules that require the Distutils, or
use the Distutils to distribute your own modules.

Distutils 1.0 is the version that will be released with Python 2.0 (unless
last-minute bugs pop up).

More information is available at the Distutils web page:

    http://www.python.org/sigs/distutils-sig/

and in the README.txt included in the Distutils source distribution.

You can download the Distutils from

    http://www.python.org/sigs/distutils-sig/download.html

Trivial patches can be sent to me (Greg Ward) at gward at python.net.
Larger patches should be discussed on the Distutils mailing list:
distutils-sig at python.org.

        Greg
-- 
Greg Ward                                      gward at python.net
http://starship.python.net/~gward/
And now for something completely different.



From fredrik at pythonware.com  Tue Oct  3 10:52:37 2000
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Tue, 3 Oct 2000 10:52:37 +0200
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib cgi.py,1.53,1.54
References: <200010030832.BAA05615@slayer.i.sourceforge.net>
Message-ID: <011801c02d17$48659b10$0900a8c0@SPIFF>

> Change first line to #!/usr/bin/env python (really just to test check-in).

hmm.  cgi.py is a CGI script.  according to the Python FAQ, CGI
scripts should use an explicit path, not /usr/bin/env:

    "Note -- *don't* do this for CGI scripts. The $PATH variable
    for CGI scripts is often very minimal, so you need to use the
    actual absolute pathname of the interpreter."

(since this comes up over and over again, maybe someone should
add a comment to the file?)

</F>




From ping at lfw.org  Tue Oct  3 12:15:13 2000
From: ping at lfw.org (Ka-Ping Yee)
Date: Tue, 3 Oct 2000 03:15:13 -0700 (PDT)
Subject: [Python-Dev] Re: CVS: python/dist/src/Lib cgi.py,1.53,1.54
In-Reply-To: <011801c02d17$48659b10$0900a8c0@SPIFF>
Message-ID: <Pine.LNX.4.10.10010030310460.744-100000@skuld.kingmanhall.org>

On Tue, 3 Oct 2000, Fredrik Lundh wrote:
> > Change first line to #!/usr/bin/env python (really just to test check-in).
> 
> hmm.  cgi.py is a CGI script.  according to the Python FAQ, CGI
> scripts should use an explicit path, not /usr/bin/env:
> 
>     "Note -- *don't* do this for CGI scripts. The $PATH variable
>     for CGI scripts is often very minimal, so you need to use the
>     actual absolute pathname of the interpreter."

The $PATH variable for CGI scripts may be minimal, but minimal
as it is, Python should still be on it.  Using /usr/bin/python
works for half the people and /usr/local/bin/python works for
the other half... /usr/bin/env is supposed to work for everyone.

If this has already been argued soundly to death, i'm happy to
back out the change and add a comment.  It was a meaningless
change for me anyway.

Oh well.  Anyway, i'm glad CVS commit *finally* works for me.
Sorry for the extra hassle.


-- ?!ng

"To be human is to continually change.  Your desire to remain as you are
is what ultimately limits you."
    -- The Puppet Master, Ghost in the Shell




From nas at arctrix.com  Tue Oct  3 08:41:18 2000
From: nas at arctrix.com (Neil Schemenauer)
Date: Mon, 2 Oct 2000 23:41:18 -0700
Subject: [Python-Dev] Release candidate followed by feature freeze?
In-Reply-To: <200010030236.VAA02702@cj20424-a.reston1.va.home.com>; from guido@python.org on Mon, Oct 02, 2000 at 09:36:03PM -0500
References: <200010011913.VAA01107@pandora.informatik.hu-berlin.de> <200010021919.OAA01232@cj20424-a.reston1.va.home.com> <20001002044859.A9639@glacier.fnational.com> <200010030236.VAA02702@cj20424-a.reston1.va.home.com>
Message-ID: <20001002234118.A11108@glacier.fnational.com>

On Mon, Oct 02, 2000 at 09:36:03PM -0500, Guido van Rossum wrote:
> What's the other?

Some people from Origin Systems have reported a crash.  They are
using Python in a large application (probably related to the
Ultima Online game).  I will put the bug report in the database
today.

They are using a custom version of cPickle that may be causing
the problem.  It is an instance object which is causing the
trouble.  My malloc() == NULL patch for classobject.c did not fix
things.  They still haven't reported back regarding the cPickle
fix.

> Hooft's problem makes heavy use of Tkinter and Pmw, it seems.
> Maybe that's a clue?

I don't think _tkinter does anything special (unlike cPickle and
new).

> Does he also use threads?

His interpreter has threads enabled it seems.  Maybe I should get
him to test without threads, assuming he doesn't require them.

> Is he willing to send his entire program over?


From bwarsaw at beopen.com  Tue Oct  3 15:49:23 2000
From: bwarsaw at beopen.com (Barry A. Warsaw)
Date: Tue, 3 Oct 2000 09:49:23 -0400 (EDT)
Subject: [Python-Dev] Re: CVS: python/dist/src/Lib cgi.py,1.53,1.54
References: <011801c02d17$48659b10$0900a8c0@SPIFF>
	<Pine.LNX.4.10.10010030310460.744-100000@skuld.kingmanhall.org>
Message-ID: <14809.58339.707476.273418@anthem.concentric.net>

>>>>> "KY" == Ka-Ping Yee <ping at lfw.org> writes:

    KY> The $PATH variable for CGI scripts may be minimal, but minimal
    KY> as it is, Python should still be on it.

Well, maybe. :) E.g. Mailman's cgi wrapper program explicitly removes
$PATH from the environment before calling python with a compiled in
absolute path.

Which leads me to ask: how often are you calling cgi.py directly
anyway?  That'll just run the text() function which isn't terribly
useful other than to debug your cgi setup.  Usually you're calling
some other module that imports cgi, and in that case this line won't
have any effect.  And besides, it's not very safe to call a script
directly so I'd recommend a wrapper program anyway.
    
I'd say this one is rather harmless.

-Barry



From guido at python.org  Tue Oct  3 16:58:00 2000
From: guido at python.org (Guido van Rossum)
Date: Tue, 03 Oct 2000 09:58:00 -0500
Subject: [Python-Dev] Re: CVS: python/dist/src/Lib cgi.py,1.53,1.54
In-Reply-To: Your message of "Tue, 03 Oct 2000 03:15:13 MST."
             <Pine.LNX.4.10.10010030310460.744-100000@skuld.kingmanhall.org> 
References: <Pine.LNX.4.10.10010030310460.744-100000@skuld.kingmanhall.org> 
Message-ID: <200010031458.JAA05661@cj20424-a.reston1.va.home.com>

> > hmm.  cgi.py is a CGI script.  according to the Python FAQ, CGI
> > scripts should use an explicit path, not /usr/bin/env:
> > 
> >     "Note -- *don't* do this for CGI scripts. The $PATH variable
> >     for CGI scripts is often very minimal, so you need to use the
> >     actual absolute pathname of the interpreter."
> 
> The $PATH variable for CGI scripts may be minimal, but minimal
> as it is, Python should still be on it.  Using /usr/bin/python
> works for half the people and /usr/local/bin/python works for
> the other half... /usr/bin/env is supposed to work for everyone.

No.  On a typical Unix system (Linux perhaps excluded), /usr/local/bin
is not on the default $PATH.

> If this has already been argued soundly to death, i'm happy to
> back out the change and add a comment.  It was a meaningless
> change for me anyway.

I backed it out for you.  It really has been argued to death.

Glad CVS works for you!

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



From jeremy at beopen.com  Tue Oct  3 17:37:21 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Tue, 3 Oct 2000 11:37:21 -0400 (EDT)
Subject: [Python-Dev] Release candidate followed by feature freeze?
In-Reply-To: <20001002234118.A11108@glacier.fnational.com>
References: <200010011913.VAA01107@pandora.informatik.hu-berlin.de>
	<200010021919.OAA01232@cj20424-a.reston1.va.home.com>
	<20001002044859.A9639@glacier.fnational.com>
	<200010030236.VAA02702@cj20424-a.reston1.va.home.com>
	<20001002234118.A11108@glacier.fnational.com>
Message-ID: <14809.64817.295610.920807@bitdiddle.concentric.net>

>>>>> "NS" == Neil Schemenauer <nas at arctrix.com> writes:

  [GvR writes:]
  >> Anyway, I'm not yet ready to disable GC by default -- that's
  >> sensible but also defeats the purpose...

  NS> Okay.  I think I've found a possible problem.  When I set
  NS> threshold0 to 1 in the C code, weird things start happening.
  NS> I'm looking into it.

I agree that it isn't too useful to ship the garbage collector, but
have it turned off.  On the other hand, we're going to get a lot of
unhappy users if GC bugs cause inexplicable crashes in large
programs.  It would be hard to sell Python for important applications,
e.g. long-running server processes, if there was a small possibility
that the program could crash through no fault of its own.

Jeremy




From bwarsaw at beopen.com  Tue Oct  3 17:39:19 2000
From: bwarsaw at beopen.com (Barry A. Warsaw)
Date: Tue, 3 Oct 2000 11:39:19 -0400 (EDT)
Subject: [Python-Dev] Suggested change for Setup.in
Message-ID: <14809.64935.157146.681813@anthem.concentric.net>

I have a small suggestion for Modules/Setup.in.  On Linux (RH6.1) with
the zlib rpm installed, all I need to enable this module is the
following line:

    zlib zlibmodule.c -lz

but Setup.in has this suggestion, which I think is too hard for people
to figure out what to do:

    zlib zlibmodule.c -I$(prefix)/include -L$(exec_prefix)/lib -lz

The standard build options will already include the right -I and -L
flags for this to Just Work.  I suggest we make the common case
(Linux?) simple, and let others figure out what the right -I and -L
flags are.  I submit that even if they /do/ have to handcraft -I and
-L, the defaults in Setup.in are pretty meaningless.

A worthy change?  For 2.0 final?

-Barry



From guido at python.org  Tue Oct  3 19:31:47 2000
From: guido at python.org (Guido van Rossum)
Date: Tue, 03 Oct 2000 12:31:47 -0500
Subject: [Python-Dev] Canvas.Canvas.bbox() return value
Message-ID: <200010031731.MAA08827@cj20424-a.reston1.va.home.com>

Hi Fredrik,

Re this bug report:

http://sourceforge.net/bugs/?func=detailbug&bug_id=110677&group_id=5470

I can take care of the Canvas issues, but I need your advice on
bbox().  He's right that the bbox() method the Canvas class in the
Canvas module is different from all other bbox() methods: it returns a
tuple of tuples ((x1,y1),(x2,y2)) instead of a flat 4-tuple
(x,y1,x2,y2).

Do you think it's worth not breaking existing code here???

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



From bwarsaw at beopen.com  Tue Oct  3 18:34:51 2000
From: bwarsaw at beopen.com (Barry A. Warsaw)
Date: Tue, 3 Oct 2000 12:34:51 -0400 (EDT)
Subject: [Python-Dev] Small memory leak in unicodeobject.c
Message-ID: <14810.2731.466997.243906@anthem.concentric.net>

I've found a small memory leak in unicodeobject.c, in the way
_PyUnicode_Fini() shuts down.  Take a loop such as:

-------------------- snip snip --------------------
#include "Python.h"

int main(int argc, char** argv)
{
    int i;

    while (1) {
        Py_Initialize();
        Py_Finalize();
    }
    return 0;
}
-------------------- snip snip --------------------

and you'll find that unicode_empty leaks.  This is because, while
_PyUnicode_Fini() decrefs unicode_empty, it never actually gets
freed.  Instead it gets placed on the already freed unicode_freelist!
See _PyUnicode_Free() for why.

I've come up with the following nasty hack to force unicode_empty to
really be freed in _PyUnicode_Fini().  Maybe there's a better way to
do this.  Note that moving the decref of unicode_empty to above the
freeing of unicode_freelist didn't plug the memory leak for me (but
I'm quite tired so maybe I missed something! ;} ).

Below is the proposed patch.
-Barry

-------------------- snip snip --------------------
Index: unicodeobject.c
===================================================================
RCS file: /cvsroot/python/python/dist/src/Objects/unicodeobject.c,v
retrieving revision 2.64
diff -u -r2.64 unicodeobject.c
--- unicodeobject.c	2000/09/26 05:46:01	2.64
+++ unicodeobject.c	2000/10/03 16:31:32
@@ -5234,7 +5234,11 @@
 	PyObject_DEL(v);
     }
     unicode_freelist = NULL;
-    unicode_freelist_size = 0;
+    /* XXX This is a hack to force the freeing of unicode_empty's memory.
+     * Otherwise, it'll get placed on the already freed free list.
+     */
+    unicode_freelist_size = MAX_UNICODE_FREELIST_SIZE;
     Py_XDECREF(unicode_empty);
     unicode_empty = NULL;
+    unicode_freelist_size = 0;
 }



From effbot at telia.com  Tue Oct  3 19:08:05 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Tue, 3 Oct 2000 19:08:05 +0200
Subject: [Python-Dev] Canvas.Canvas.bbox() return value
References: <200010031731.MAA08827@cj20424-a.reston1.va.home.com>
Message-ID: <001801c02d5c$801d0300$766940d5@hagrid>

> Hi Fredrik,
> 
> Re this bug report:
> 
> http://sourceforge.net/bugs/?func=detailbug&bug_id=110677&group_id=5470
> 
> I can take care of the Canvas issues, but I need your advice on
> bbox().  He's right that the bbox() method the Canvas class in the
> Canvas module is different from all other bbox() methods: it returns a
> tuple of tuples ((x1,y1),(x2,y2)) instead of a flat 4-tuple
> (x,y1,x2,y2).
> 
> Do you think it's worth not breaking existing code here???

no idea -- I don't think I've ever used that module (!).

(I'd deprecate the entire module if I were in charge -- there
are better ways to put objects on the canvas)

but in case someone's using it, it's probably best to leave things
as they are...

</F>




From thomas at xs4all.net  Tue Oct  3 19:07:11 2000
From: thomas at xs4all.net (Thomas Wouters)
Date: Tue, 3 Oct 2000 19:07:11 +0200
Subject: [Python-Dev] Suggested change for Setup.in
In-Reply-To: <14809.64935.157146.681813@anthem.concentric.net>; from bwarsaw@beopen.com on Tue, Oct 03, 2000 at 11:39:19AM -0400
References: <14809.64935.157146.681813@anthem.concentric.net>
Message-ID: <20001003190711.D12812@xs4all.nl>

On Tue, Oct 03, 2000 at 11:39:19AM -0400, Barry A. Warsaw wrote:

> but Setup.in has this suggestion, which I think is too hard for people
> to figure out what to do:

>     zlib zlibmodule.c -I$(prefix)/include -L$(exec_prefix)/lib -lz

> The standard build options will already include the right -I and -L
> flags for this to Just Work.  I suggest we make the common case
> (Linux?) simple, and let others figure out what the right -I and -L
> flags are.  I submit that even if they /do/ have to handcraft -I and
> -L, the defaults in Setup.in are pretty meaningless.

> A worthy change?  For 2.0 final?

What about including both -I$(prefix)/include and -L$(exec_prefix)/lib by
default, for all modules, if those directories already exist ? Because zlib
is not the only module that has this problem. On BSDI and Solaris, the
same problem exists for curses, readline and gdbm, at least. If you are
installing in a completely separate tree, for whatever reason, either those
include/lib directories won't exist, they won't contain anything useful, or
they will contain the actual libraries you want to link with, anyway ;-P

And if you are installing in a 'standard' tree, like /usr, /usr/local,
/usr/contrib, /opt, or whatever, the optional GNU stuff is likely to be
there, too. If you don't fall under any of these cases, you'll have to do
what you have to do now, figure it out by hand.

I don't think changing the zlib line alone is going to matter much; it stops
working 'out of the box' for the slightly-less common case of non-linux
platforms (and not even all linux platforms ! There is no reason why a
distribution would install zlib in /usr.) I would prefer adding a
comment that clarifies the -I/-L lines, over removing them altogether, if we
aren't including $prefix/include and $exec_prefix/lib by default.

I-compile-on-BSDI-a-lot--and-every-little-bit-helps-;-)

-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!



From jeremy at beopen.com  Tue Oct  3 19:13:39 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Tue, 3 Oct 2000 13:13:39 -0400 (EDT)
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/test test_pty.py,1.4,1.5
In-Reply-To: <200010031651.JAA06853@slayer.i.sourceforge.net>
References: <200010031651.JAA06853@slayer.i.sourceforge.net>
Message-ID: <14810.5059.445654.876073@bitdiddle.concentric.net>

Thomas,

Thanks for taking care of this.  One nit on the checkin procedure,
pleae reference the SF bug number when you're fixing a bug.  Also,
report the revision number of the changed file when you close the bug.

Thanks,
Jeremy



From fdrake at beopen.com  Tue Oct  3 19:08:06 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Tue, 3 Oct 2000 13:08:06 -0400 (EDT)
Subject: [Python-Dev] Suggested change for Setup.in
In-Reply-To: <14809.64935.157146.681813@anthem.concentric.net>
References: <14809.64935.157146.681813@anthem.concentric.net>
Message-ID: <14810.4726.855657.955145@cj42289-a.reston1.va.home.com>

Barry A. Warsaw writes:
 > A worthy change?  For 2.0 final?

  This is good; even better would be the configure magic to make it
work automatically, similar to what we have for bsddb.  Given the
short time frame, your approach is good.  There may be other modules
that need similar adjustments in Setup.in.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From mal at lemburg.com  Tue Oct  3 19:13:40 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Tue, 03 Oct 2000 19:13:40 +0200
Subject: [Python-Dev] Small memory leak in unicodeobject.c
References: <14810.2731.466997.243906@anthem.concentric.net>
Message-ID: <39DA13C4.B1855D9A@lemburg.com>

"Barry A. Warsaw" wrote:
> 
> I've found a small memory leak in unicodeobject.c, in the way
> _PyUnicode_Fini() shuts down.  Take a loop such as:
> 
> -------------------- snip snip --------------------
> #include "Python.h"
> 
> int main(int argc, char** argv)
> {
>     int i;
> 
>     while (1) {
>         Py_Initialize();
>         Py_Finalize();
>     }
>     return 0;
> }
> -------------------- snip snip --------------------
> 
> and you'll find that unicode_empty leaks.  This is because, while
> _PyUnicode_Fini() decrefs unicode_empty, it never actually gets
> freed.  Instead it gets placed on the already freed unicode_freelist!
> See _PyUnicode_Free() for why.
> 
> I've come up with the following nasty hack to force unicode_empty to
> really be freed in _PyUnicode_Fini().  Maybe there's a better way to
> do this.  Note that moving the decref of unicode_empty to above the
> freeing of unicode_freelist didn't plug the memory leak for me (but
> I'm quite tired so maybe I missed something! ;} ).

It would be easier to simply move the Py_DECREF() in front of the
cleanup code for the free list. That way, unicode_empty would
be placed on the free list, but then immedialtely cleaned up
by the following code.

Should I check in such a patch ?
 
> Below is the proposed patch.
> -Barry
> 
> -------------------- snip snip --------------------
> Index: unicodeobject.c
> ===================================================================
> RCS file: /cvsroot/python/python/dist/src/Objects/unicodeobject.c,v
> retrieving revision 2.64
> diff -u -r2.64 unicodeobject.c
> --- unicodeobject.c     2000/09/26 05:46:01     2.64
> +++ unicodeobject.c     2000/10/03 16:31:32
> @@ -5234,7 +5234,11 @@
>         PyObject_DEL(v);
>      }
>      unicode_freelist = NULL;
> -    unicode_freelist_size = 0;
> +    /* XXX This is a hack to force the freeing of unicode_empty's memory.
> +     * Otherwise, it'll get placed on the already freed free list.
> +     */
> +    unicode_freelist_size = MAX_UNICODE_FREELIST_SIZE;
>      Py_XDECREF(unicode_empty);
>      unicode_empty = NULL;
> +    unicode_freelist_size = 0;
>  }
> 
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://www.python.org/mailman/listinfo/python-dev

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From guido at python.org  Tue Oct  3 20:28:08 2000
From: guido at python.org (Guido van Rossum)
Date: Tue, 03 Oct 2000 13:28:08 -0500
Subject: [Python-Dev] Suggested change for Setup.in
In-Reply-To: Your message of "Tue, 03 Oct 2000 11:39:19 -0400."
             <14809.64935.157146.681813@anthem.concentric.net> 
References: <14809.64935.157146.681813@anthem.concentric.net> 
Message-ID: <200010031828.NAA09229@cj20424-a.reston1.va.home.com>

> I have a small suggestion for Modules/Setup.in.  On Linux (RH6.1) with
> the zlib rpm installed, all I need to enable this module is the
> following line:
> 
>     zlib zlibmodule.c -lz
> 
> but Setup.in has this suggestion, which I think is too hard for people
> to figure out what to do:
> 
>     zlib zlibmodule.c -I$(prefix)/include -L$(exec_prefix)/lib -lz
> 
> The standard build options will already include the right -I and -L
> flags for this to Just Work.  I suggest we make the common case
> (Linux?) simple, and let others figure out what the right -I and -L
> flags are.  I submit that even if they /do/ have to handcraft -I and
> -L, the defaults in Setup.in are pretty meaningless.
> 
> A worthy change?  For 2.0 final?

Check it in right now.

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



From effbot at telia.com  Tue Oct  3 19:54:44 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Tue, 3 Oct 2000 19:54:44 +0200
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/test test_pty.py,1.4,1.5
References: <200010031651.JAA06853@slayer.i.sourceforge.net> <14810.5059.445654.876073@bitdiddle.concentric.net>
Message-ID: <005901c02d63$05cb5dc0$766940d5@hagrid>

> Thanks for taking care of this.  One nit on the checkin procedure,
> pleae reference the SF bug number when you're fixing a bug.  Also,
> report the revision number of the changed file when you close the bug.

do you really need both?  the former is easy, the latter is more
of a PITA, at least with the CVS setup I'm using here...

</F>




From guido at python.org  Tue Oct  3 20:58:20 2000
From: guido at python.org (Guido van Rossum)
Date: Tue, 03 Oct 2000 13:58:20 -0500
Subject: [Python-Dev] Small memory leak in unicodeobject.c
In-Reply-To: Your message of "Tue, 03 Oct 2000 12:34:51 -0400."
             <14810.2731.466997.243906@anthem.concentric.net> 
References: <14810.2731.466997.243906@anthem.concentric.net> 
Message-ID: <200010031858.NAA09564@cj20424-a.reston1.va.home.com>

> Index: unicodeobject.c
> ===================================================================
> RCS file: /cvsroot/python/python/dist/src/Objects/unicodeobject.c,v
> retrieving revision 2.64
> diff -u -r2.64 unicodeobject.c
> --- unicodeobject.c	2000/09/26 05:46:01	2.64
> +++ unicodeobject.c	2000/10/03 16:31:32
> @@ -5234,7 +5234,11 @@
>  	PyObject_DEL(v);
>      }
>      unicode_freelist = NULL;
> -    unicode_freelist_size = 0;
> +    /* XXX This is a hack to force the freeing of unicode_empty's memory.
> +     * Otherwise, it'll get placed on the already freed free list.
> +     */
> +    unicode_freelist_size = MAX_UNICODE_FREELIST_SIZE;
>      Py_XDECREF(unicode_empty);
>      unicode_empty = NULL;
> +    unicode_freelist_size = 0;
>  }

Doesn't it make more sense to decref unicode_empty sooner?  The loop
over the free list won't touch it:

Index: unicodeobject.c
===================================================================
RCS file: /cvsroot/python/python/dist/src/Objects/unicodeobject.c,v
retrieving revision 2.64
diff -c -r2.64 unicodeobject.c
*** unicodeobject.c	2000/09/26 05:46:01	2.64
--- unicodeobject.c	2000/10/03 17:55:34
***************
*** 5225,5230 ****
--- 5225,5232 ----
  {
      PyUnicodeObject *u = unicode_freelist;
  
+     Py_XDECREF(unicode_empty);
+     unicode_empty = NULL;
      while (u != NULL) {
  	PyUnicodeObject *v = u;
  	u = *(PyUnicodeObject **)u;
***************
*** 5235,5240 ****
      }
      unicode_freelist = NULL;
      unicode_freelist_size = 0;
-     Py_XDECREF(unicode_empty);
-     unicode_empty = NULL;
  }
--- 5237,5240 ----


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



From mal at lemburg.com  Tue Oct  3 20:02:39 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Tue, 03 Oct 2000 20:02:39 +0200
Subject: [Python-Dev] Small memory leak in unicodeobject.c
References: <14810.2731.466997.243906@anthem.concentric.net> <200010031858.NAA09564@cj20424-a.reston1.va.home.com>
Message-ID: <39DA1F3F.9EFA41EB@lemburg.com>

Guido van Rossum wrote:
> 
> > Index: unicodeobject.c
> > ===================================================================
> > RCS file: /cvsroot/python/python/dist/src/Objects/unicodeobject.c,v
> > retrieving revision 2.64
> > diff -u -r2.64 unicodeobject.c
> > --- unicodeobject.c   2000/09/26 05:46:01     2.64
> > +++ unicodeobject.c   2000/10/03 16:31:32
> > @@ -5234,7 +5234,11 @@
> >       PyObject_DEL(v);
> >      }
> >      unicode_freelist = NULL;
> > -    unicode_freelist_size = 0;
> > +    /* XXX This is a hack to force the freeing of unicode_empty's memory.
> > +     * Otherwise, it'll get placed on the already freed free list.
> > +     */
> > +    unicode_freelist_size = MAX_UNICODE_FREELIST_SIZE;
> >      Py_XDECREF(unicode_empty);
> >      unicode_empty = NULL;
> > +    unicode_freelist_size = 0;
> >  }
> 
> Doesn't it make more sense to decref unicode_empty sooner? 

Right. That's the change I proposed to Barry in my last mail.
Please check this in.

Thanks,
Marc-Andre

> The loop
> over the free list won't touch it:
> 
> Index: unicodeobject.c
> ===================================================================
> RCS file: /cvsroot/python/python/dist/src/Objects/unicodeobject.c,v
> retrieving revision 2.64
> diff -c -r2.64 unicodeobject.c
> *** unicodeobject.c     2000/09/26 05:46:01     2.64
> --- unicodeobject.c     2000/10/03 17:55:34
> ***************
> *** 5225,5230 ****
> --- 5225,5232 ----
>   {
>       PyUnicodeObject *u = unicode_freelist;
> 
> +     Py_XDECREF(unicode_empty);
> +     unicode_empty = NULL;
>       while (u != NULL) {
>         PyUnicodeObject *v = u;
>         u = *(PyUnicodeObject **)u;
> ***************
> *** 5235,5240 ****
>       }
>       unicode_freelist = NULL;
>       unicode_freelist_size = 0;
> -     Py_XDECREF(unicode_empty);
> -     unicode_empty = NULL;
>   }
> --- 5237,5240 ----
> 
> --Guido van Rossum (home page: http://www.python.org/~guido/)
> 
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://www.python.org/mailman/listinfo/python-dev

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From bwarsaw at beopen.com  Tue Oct  3 22:35:10 2000
From: bwarsaw at beopen.com (Barry A. Warsaw)
Date: Tue, 3 Oct 2000 16:35:10 -0400 (EDT)
Subject: [Python-Dev] Small memory leak in unicodeobject.c
References: <14810.2731.466997.243906@anthem.concentric.net>
	<39DA13C4.B1855D9A@lemburg.com>
Message-ID: <14810.17150.777092.128211@anthem.concentric.net>

>>>>> "M" == M  <mal at lemburg.com> writes:

    M> It would be easier to simply move the Py_DECREF() in front of
    M> the cleanup code for the free list. That way, unicode_empty
    M> would be placed on the free list, but then immedialtely cleaned
    M> up by the following code.

I know that's the obvious fix -- and it was the first thing I tried,
but it doesn't work!  (I thought I mentioned that in my original
message).

Verifying after a cvs up still shows unicode_empty leaking (I loop
through the Py_Initialize/Py_Finalize loop 10 times):

-------------------- snip snip --------------------
       240 bytes     10 chunks allocated at unicodeobject.c, 227
                          malloc()
                  _PyUnicode_New()  unicodeobject.c, 227
                 _PyUnicode_Init()  unicodeobject.c, 5217
                   Py_Initialize()  pythonrun.c, 125
                            main()
        30 bytes     10 chunks allocated at unicodeobject.c, 230
                          malloc()
                  _PyUnicode_New()  unicodeobject.c, 230
                 _PyUnicode_Init()  unicodeobject.c, 5217
                   Py_Initialize()  pythonrun.c, 125
                            main()
-------------------- snip snip --------------------

So let me step through the code and figure out what's wrong...

-Barry



From loewis at informatik.hu-berlin.de  Tue Oct  3 22:39:06 2000
From: loewis at informatik.hu-berlin.de (Martin von Loewis)
Date: Tue, 3 Oct 2000 22:39:06 +0200 (MET DST)
Subject: [Python-Dev] Release candidate followed by feature freeze?
Message-ID: <200010032039.WAA27659@pandora.informatik.hu-berlin.de>

> It would be hard to sell Python for important applications,
> e.g. long-running server processes, if there was a small possibility
> that the program could crash through no fault of its own.

There is always a small possibility that the program could crash
through no faults of its own - i.e. I don't believe that Python is bug
free without gc. I'd agree that bugs in the gc are more serious than
other bugs.

If it turns out that there are serious bugs in 2.0 (whether in the gc
or elsewhere), I'd hope BeOpen will release 2.0.1 shortly after they
get fixed.

Regards,
Martin



From bwarsaw at beopen.com  Tue Oct  3 22:42:25 2000
From: bwarsaw at beopen.com (Barry A. Warsaw)
Date: Tue, 3 Oct 2000 16:42:25 -0400 (EDT)
Subject: [Python-Dev] Small memory leak in unicodeobject.c
References: <14810.2731.466997.243906@anthem.concentric.net>
	<39DA13C4.B1855D9A@lemburg.com>
Message-ID: <14810.17585.567814.278594@anthem.concentric.net>

Oh the problem is obvious.  You have to initialize the local variable
`u' /after/ unicode_empty is freed otherwise it doesn't point to the
proper start of the free list.

I'll check that change in.
-Barry



From MarkH at ActiveState.com  Wed Oct  4 00:58:14 2000
From: MarkH at ActiveState.com (Mark Hammond)
Date: Wed, 4 Oct 2000 09:58:14 +1100
Subject: [Python-Dev] pep42 procedure?
Message-ID: <ECEPKNMJLHAPFFJHDOJBOEAJDMAA.MarkH@ActiveState.com>

Please excuse my ignorance...

I am in the process of applying the patch to prevent 1.5/1.6 extensions
crashing 2.0 under Windows.

Based on the feedback here (ie, "this should be a short term patch"), the
various other patches that try to do the same thing, and the belief by some
that we should be more like Unix anyway, I believe we should try and
capture this entire issue in a more formal manner.

The 2 logical places would be as a bug, and in pep42.  However, after
applying this patch, it doesnt really qualify as a bug!  Putting it in
pep42 is slightly suspect, as it is not a thought-out feature request yet -
however, I believe capturing it there, with links to the relevant patches
and discussions would be valuable.

So, assuming this sounds reasonable - a bug, or pep42?  If pep42, what is
the procedure for changing it?  I couldnt find it (or any pep) in the CVS
repository, and the source-force pages would show me the peps, but not
their source.  I do remember seeing this mentioned some time ago, but can't
locate that mail either...

Thanks,

Mark.




From trentm at ActiveState.com  Wed Oct  4 01:08:09 2000
From: trentm at ActiveState.com (Trent Mick)
Date: Tue, 3 Oct 2000 16:08:09 -0700
Subject: [Python-Dev] change to Lib/popen2.py break test_popen2 on windows
Message-ID: <20001003160809.A18387@ActiveState.com>

Fred's checkin:
http://www.python.org/pipermail/python-checkins/2000-September/008355.html
breaks test_popen2.py on windows.

This is because test_popen2.py attempts to refer to popen2's internal
'_active' variable, which is now explicitly deleted on Windows platforms.

test_popen2.py should be updated for the new popen2 semantics.


sorry-no-patch-ly yours,
Trent

-- 
Trent Mick
TrentM at ActiveState.com



From trentm at ActiveState.com  Wed Oct  4 01:10:09 2000
From: trentm at ActiveState.com (Trent Mick)
Date: Tue, 3 Oct 2000 16:10:09 -0700
Subject: [Python-Dev] change to Lib/popen2.py break test_popen2 on windows
In-Reply-To: <20001003160809.A18387@ActiveState.com>; from trentm@ActiveState.com on Tue, Oct 03, 2000 at 04:08:09PM -0700
References: <20001003160809.A18387@ActiveState.com>
Message-ID: <20001003161009.B18387@ActiveState.com>

On Tue, Oct 03, 2000 at 04:08:09PM -0700, Trent Mick wrote:
> 
> Fred's checkin:
> http://www.python.org/pipermail/python-checkins/2000-September/008355.html
> breaks test_popen2.py on windows.
> 
> This is because test_popen2.py attempts to refer to popen2's internal
> '_active' variable, which is now explicitly deleted on Windows platforms.
> 
> test_popen2.py should be updated for the new popen2 semantics.
> 

Geez, you are fast Tim! (for others: he patched test_popen.py after I sent my
email but before my email made it to python-dev!)


Trent


-- 
Trent Mick
TrentM at ActiveState.com



From skip at mojam.com  Wed Oct  4 02:54:55 2000
From: skip at mojam.com (Skip Montanaro)
Date: Tue, 3 Oct 2000 19:54:55 -0500 (CDT)
Subject: [Python-Dev] pep42 procedure?
In-Reply-To: <ECEPKNMJLHAPFFJHDOJBOEAJDMAA.MarkH@ActiveState.com>
References: <ECEPKNMJLHAPFFJHDOJBOEAJDMAA.MarkH@ActiveState.com>
Message-ID: <14810.32735.229954.547385@beluga.mojam.com>

    Mark> So, assuming this sounds reasonable - a bug, or pep42?  

I think neither.  This topic seems to have generated a lot of discussion.  I
think it deserves a bit more elaboration than what you'd find reasonable for
pep42.  Also, it would be kinda nice to add it to the Python FAQ with a
reference to a specific pep for all the gory details of the problem and
solution(s).

Skip



From MarkH at ActiveState.com  Wed Oct  4 05:58:25 2000
From: MarkH at ActiveState.com (Mark Hammond)
Date: Wed, 4 Oct 2000 14:58:25 +1100
Subject: [Python-Dev] pep42 procedure?
In-Reply-To: <14810.32735.229954.547385@beluga.mojam.com>
Message-ID: <ECEPKNMJLHAPFFJHDOJBAEBJDMAA.MarkH@ActiveState.com>

> I think neither.  This topic seems to have generated a lot of
> discussion.  I
> think it deserves a bit more elaboration than what you'd find
> reasonable for
> pep42.  Also, it would be kinda nice to add it to the Python FAQ with a
> reference to a specific pep for all the gory details of the problem and
> solution(s).

That would be a great idea, if only we had a PEP author.  To be honest, I
really dont care too much about this issue, and have been doing my level
best to avoid it.  But Tim knows that, and delights in assigning related
patches to me ;-)  I certainly don't care enough to own a pep on it.

The way things stand, I have a checkin ready to go, and am unwilling to
commit to any sort of pep in the short or medium term.  The best I could do
is to add links to the 3 or 4 other patches submitted for the same thing,
and pep42 seemed ideal.

So given this, what should I do - just check it in, and leave it to the
collective memory? ;-)

Mark.




From tim_one at email.msn.com  Wed Oct  4 06:58:46 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Wed, 4 Oct 2000 00:58:46 -0400
Subject: [Python-Dev] CIV
Message-ID: <LNBBLJKPBEHFEDALKOLCAEIDHJAA.tim_one@email.msn.com>

No, that's not 104, it's a Call for Indentation Volunteers!

An item that mistakenly got dropped on the floor before 2.0b1 was to ensure
that the standard Python libraries follow the recommended "4-space indents,
no hard tabs" guideline.  Since 100s of files (especially older ones in
oddball directories) are affected, I moved that it into PEP42 rather than
risk destabilizing the release after 2.0b1.

So it will happen instead soon after 2.0final is released.  I looked at
existing tools for doing this, and found they all left way too much manual
fiddling to bear,  too prone to screw up on comment lines (e.g., try running
your favorite tool over pindent.py:  does the output bear any resemblance to
the input?!  The Emacs pymode does OK there because pindent comments match
its conventions for "indenting comment lines", but nothing else even gets
close; OTOH,

    if 1:    # some insane people like
             # writing comments
             # like this too

and nobody knows what to do about that).

Attached is a new tool that tries much harder to get perverse comments right
(everything else is easy).  Try it and gripe at will.  Since I wrote it
while on vacation, it's public domain <0.5 wink>.

regularly y'rs  - tim

#! /usr/bin/env python

# Released to the public domain, by Tim Peters, 03 October 2000.

"""reindent [-d][-r][-v] path ...

-d  Dry run.  Analyze, but don't make any changes to, files.
-r  Recurse.  Search for all .py files in subdirectories too.
-v  Verbose.  Print informative msgs; else no output.

Change Python (.py) files to use 4-space indents and no hard tab characters.
Also trim excess whitespace from ends of lines, and empty lines at the ends
of files.  Ensure the last line ends with a newline.

Pass one or more file and/or directory paths.  When a directory path, all
.py files within the directory will be examined, and, if the -r option is
given, likewise recursively for subdirectories.

Overwrites files in place, renaming the originals with a .bak extension.
If reindent finds nothing to change, the file is left alone.  If reindent
does change a file, the changed file is a fixed-point for reindent (i.e.,
running reindent on the resulting .py file won't change it again).

The hard part of reindenting is figuring out what to do with comment
lines.  So long as the input files get a clean bill of health from
tabnanny.py, reindent should do a good job.
"""

import tokenize
import os
import sys

verbose = 0
recurse = 0
dryrun  = 0

def errprint(*args):
    sep = ""
    for arg in args:
        sys.stderr.write(sep + str(arg))
        sep = " "
    sys.stderr.write("\n")

def main():
    import getopt
    global verbose, recurse, dryrun
    try:
        opts, args = getopt.getopt(sys.argv[1:], "drv")
    except getopt.error, msg:
        errprint(msg)
        return
    for o, a in opts:
        if o == '-d':
            dryrun += 1
        elif o == '-r':
            recurse += 1
        elif o == '-v':
            verbose += 1
    if not args:
        errprint("Usage:", __doc__)
        return
    for arg in args:
        check(arg)

def check(file):
    if os.path.isdir(file) and not os.path.islink(file):
        if verbose:
            print "listing directory", file
        names = os.listdir(file)
        for name in names:
            fullname = os.path.join(file, name)
            if ((recurse and os.path.isdir(fullname) and
                 not os.path.islink(fullname))
                or name.lower().endswith(".py")):
                check(fullname)
        return

    if verbose:
        print "checking", file, "...",
    try:
        f = open(file)
    except IOError, msg:
        errprint("%s: I/O Error: %s" % (file, str(msg)))
        return

    r = Reindenter(f)
    f.close()
    if r.run():
        if verbose:
            print "changed."
            if dryrun:
                print "But this is a dry run, so leaving it alone."
        if not dryrun:
            bak = file + ".bak"
            if os.path.exists(bak):
                os.remove(bak)
            os.rename(file, bak)
            if verbose:
                print "renamed", file, "to", bak
            f = open(file, "w")
            r.write(f)
            f.close()
            if verbose:
                print "wrote new", file
    else:
        if verbose:
            print "unchanged."

class Reindenter:

    def __init__(self, f):
        self.find_stmt = 1  # next token begins a fresh stmt?
        self.level = 0      # current indent level

        # Raw file lines.
        self.raw = f.readlines()

        # File lines, rstripped & tab-expanded.  Dummy at start is so
        # that we can use tokenize's 1-based line numbering easily.
        # Note that a line is all-blank iff it's "\n".
        self.lines = [line.rstrip().expandtabs() + "\n"
                      for line in self.raw]
        self.lines.insert(0, None)
        self.index = 1  # index into self.lines of next line

        # List of (lineno, indentlevel) pairs, one for each stmt and
        # comment line.  indentlevel is -1 for comment lines, as a
        # signal that tokenize doesn't know what to do about them;
        # indeed, they're our headache!
        self.stats = []

    def run(self):
        tokenize.tokenize(self.getline, self.tokeneater)
        # Remove trailing empty lines.
        lines = self.lines
        while lines and lines[-1] == "\n":
            lines.pop()
        # Sentinel.
        stats = self.stats
        stats.append((len(lines), 0))
        # Map count of leading spaces to # we want.
        have2want = {}
        # Program after transformation.
        after = self.after = []
        for i in range(len(stats)-1):
            thisstmt, thislevel = stats[i]
            nextstmt = stats[i+1][0]
            have = getlspace(lines[thisstmt])
            want = thislevel * 4
            if want < 0:
                # A comment line.
                if have:
                    # An indented comment line.  If we saw the same
                    # indentation before, reuse what it most recently
                    # mapped to.
                    want = have2want.get(have, -1)
                    if want < 0:
                        # Then it probably belongs to the next real stmt.
                        for j in xrange(i+1, len(stats)-1):
                            jline, jlevel = stats[j]
                            if jlevel >= 0:
                                if have == getlspace(lines[jline]):
                                    want = jlevel * 4
                                break
                    if want < 0:           # Maybe it's a hanging
                                           # comment like this one,
                        # in which case we should shift it like its base
                        # line got shifted.
                        for j in xrange(i-1, -1, -1):
                            jline, jlevel = stats[j]
                            if jlevel >= 0:
                                want = have + getlspace(after[jline-1]) - \
                                       getlspace(lines[jline])
                                break
                    if want < 0:
                        # Still no luck -- leave it alone.
                        want = have
                else:
                    want = 0
            assert want >= 0
            have2want[have] = want
            diff = want - have
            if diff == 0 or have == 0:
                after.extend(lines[thisstmt:nextstmt])
            else:
                for line in lines[thisstmt:nextstmt]:
                    if diff > 0:
                        if line == "\n":
                            after.append(line)
                        else:
                            after.append(" " * diff + line)
                    else:
                        remove = min(getlspace(line), -diff)
                        after.append(line[remove:])
        return self.raw != self.after

    def write(self, f):
        f.writelines(self.after)

    # Line-getter for tokenize.
    def getline(self):
        if self.index >= len(self.lines):
            line = ""
        else:
            line = self.lines[self.index]
            self.index += 1
        return line

    # Line-eater for tokenize.
    def tokeneater(self, type, token, (sline, scol), end, line,
                   INDENT=tokenize.INDENT,
                   DEDENT=tokenize.DEDENT,
                   NEWLINE=tokenize.NEWLINE,
                   COMMENT=tokenize.COMMENT,
                   NL=tokenize.NL):

        if type == NEWLINE:
            # A program statement, or ENDMARKER, will eventually follow,
            # after some (possibly empty) run of tokens of the form
            #     (NL | COMMENT)* (INDENT | DEDENT+)?
            self.find_stmt = 1

        elif type == INDENT:
            self.find_stmt = 1
            self.level += 1

        elif type == DEDENT:
            self.find_stmt = 1
            self.level -= 1

        elif type == COMMENT:
            if self.find_stmt:
                self.stats.append((sline, -1))
                # but we're still looking for a new stmt, so leave
                # find_stmt alone

        elif type == NL:
            pass

        elif self.find_stmt:
            # This is the first "real token" following a NEWLINE, so it
            # must be the first token of the next program statement, or an
            # ENDMARKER.
            self.find_stmt = 0
            if line:   # not endmarker
                self.stats.append((sline, self.level))

# Count number of leading blanks.
def getlspace(line):
    i, n = 0, len(line)
    while i < n and line[i] == " ":
        i += 1
    return i

if __name__ == '__main__':
    main()





From bwarsaw at beopen.com  Wed Oct  4 08:06:14 2000
From: bwarsaw at beopen.com (Barry A. Warsaw)
Date: Wed, 4 Oct 2000 02:06:14 -0400 (EDT)
Subject: [Python-Dev] pep42 procedure?
References: <ECEPKNMJLHAPFFJHDOJBOEAJDMAA.MarkH@ActiveState.com>
Message-ID: <14810.51414.59852.855231@anthem.concentric.net>

>>>>> "MH" == Mark Hammond <MarkH at ActiveState.com> writes:

    MH> I couldnt find it (or any pep) in the CVS repository, and the
    MH> source-force pages would show me the peps, but not their
    MH> source.

The PEPs are located in the nondist directory, under nondist/peps!

-Barry



From bwarsaw at beopen.com  Wed Oct  4 08:07:06 2000
From: bwarsaw at beopen.com (Barry A. Warsaw)
Date: Wed, 4 Oct 2000 02:07:06 -0400 (EDT)
Subject: [Python-Dev] forwarded message from aahz@panix.com
Message-ID: <14810.51466.486982.938180@anthem.concentric.net>

An embedded message was scrubbed...
From: aahz at panix.com
Subject: htmllib.HTMLescape()
Date: Tue, 3 Oct 2000 16:26:32 -0700 (PDT)
Size: 1672
URL: <http://mail.python.org/pipermail/python-dev/attachments/20001004/159fd0b6/attachment-0001.eml>

From thomas at xs4all.net  Wed Oct  4 08:16:58 2000
From: thomas at xs4all.net (Thomas Wouters)
Date: Wed, 4 Oct 2000 08:16:58 +0200
Subject: [Python-Dev] pep42 procedure?
In-Reply-To: <ECEPKNMJLHAPFFJHDOJBAEBJDMAA.MarkH@ActiveState.com>; from MarkH@ActiveState.com on Wed, Oct 04, 2000 at 02:58:25PM +1100
References: <14810.32735.229954.547385@beluga.mojam.com> <ECEPKNMJLHAPFFJHDOJBAEBJDMAA.MarkH@ActiveState.com>
Message-ID: <20001004081658.E12812@xs4all.nl>

On Wed, Oct 04, 2000 at 02:58:25PM +1100, Mark Hammond wrote:

[ Mark wants to apply a patch that prevents crashes on windows when loading
extentions linked with old Python DLLs, but doesn't know where to document
it: PEP 42 or the bug report(s) ]

[ Skip proposes a separate PEP ]

[ Mark doesn't have time to write a PEP ]

> So given this, what should I do - just check it in, and leave it to the
> collective memory? ;-)

PEP 42 is the meaning of life PEP, meaning that it's everything that needs
to be done before python-dev can rest in pieces. I don't think that a solved
issue is in its place there, even if it had such a section. A PEP on its own
would probably be the best spot, because even if it's a 'temporary' solution
now, we or someone else might need the info later. And a PEP doesn't have to
be that hard to write ;)

And besides, you don't have to be the person to write the PEP, someone else
can. And if noone suitable volunteers, perhaps a checkin-message giving
'full' documentation, the necessary sourcecode comments and a reference to
both in the bugreport message will suffice... But I'm willing to PEPify
whatever docs or comments you write on this issue, Mark. I will need some
guidance on what exactly is the issue, but I'm sure I'll get that from one
of you Windows lovers ! :-)

And no, I don't think Python should be more like UNIX. Windows, yes, but
it's not Python's job to turn Windows into a halfhearted UNIX ;-P Besides,
that would only alienate the Windows users with Uni(x)fobia.

Unix-unix-unix-ly y'rs,

-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!



From ping at lfw.org  Wed Oct  4 13:02:51 2000
From: ping at lfw.org (Ka-Ping Yee)
Date: Wed, 4 Oct 2000 04:02:51 -0700 (PDT)
Subject: [Python-Dev] Installing python in /usr/bin
Message-ID: <Pine.LNX.4.10.10010040357390.4474-100000@skuld.kingmanhall.org>

The cgi.py discussion brought my attention to this comment from Guido:

> No, no, no!  The /usr/bin/env form *fails* on most platforms (except
> Linux) because Python is not installed in any of the default "bin"
> directories -- /usr/local/bin is the standard install place and that's
> not in the default path.

So the natural question to ask is -- why not install Python in /usr/bin
like everyone else?

Perhaps a while ago Python wasn't popular enough to belong in /usr/bin
and decided to modestly stay out of the way in /usr/local/bin instead?

But by now, i think it's quite qualified to take its seat in /usr/bin
along with all the other standard Unix binaries like /usr/bin/vi,
/usr/bin/ftp, /usr/bin/perl, etc.  Python *should* be in the default
binary directory.

Your thoughts?


-- ?!ng




From thomas at xs4all.net  Wed Oct  4 13:35:28 2000
From: thomas at xs4all.net (Thomas Wouters)
Date: Wed, 4 Oct 2000 13:35:28 +0200
Subject: [Python-Dev] Installing python in /usr/bin
In-Reply-To: <Pine.LNX.4.10.10010040357390.4474-100000@skuld.kingmanhall.org>; from ping@lfw.org on Wed, Oct 04, 2000 at 04:02:51AM -0700
References: <Pine.LNX.4.10.10010040357390.4474-100000@skuld.kingmanhall.org>
Message-ID: <20001004133528.G12812@xs4all.nl>

On Wed, Oct 04, 2000 at 04:02:51AM -0700, Ka-Ping Yee wrote:

> So the natural question to ask is -- why not install Python in /usr/bin
> like everyone else?

> Perhaps a while ago Python wasn't popular enough to belong in /usr/bin
> and decided to modestly stay out of the way in /usr/local/bin instead?

The only reason is the hysterical one: it's always been that way.
Traditionally, /usr/local/bin was the place for user-installed binaries.
This sets them apart from the the vendor-supplied binaries (commonly in /bin
and /usr/bin, where /bin are the tools necessary to boot and mount /usr, and
/usr/bin is the rest) and the vendor-installed 3rd-party binaries (commonly
in /usr/contrib/bin, or /opt/bin, or /opt/gnu/bin, and the like.)

> But by now, i think it's quite qualified to take its seat in /usr/bin
> along with all the other standard Unix binaries like /usr/bin/vi,
> /usr/bin/ftp, /usr/bin/perl, etc.  Python *should* be in the default
> binary directory.

Perl only resides in /usr/bin if the vendor (or distribution-maker, in the
case of the Free OSes) put it there. The default for Perl is /usr/local as
well. In fact, almost all source packages default to /usr/local; I have yet
to see a package that uses autoconf and does not have /usr/local as the
default prefix, for instance.

I think the best solution is just for every OS to put /usr/local/bin in
their path, and not pretend they delivered the Definitive Collection of
Useful Programs. Installing Python in /usr can do more damage than good --
think of all the people that are used to have it installed in /usr/local,
don't specify a prefix because they 'know' it's /usr/local by default, and
end up filling up their minimal /usr partition with Python ;)

-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!



From gward at python.net  Tue Oct  3 06:08:45 2000
From: gward at python.net (Greg Ward)
Date: Tue, 3 Oct 2000 00:08:45 -0400
Subject: [Python-Dev] ANNOUNCE: Distutils 1.0
Message-ID: <mailman.970578302.4920.clpa-moderators@python.org>

                     Python Distribution Utilities
                              release 1.0
                            October 2, 2000

The Python Distribution Utilities, or Distutils for short, are a
collection of modules that aid in the development, distribution, and
installation of Python modules.  (It is intended that ultimately the
Distutils will grow up into a system for distributing and installing
whole Python applications, but for now their scope is limited to module
distributions.)

The Distutils are a standard part of Python 1.6 and 2.0; if you are running
1.6 or 2.0, you don't need to install the Distutils separately.  (However,
you might want to upgrade if you're running Python 1.6.)  This release is
primarily so that you can add the Distutils to a Python 1.5.2 installation
-- you will then be able to install modules that require the Distutils, or
use the Distutils to distribute your own modules.

Distutils 1.0 is the version that will be released with Python 2.0 (unless
last-minute bugs pop up).

More information is available at the Distutils web page:

    http://www.python.org/sigs/distutils-sig/

and in the README.txt included in the Distutils source distribution.

You can download the Distutils from

    http://www.python.org/sigs/distutils-sig/download.html

Trivial patches can be sent to me (Greg Ward) at gward at python.net.
Larger patches should be discussed on the Distutils mailing list:
distutils-sig at python.org.

        Greg
-- 
Greg Ward                                      gward at python.net
http://starship.python.net/~gward/
And now for something completely different.




From bwarsaw at beopen.com  Wed Oct  4 15:44:40 2000
From: bwarsaw at beopen.com (Barry A. Warsaw)
Date: Wed, 4 Oct 2000 09:44:40 -0400 (EDT)
Subject: [Python-Dev] Installing python in /usr/bin
References: <Pine.LNX.4.10.10010040357390.4474-100000@skuld.kingmanhall.org>
	<20001004133528.G12812@xs4all.nl>
Message-ID: <14811.13384.137080.196973@anthem.concentric.net>

>>>>> "TW" == Thomas Wouters <thomas at xs4all.net> writes:

    TW> The only reason is the hysterical one: it's always been that
    TW> way.  Traditionally, /usr/local/bin was the place for
    TW> user-installed binaries.

Yes exactly.

And in fact on my RH6.1 system, I have Python in both /usr/bin and
/usr/local/bin.  RedHat sticks its rpms in /usr/bin, and right now,
1.5.2 resides there.  My dev copy gets installed from source into
/usr/local/bin, and that's the current CVS snapshot.  This is as it
should be and all is right in the world.

The rule is -- and ought to be -- that the default install location in
a build-from-source distro is /usr/local.  rpms or other package
installs can install where ever is appropriate for that platform
(e.g. if someone were to build a Solaris pkg distro, it probably ought
to install to /opt by default).

if-it-ain't-broke...-ly y'rs,
-Barry



From nas at arctrix.com  Wed Oct  4 11:46:36 2000
From: nas at arctrix.com (Neil Schemenauer)
Date: Wed, 4 Oct 2000 02:46:36 -0700
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules cPickle.c,2.52,2.53
In-Reply-To: <200010041622.JAA17363@slayer.i.sourceforge.net>; from nascheme@users.sourceforge.net on Wed, Oct 04, 2000 at 09:22:31AM -0700
References: <200010041622.JAA17363@slayer.i.sourceforge.net>
Message-ID: <20001004024636.A13475@glacier.fnational.com>

On Wed, Oct 04, 2000 at 09:22:31AM -0700, Neil Schemenauer wrote:
> Update of /cvsroot/python/python/dist/src/Modules
> In directory slayer.i.sourceforge.net:/tmp/cvs-serv16887/Modules
> 
> Modified Files:
> 	cPickle.c 
> Log Message:
> - Fix a GC bug caused by PyDict_New() failing.
> 
> 
> Index: cPickle.c
> ===================================================================
> RCS file: /cvsroot/python/python/dist/src/Modules/cPickle.c,v
> retrieving revision 2.52
> retrieving revision 2.53
> diff -C2 -r2.52 -r2.53
> *** cPickle.c	2000/09/07 14:35:37	2.52
> --- cPickle.c	2000/10/04 16:22:26	2.53
> ***************
> *** 2876,2880 ****
>                 Py_INCREF(cls);
>                 UNLESS (inst->in_dict=PyDict_New()) {
> !                 Py_DECREF(inst);
>                   goto err;
>                 }
> --- 2876,2881 ----
>                 Py_INCREF(cls);
>                 UNLESS (inst->in_dict=PyDict_New()) {
> !                 inst = (PyInstanceObject *) PyObject_AS_GC(inst);
> !                 PyObject_DEL(inst);
>                   goto err;
>                 }

I aways seem to think harder when reviewing a commit message than
a diff. :(  I just realized that this commit subtly modifies
cPickle's behavior.  Before the change instances __del__ methods
would be called if allocating __dict__ failed.  After the change
they are not.  I think the new behavior is better but the
question is will it break existing code?  I think probably not.

BTW, pickle seems to follow the new behavior.

  Neil



From esr at snark.thyrsus.com  Wed Oct  4 19:17:39 2000
From: esr at snark.thyrsus.com (Eric S. Raymond)
Date: Wed, 4 Oct 2000 13:17:39 -0400
Subject: [Python-Dev] Proposal -- makefile patches and scripts to generate python RPMs
Message-ID: <200010041717.NAA03509@snark.thyrsus.com>

In the course of maintaining fetchmail, I've developed effective
techniques for integrating RPM and lsm generation into the release machinery
of a package.  I'm willing to do this for Python; it will involve
adding a makefile production and a couple of scripts to the
distribution.

The benefit would be that we could generate correct RPMs automatically
and ship them with each release.  I think RPM is a sufficiently
important distribution format to justify this effort.  Comments?
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

The prestige of government has undoubtedly been lowered considerably
by the Prohibition law. For nothing is more destructive of respect for
the government and the law of the land than passing laws which cannot
be enforced. It is an open secret that the dangerous increase of crime
in this country is closely connected with this.
	-- Albert Einstein, "My First Impression of the U.S.A.", 1921



From effbot at telia.com  Wed Oct  4 19:25:37 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Wed, 4 Oct 2000 19:25:37 +0200
Subject: [Python-Dev] Proposal -- makefile patches and scripts to generate python RPMs
References: <200010041717.NAA03509@snark.thyrsus.com>
Message-ID: <002c01c02e28$1dc20d00$766940d5@hagrid>

eric wrote:
> In the course of maintaining fetchmail, I've developed effective
> techniques for integrating RPM and lsm generation into the release machinery
> of a package.  I'm willing to do this for Python; it will involve
> adding a makefile production and a couple of scripts to the
> distribution.
> 
> The benefit would be that we could generate correct RPMs automatically
> and ship them with each release.  I think RPM is a sufficiently
> important distribution format to justify this effort.  Comments?

isn't this a distutils thing?  see:

ftp://python.beopen.com/pub/docco/devel/dist/creating-rpms.html

(lazy programmers just press the "deploy" button, of course ;-)

</F>




From akuchlin at mems-exchange.org  Wed Oct  4 20:02:19 2000
From: akuchlin at mems-exchange.org (Andrew Kuchling)
Date: Wed, 4 Oct 2000 14:02:19 -0400
Subject: [Python-Dev] Proposal -- makefile patches and scripts to generate python RPMs
In-Reply-To: <002c01c02e28$1dc20d00$766940d5@hagrid>; from effbot@telia.com on Wed, Oct 04, 2000 at 07:25:37PM +0200
References: <200010041717.NAA03509@snark.thyrsus.com> <002c01c02e28$1dc20d00$766940d5@hagrid>
Message-ID: <20001004140219.A5125@kronos.cnri.reston.va.us>

On Wed, Oct 04, 2000 at 07:25:37PM +0200, Fredrik Lundh wrote:
>isn't this a distutils thing?  see:
>ftp://python.beopen.com/pub/docco/devel/dist/creating-rpms.html
>(lazy programmers just press the "deploy" button, of course ;-)

It's not immediately obvious that the Distutils 1.0, which after all
mostly aims to support installing Python modules, can be applied to
installing Python itself, what with all the libraries and scripts and
such that Python needs.  It certainly is something to aim for, and I
intend to work on this some more after 2.0, but the attempt might run
into missing Distutil features.  Whether it's worth adding rules for
RPM in the meantime is up to the Pythoneers; I'm 0 on it.  (Not +0 or
-0, just 0 -- a Nirvana-like state of utter unconcern.)

--amk




From gward at mems-exchange.org  Wed Oct  4 20:13:01 2000
From: gward at mems-exchange.org (Greg Ward)
Date: Wed, 4 Oct 2000 14:13:01 -0400
Subject: [Python-Dev] Proposal -- makefile patches and scripts to generate python RPMs
In-Reply-To: <002c01c02e28$1dc20d00$766940d5@hagrid>; from effbot@telia.com on Wed, Oct 04, 2000 at 07:25:37PM +0200
References: <200010041717.NAA03509@snark.thyrsus.com> <002c01c02e28$1dc20d00$766940d5@hagrid>
Message-ID: <20001004141301.A31167@ludwig.cnri.reston.va.us>

On 04 October 2000, Fredrik Lundh said:
> isn't this a distutils thing?  see:
> 
> ftp://python.beopen.com/pub/docco/devel/dist/creating-rpms.html

But the Distutils brag line is:

  The Python Distribution Utilities, or Distutils for short, are a
  collection of modules that aid in the development, distribution, and
  installation of Python modules.

If that first sentence were instead

  The Python Distribution Utilities, or Distutils for short, are a
  collection of modules that aid in the development, distribution, and
  installation of Python.

then you'd have a point.

What a difference one little word can make...

        Greg



From gward at mems-exchange.org  Wed Oct  4 20:16:20 2000
From: gward at mems-exchange.org (Greg Ward)
Date: Wed, 4 Oct 2000 14:16:20 -0400
Subject: [Python-Dev] Adding a section to PEP 0042
Message-ID: <20001004141620.A31293@ludwig.cnri.reston.va.us>

I need to add an entry to PEP 0042 about the lack of cross-compilation
support, because that's a bug report that was assigned to me, and needs
to be marked "Closed/Feature Request/Later" and put in PEP 0042.  Seems
to me that I should just add a section on "Build/Installation" to the
PEP -- anyone disagree?  This might also be a good place to gather
other gripes about Python's build/installation machinery...

        Greg
-- 
Greg Ward - software developer                gward at mems-exchange.org
MEMS Exchange / CNRI                           voice: +1-703-262-5376
Reston, Virginia, USA                            fax: +1-703-262-5367



From effbot at telia.com  Wed Oct  4 20:53:48 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Wed, 4 Oct 2000 20:53:48 +0200
Subject: [Python-Dev] Proposal -- makefile patches and scripts to generate python RPMs
References: <200010041717.NAA03509@snark.thyrsus.com> <002c01c02e28$1dc20d00$766940d5@hagrid> <20001004141301.A31167@ludwig.cnri.reston.va.us>
Message-ID: <007901c02e34$81e32ce0$766940d5@hagrid>

greg wrote:
> If that first sentence were instead
> 
>   The Python Distribution Utilities, or Distutils for short, are a
>   collection of modules that aid in the development, distribution, and
>   installation of Python.
> 
> then you'd have a point.
> 
> What a difference one little word can make...

so why not fix it?  cannot be too hard to remove one
little word, can it? ;-)

</F>




From loewis at informatik.hu-berlin.de  Wed Oct  4 22:31:23 2000
From: loewis at informatik.hu-berlin.de (Martin von Loewis)
Date: Wed, 4 Oct 2000 22:31:23 +0200 (MET DST)
Subject: [Python-Dev] htmllib.HTMLescape()
Message-ID: <200010042031.WAA17378@pandora.informatik.hu-berlin.de>

> Someone just pointed out on c.l.py that we need an HTMLescape()
> function that takes a string and converts special characters to
> entities.  I'm not on python-dev, so could you please forward this
> and find out whether I need to run a PEP?

Doesn't xml.sax.saxutils.escape do what you want (together with
htmlentitydefs)? I was going to say that this is quite a small change
to warrant a PEP - but there are two obvious approaches (working from
scratch, or working on top of xml.sax.saxutils.escape - perhaps
modifying and relocating that function), so *some* design probably
needs to be recorded in a PEP.

Regards,
Martin



From trentm at ActiveState.com  Wed Oct  4 23:17:37 2000
From: trentm at ActiveState.com (Trent Mick)
Date: Wed, 4 Oct 2000 14:17:37 -0700
Subject: [Python-Dev] test_sre.py fails on Win64 because PyOS_CheckStack *never* fails
Message-ID: <20001004141737.A16659@ActiveState.com>

I did not follow the discussion a while back regarding the implementation and
use of PyOS_CheckStack on Windows. In any case, its use (USE_STACKCHECK)
instead of recursion limit checking (USE_RECURSION_LIMIT) in _sre.c results
in this test:
    test(r"""sre.match(r'(x)*', 50000*'x').span()""", (0, 50000), RuntimeError)
in test_sre.py failing on Win64.


This is because PyOS_CheckStack seem to *never* fail on Win64. Three
possibilites:
  (1) I don't understand the PyOS_CheckStack code or I am misintepreting the
      problem.
  (2) The semantics of _alloca() has changed for Win64 such that a stack
      overflow exception is no longer thrown if space cannot be allocated.
      NOTE: I changed the number of pointers allocated in PyOS_CheckStack
            from 2048 to over 1 *Tera*byte and it *still* did not fail.
  (3) I am stoopid.


In any case, I would like to *not* define USE_STACKCHECK on Win64 for the
time being (and for 2.0, unless a Win64 angel comes to me in the next couple
of days). Does anybody have a problem with me checking this in?

*** Include\pythonrun.h~     Wed Oct 04 14:18:00 2000
--- Include\pythonrun.h      Wed Oct 04 13:17:17 2000
***************
*** 88,94 ****
     to a 8k margin. */
  #define PYOS_STACK_MARGIN 2048

! #if defined(WIN32) && defined(_MSC_VER)
  /* Enable stack checking under Microsoft C */
  #define USE_STACKCHECK
  #endif
--- 88,94 ----
     to a 8k margin. */
  #define PYOS_STACK_MARGIN 2048

! #if defined(WIN32) && !defined(MS_WIN64) && defined(_MSC_VER)
  /* Enable stack checking under Microsoft C */
  #define USE_STACKCHECK
  #endif


Thanks,
Trent

-- 
Trent Mick
TrentM at ActiveState.com



From effbot at telia.com  Wed Oct  4 23:34:50 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Wed, 4 Oct 2000 23:34:50 +0200
Subject: [Python-Dev] test_sre.py fails on Win64 because PyOS_CheckStack *never* fails
References: <20001004141737.A16659@ActiveState.com>
Message-ID: <000701c02e4a$edf6b580$766940d5@hagrid>

trent wrote:
> I did not follow the discussion a while back regarding the implementation and
> use of PyOS_CheckStack on Windows. In any case, its use (USE_STACKCHECK)
> instead of recursion limit checking (USE_RECURSION_LIMIT) in _sre.c results
> in this test:
>     test(r"""sre.match(r'(x)*', 50000*'x').span()""", (0, 50000), RuntimeError)
> in test_sre.py failing on Win64.

note that the test assumes that 50000 iterations would be
enough to hit the stack limit.  maybe Win64 has a *huge*
stack?

what does this little program do:

    import sre
    sre.match(r'(x)*', 50000*'x').span()

if it prints (0, 50000), all is well, and the *test* should be
disabled (or modified) on Win64...

</F>




From jeremy at beopen.com  Wed Oct  4 23:35:26 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Wed, 4 Oct 2000 17:35:26 -0400 (EDT)
Subject: [Python-Dev] Proposal -- makefile patches and scripts to generate python RPMs
In-Reply-To: <200010041717.NAA03509@snark.thyrsus.com>
References: <200010041717.NAA03509@snark.thyrsus.com>
Message-ID: <14811.41630.554137.351253@bitdiddle.concentric.net>

>>>>> "ESR" == Eric S Raymond <esr at snark.thyrsus.com> writes:

  ESR> In the course of maintaining fetchmail, I've developed
  ESR> effective techniques for integrating RPM and lsm generation
  ESR> into the release machinery of a package.  I'm willing to do
  ESR> this for Python; it will involve adding a makefile production
  ESR> and a couple of scripts to the distribution.

  ESR> The benefit would be that we could generate correct RPMs
  ESR> automatically and ship them with each release.  I think RPM is
  ESR> a sufficiently important distribution format to justify this
  ESR> effort.  Comments?

We are now distributing RPMs for RH 6 with Python and have plans to
support other distributions we have access to, namely those available
on the SF compile farm.

This page has the RPMs:
http://www.pythonlabs.com/products/python2.0/download_python2.0b2.html

Can you compare this approach to using a hand-crafted .spec file for
the RPMs?  It took a little while to figure out how to generate the
.spec, but now that it has been created it does not seem hard to
maintain.

I imagine, without knowing any details of what you propose, that this
is primarily beneficial for people who do not know how to build RPMs.

Jeremy




From effbot at telia.com  Wed Oct  4 23:43:41 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Wed, 4 Oct 2000 23:43:41 +0200
Subject: [Python-Dev] test_sre.py fails on Win64 because PyOS_CheckStack *never* fails
References: <20001004141737.A16659@ActiveState.com>
Message-ID: <000b01c02e4c$2ac63980$766940d5@hagrid>

trent wrote:
> This is because PyOS_CheckStack seem to *never* fail on Win64. Three
> possibilites:
>   (1) I don't understand the PyOS_CheckStack code or I am misintepreting the
>       problem.
>   (2) The semantics of _alloca() has changed for Win64 such that a stack
>       overflow exception is no longer thrown if space cannot be allocated.
>       NOTE: I changed the number of pointers allocated in PyOS_CheckStack
>             from 2048 to over 1 *Tera*byte and it *still* did not fail.

me again: didn't read the note carefully enough, so I didn't
quite figure out what you said...

:::

what happens if you run this program (on my win95 box, it
counts up to 8, and stops).

#include <malloc.h>
#include <excpt.h>

int __inline
PyOS_CheckStack()
{
    __try {
        _alloca(100000);
        return 0;
    } __except (EXCEPTION_EXECUTE_HANDLER) {
        /* just ignore all errors */
    }
    return 1;
}

void
callme(int i)
{
    char buf[100000];
    if (PyOS_CheckStack())
        return;
    printf("%d\n", i);
    memset(buf, 0, sizeof buf);
    callme(i+1);
}

int
main()
{
    callme(0);
}

:::

if it goes on and on and on, check the assembler output from
this program.

(maybe the win64 compiler is smarter than I -- if it realizes that I
don't actually use the return value from _alloca, it may of course
remove the entire thing...)

</F>




From esr at thyrsus.com  Wed Oct  4 23:56:38 2000
From: esr at thyrsus.com (Eric S. Raymond)
Date: Wed, 4 Oct 2000 17:56:38 -0400
Subject: [Python-Dev] Proposal -- makefile patches and scripts to generate python RPMs
In-Reply-To: <14811.41630.554137.351253@bitdiddle.concentric.net>; from jeremy@beopen.com on Wed, Oct 04, 2000 at 05:35:26PM -0400
References: <200010041717.NAA03509@snark.thyrsus.com> <14811.41630.554137.351253@bitdiddle.concentric.net>
Message-ID: <20001004175638.A4423@thyrsus.com>

Jeremy Hylton <jeremy at beopen.com>:
> We are now distributing RPMs for RH 6 with Python and have plans to
> support other distributions we have access to, namely those available
> on the SF compile farm.
> 
> This page has the RPMs:
> http://www.pythonlabs.com/products/python2.0/download_python2.0b2.html
> 
> Can you compare this approach to using a hand-crafted .spec file for
> the RPMs?  It took a little while to figure out how to generate the
> .spec, but now that it has been created it does not seem hard to
> maintain.
> 
> I imagine, without knowing any details of what you propose, that this
> is primarily beneficial for people who do not know how to build RPMs.

Actually, the point of my approach is *not* to hand-craft the spec file.
What I normally do is write a specfile generator script in shell, which
takes the release version as an argument.  Most of the point of the generator
script is so the file list part of the specfile never has to be handhacked.

So, for example, a specfile generator script for Python would know that for
each library file foo.py in the Python X.Y release tree, it needs to generate 
a file entry /usr/lib/pythonX.Y/foo.py -- that way whenever a module is
added to the library it will automatically ripple through to the RPM.

Then I embed something like this in the Makefile:

# Make RPMs.  You need to be root to make this work
RPMROOT=/usr/src/redhat
RPM = rpm
RPMFLAGS = -ba
rpm: dist
	cp foo-$(VERSION).tar.gz foo.xpm $(RPMROOT)/SOURCES;
	$(srcdir)/specgen.sh $(VERSION) >$(RPMROOT)/SPECS/foo.spec
	cd $(RPMROOT)/SPECS; $(RPM) $(RPMFLAGS) foo.spec	
	cp $(RPMROOT)/RPMS/`arch|sed 's/i[4-9]86/i386/'`/foo*-$(VERSION)*.rpm $(srcdir)
	cp $(RPMROOT)/SRPMS/foo*-$(VERSION)*.src.rpm $(srcdir)

Hey presto!  Instant RPMs.  I use this approach for several of my projects.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

The most foolish mistake we could possibly make would be to permit 
the conquered Eastern peoples to have arms.  History teaches that all 
conquerors who have allowed their subject races to carry arms have 
prepared their own downfall by doing so.
        -- Hitler, April 11 1942, revealing the real agenda of "gun control"



From nas at arctrix.com  Wed Oct  4 18:12:04 2000
From: nas at arctrix.com (Neil Schemenauer)
Date: Wed, 4 Oct 2000 09:12:04 -0700
Subject: [Python-Dev] Proposal -- makefile patches and scripts to generate python RPMs
In-Reply-To: <20001004175638.A4423@thyrsus.com>; from esr@thyrsus.com on Wed, Oct 04, 2000 at 05:56:38PM -0400
References: <200010041717.NAA03509@snark.thyrsus.com> <14811.41630.554137.351253@bitdiddle.concentric.net> <20001004175638.A4423@thyrsus.com>
Message-ID: <20001004091204.A787@glacier.fnational.com>

On Wed, Oct 04, 2000 at 05:56:38PM -0400, Eric S. Raymond wrote:
> Jeremy Hylton <jeremy at beopen.com>:
> > Can you compare this approach to using a hand-crafted .spec file for
> > the RPMs?  It took a little while to figure out how to generate the
> > .spec, but now that it has been created it does not seem hard to
> > maintain.
> Actually, the point of my approach is *not* to hand-craft the spec file.

Okay, but we already have the spec file.  Why is your approach
better?  Is your script that generates the the spec easier to
maintain then the spec file itself?  Is it just as flexible?  If
so then Red Hat screwed up designing RPM.  I can see the utility
of such as script but I don't see how it helps in this situation.

  Neil



From esr at thyrsus.com  Thu Oct  5 04:23:18 2000
From: esr at thyrsus.com (Eric S. Raymond)
Date: Wed, 4 Oct 2000 22:23:18 -0400
Subject: [Python-Dev] Proposal -- makefile patches and scripts to generate python RPMs
In-Reply-To: <20001004091204.A787@glacier.fnational.com>; from nas@arctrix.com on Wed, Oct 04, 2000 at 09:12:04AM -0700
References: <200010041717.NAA03509@snark.thyrsus.com> <14811.41630.554137.351253@bitdiddle.concentric.net> <20001004175638.A4423@thyrsus.com> <20001004091204.A787@glacier.fnational.com>
Message-ID: <20001004222318.E4742@thyrsus.com>

Neil Schemenauer <nas at arctrix.com>:
> On Wed, Oct 04, 2000 at 05:56:38PM -0400, Eric S. Raymond wrote:
> > Jeremy Hylton <jeremy at beopen.com>:
> > > Can you compare this approach to using a hand-crafted .spec file for
> > > the RPMs?  It took a little while to figure out how to generate the
> > > .spec, but now that it has been created it does not seem hard to
> > > maintain.
> > Actually, the point of my approach is *not* to hand-craft the spec file.
> 
> Okay, but we already have the spec file.  Why is your approach
> better?  Is your script that generates the the spec easier to
> maintain then the spec file itself?  Is it just as flexible?  If
> so then Red Hat screwed up designing RPM.  I can see the utility
> of such as script but I don't see how it helps in this situation.

The main thing a specfile generator can accomplish is to automate the
generation of the file list so that (for example) when we add a new
library module the specfile doesn't have to be hand-edited.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

"Guard with jealous attention the public liberty.  Suspect every one
who approaches that jewel.  Unfortunately, nothing will preserve it
but downright force.  Whenever you give up that force, you are
inevitably ruined."
	-- Patrick Henry, speech of June 5 1788



From nas at arctrix.com  Wed Oct  4 23:43:50 2000
From: nas at arctrix.com (Neil Schemenauer)
Date: Wed, 4 Oct 2000 14:43:50 -0700
Subject: [Python-Dev] Release candidate followed by feature freeze?
In-Reply-To: <200010030236.VAA02702@cj20424-a.reston1.va.home.com>; from guido@python.org on Mon, Oct 02, 2000 at 09:36:03PM -0500
References: <200010011913.VAA01107@pandora.informatik.hu-berlin.de> <200010021919.OAA01232@cj20424-a.reston1.va.home.com> <20001002044859.A9639@glacier.fnational.com> <200010030236.VAA02702@cj20424-a.reston1.va.home.com>
Message-ID: <20001004144350.A434@glacier.fnational.com>

On Mon, Oct 02, 2000 at 09:36:03PM -0500, Guido van Rossum wrote:
> Hooft's problem makes heavy use of Tkinter and Pmw, it seems.  Maybe
> that's a clue?

Rob was kind enough to send me some code to trigger the bug.  The
winner is ... tupleobject.c!  When MAXSAVESIZE is zero Rob's
program seems to work fine.  I think Pmw uses lots of tuples.

Looking closely at the code I see that _PyTuple_Resize is almost
certainly buggy.  I think something is wrong with PyTuple_New as
well.  I'll have to come up with a patch later as it is much to
late now for me to fully understand such hairy code. :(

  Neil



From pf at artcom-gmbh.de  Thu Oct  5 07:55:19 2000
From: pf at artcom-gmbh.de (Peter Funk)
Date: Thu, 5 Oct 2000 07:55:19 +0200 (MEST)
Subject: [Python-Dev] irritating 'No such file or directory' message (was Re: [Python-checkins] CVS: python/nondist/peps pep-0004.txt,NONE,1.1)
In-Reply-To: <200010042240.PAA14714@slayer.i.sourceforge.net> from Barry Warsaw at "Oct 4, 2000  3:40:33 pm"
Message-ID: <m13h3zz-000DmMC@artcom0.artcom-gmbh.de>

Hi,

Barry Warsaw :
> Update of /cvsroot/python/python/nondist/peps
> In directory slayer.i.sourceforge.net:/tmp/cvs-serv14669
> 
> Added Files:
> 	pep-0004.txt 
> Log Message:
> Added PEP 4, Deprecation of Standard Modules, Martin von Loewis
> 
> 
> ***** Error reading new file: (2, 'No such file or directory')

Whenever Barry adds a new file to the CVS, its initial content
is invisible on the checkins mailing list due to the error message
above.  However if for example fdrake adds a new file (for example the
support.py recently added to the doc subtree) then this doesn't happen.
Is there anybody out there able to fix this for future checkins-mails?

Regards, Peter



From fdrake at beopen.com  Thu Oct  5 08:23:10 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Thu, 5 Oct 2000 02:23:10 -0400 (EDT)
Subject: [Python-Dev] irritating 'No such file or directory' message (was Re: [Python-checkins] CVS: python/nondist/peps pep-0004.txt,NONE,1.1)
In-Reply-To: <m13h3zz-000DmMC@artcom0.artcom-gmbh.de>
References: <200010042240.PAA14714@slayer.i.sourceforge.net>
	<m13h3zz-000DmMC@artcom0.artcom-gmbh.de>
Message-ID: <14812.7758.940994.732616@cj42289-a.reston1.va.home.com>

Peter Funk writes:
 > Whenever Barry adds a new file to the CVS, its initial content
 > is invisible on the checkins mailing list due to the error message
 > above.  However if for example fdrake adds a new file (for example the
 > support.py recently added to the doc subtree) then this doesn't happen.
 > Is there anybody out there able to fix this for future checkins-mails?

  Wow!  I had noticed the bolluxed messages, but hadn't tied it to
Barry!  But I just checked the added files for this month and
spot-checked the ones from last month, and Barry's all exhibit this
problem, and no one else's do.
  I wonder if something is wrong with his SourceForge account?  Barry,
check your group memberships, please!  If nothing obvious is wrong,
submit a support request, because this is definately annoying.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From tim_one at email.msn.com  Thu Oct  5 09:09:20 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Thu, 5 Oct 2000 03:09:20 -0400
Subject: [Python-Dev] change to Lib/popen2.py break test_popen2 on windows
In-Reply-To: <20001003161009.B18387@ActiveState.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCOEKMHJAA.tim_one@email.msn.com>

[Trent Mick, pointing out that test_popen2 was busted on Windows]
> Geez, you are fast Tim! (for others: he patched test_popen.py
> after I sent my email but before my email made it to python-dev!)

I hate to be honest, but I actually pointed out the test_popen2 failure on
Python-Dev last week.  However, I was On Vacation(tm) then, so thought
merely mentioning it would shame someone else into fixing it.  At this
point, I'll happily settle for that somebody else eventually *noticed* it!

our-windows-testing-dept-may-be-on-permanent-vacation-ly y'rs  - tim





From tim_one at email.msn.com  Thu Oct  5 09:09:17 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Thu, 5 Oct 2000 03:09:17 -0400
Subject: [Python-Dev] pep42 procedure?
In-Reply-To: <ECEPKNMJLHAPFFJHDOJBAEBJDMAA.MarkH@ActiveState.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCMEKMHJAA.tim_one@email.msn.com>

[Mark Hammond]
> That would be a great idea, if only we had a PEP author.  To be honest,
> I really dont care too much about this issue, and have been doing my
> level best to avoid it.  But Tim knows that, and delights in assigning
> related patches to me ;-)  I certainly don't care enough to own a pep
> on it. ...

I assign them to you because there's barely a line of Windows startup code
you didn't write, and you gave Windows the notion of naming the main DLL
differently across (some) different releases thus creating the possibility
for the problem these patches are trying to solve <wink>.  That's not to say
it's "your problem", but is to say you've thought more about "stuff like
this" than anyone else, and have very particular ideas about how you want
"stuff like this" done:  you're the best qualified.

That said, the subject of the PEP shouldn't be competing hacks to worm
around Windows-specific startup problems, it should be an actual design for
binary compatibility across iterations of the C API, or at least a reliable
way for extensions to *know* they're not getting a version of the Python
core they can use.

we're-only-hacking-because-we've-ignored-the-real-problem-ly y'rs  - tim





From martin at loewis.home.cs.tu-berlin.de  Thu Oct  5 09:44:52 2000
From: martin at loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Thu, 5 Oct 2000 09:44:52 +0200
Subject: [Python-Dev] Proposal -- makefile patches and scripts to generate python RPMs
Message-ID: <200010050744.JAA00782@loewis.home.cs.tu-berlin.de>

> The main thing a specfile generator can accomplish is to automate
> the generation of the file list so that (for example) when we add a
> new library module the specfile doesn't have to be hand-edited.

That sounds similar to the rationale for having automatically
generated dependency files for make, e.g. by gcc -MM. Many projects
use this as a convenience, and it kind-of works. However, I still like
it better to have dependencies explicitly recorded in the
Makefiles. That requires more discipline, but is easier to understand,
and the behaviour is more reproducable.

So given the option of using an existing hand-written spec file, and
having some magic generate one for me, I'd always use the hand-written
one. The magic is only good if there is no hand-written one.

Regards,
Martin




From fredrik at pythonware.com  Thu Oct  5 09:50:37 2000
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Thu, 5 Oct 2000 09:50:37 +0200
Subject: [Python-Dev] Release candidate followed by feature freeze?
References: <200010011913.VAA01107@pandora.informatik.hu-berlin.de> <200010021919.OAA01232@cj20424-a.reston1.va.home.com> <20001002044859.A9639@glacier.fnational.com> <200010030236.VAA02702@cj20424-a.reston1.va.home.com> <20001004144350.A434@glacier.fnational.com>
Message-ID: <00e301c02ea0$f3ea5680$0900a8c0@SPIFF>

neil wrote:
> On Mon, Oct 02, 2000 at 09:36:03PM -0500, Guido van Rossum wrote:
> > Hooft's problem makes heavy use of Tkinter and Pmw, it seems.  Maybe
> > that's a clue?
> 
> Rob was kind enough to send me some code to trigger the bug.  The
> winner is ... tupleobject.c!  When MAXSAVESIZE is zero Rob's
> program seems to work fine.  I think Pmw uses lots of tuples.

The new version of Tkinter contains a _flatten function written in C,
which uses PyTuple_Resize extensively.

To check if Rob's program works better without it, you can comment
out the "_flatten = _tkinter._flatten" line in Tkinter.py (it's line 70 or
so, iirc).

</F>




From larsga at garshol.priv.no  Thu Oct  5 10:36:33 2000
From: larsga at garshol.priv.no (Lars Marius Garshol)
Date: 05 Oct 2000 10:36:33 +0200
Subject: [Python-Dev] htmllib.HTMLescape()
In-Reply-To: <200010042031.WAA17378@pandora.informatik.hu-berlin.de>
References: <200010042031.WAA17378@pandora.informatik.hu-berlin.de>
Message-ID: <m3itr7elbi.fsf@lambda.garshol.priv.no>

* Martin von Loewis
| 
| Doesn't xml.sax.saxutils.escape do what you want (together with
| htmlentitydefs)? I was going to say that this is quite a small
| change to warrant a PEP - but there are two obvious approaches
| (working from scratch, or working on top of xml.sax.saxutils.escape
| - perhaps modifying and relocating that function), so *some* design
| probably needs to be recorded in a PEP.

It would probably help, but now that Python has Unicode support there
should be some way to convert string data to a legacy encoding and
represent all characters not available in that encoding using numeric
character references.  This would be very useful for both XML and
HTML.  The difficulty, I assume, lies in figuring out which encodings
support what characters.

--Lars M.




From nas at arctrix.com  Thu Oct  5 07:59:38 2000
From: nas at arctrix.com (Neil Schemenauer)
Date: Wed, 4 Oct 2000 22:59:38 -0700
Subject: [Python-Dev] Release candidate followed by feature freeze?
In-Reply-To: <00e301c02ea0$f3ea5680$0900a8c0@SPIFF>; from fredrik@pythonware.com on Thu, Oct 05, 2000 at 09:50:37AM +0200
References: <200010011913.VAA01107@pandora.informatik.hu-berlin.de> <200010021919.OAA01232@cj20424-a.reston1.va.home.com> <20001002044859.A9639@glacier.fnational.com> <200010030236.VAA02702@cj20424-a.reston1.va.home.com> <20001004144350.A434@glacier.fnational.com> <00e301c02ea0$f3ea5680$0900a8c0@SPIFF>
Message-ID: <20001004225938.A802@glacier.fnational.com>

On Thu, Oct 05, 2000 at 09:50:37AM +0200, Fredrik Lundh wrote:
> The new version of Tkinter contains a _flatten function written in C,
> which uses PyTuple_Resize extensively.
> 
> To check if Rob's program works better without it, you can comment
> out the "_flatten = _tkinter._flatten" line in Tkinter.py (it's line 70 or
> so, iirc).

That fixes the crash as well.

  Neil



From bwarsaw at beopen.com  Thu Oct  5 15:33:53 2000
From: bwarsaw at beopen.com (Barry A. Warsaw)
Date: Thu, 5 Oct 2000 09:33:53 -0400 (EDT)
Subject: [Python-Dev] irritating 'No such file or directory' message (was Re: [Python-checkins] CVS: python/nondist/peps pep-0004.txt,NONE,1.1)
References: <200010042240.PAA14714@slayer.i.sourceforge.net>
	<m13h3zz-000DmMC@artcom0.artcom-gmbh.de>
	<14812.7758.940994.732616@cj42289-a.reston1.va.home.com>
Message-ID: <14812.33601.730022.889777@anthem.concentric.net>

>>>>> "Fred" == Fred L Drake, Jr <fdrake at beopen.com> writes:

    Fred>   Wow!  I had noticed the bolluxed messages, but hadn't tied
    Fred> it to Barry!  But I just checked the added files for this
    Fred> month and spot-checked the ones from last month, and Barry's
    Fred> all exhibit this problem, and no one else's do.  I wonder if
    Fred> something is wrong with his SourceForge account?  Barry,
    Fred> check your group memberships, please!  If nothing obvious is
    Fred> wrong, submit a support request, because this is definately
    Fred> annoying.

I don't understand why this is happening, esp. just for me!  My
primary group is users and I'm definitely in the python group as
well.  Why would it be a permission problem anyway, since that's not
what the error message is saying?

Better log messages in syncmail would help diagnose this, but I
haven't got the time right now to hack on that.

-Barry



From pf at artcom-gmbh.de  Thu Oct  5 15:54:58 2000
From: pf at artcom-gmbh.de (Peter Funk)
Date: Thu, 5 Oct 2000 15:54:58 +0200 (MEST)
Subject: [Python-Dev] irritating 'No such file or directory' message (was Re: [Python-checkins] CVS: python/nondist/peps pep-0004.txt
In-Reply-To: <14812.33601.730022.889777@anthem.concentric.net> from "Barry A. Warsaw" at "Oct 5, 2000  9:33:53 am"
Message-ID: <m13hBUA-000DmMC@artcom0.artcom-gmbh.de>

Hi,

Barry A. Warsaw:
> 
> >>>>> "Fred" == Fred L Drake, Jr <fdrake at beopen.com> writes:
> 
>     Fred>   Wow!  I had noticed the bolluxed messages, but hadn't tied
>     Fred> it to Barry!  But I just checked the added files for this
>     Fred> month and spot-checked the ones from last month, and Barry's
>     Fred> all exhibit this problem, and no one else's do.  I wonder if
>     Fred> something is wrong with his SourceForge account?  Barry,
>     Fred> check your group memberships, please!  If nothing obvious is
>     Fred> wrong, submit a support request, because this is definately
>     Fred> annoying.
> 
> I don't understand why this is happening, esp. just for me!  My
> primary group is users and I'm definitely in the python group as
> well.  Why would it be a permission problem anyway, since that's not
> what the error message is saying?
> 
> Better log messages in syncmail would help diagnose this, but I
> haven't got the time right now to hack on that.

Just speculating: it has something todo with the current directory 
where the cvs commit command is executed in or it depends on the 
difference that the PEPs are under nondist and Freds files were under dist.

Possible ugly workaround for Barry: for new files first commit an empty 
file and then the real file just a moment later. ;-)

Regards, Peter
-- 
Peter Funk, Oldenburger Str.86, D-27777 Ganderkesee, Germany, Fax:+49 4222950260
office: +49 421 20419-0 (ArtCom GmbH, Grazer Str.8, D-28359 Bremen)



From jeremy at beopen.com  Thu Oct  5 16:42:31 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Thu, 5 Oct 2000 10:42:31 -0400 (EDT)
Subject: [Python-Dev] Release candidate schedule
Message-ID: <14812.37719.248406.924744@bitdiddle.concentric.net>

There are still a number of open bugs that need to be addressed before
we can issue a release candidate.  We plan to issue the release
candidate on Monday and the final release a week later.

According to the Sourceforge bug report --
http://sourceforge.net/bugs/reporting/?group_id=5470&run_report=1&tech=1
-- the following people still have open bugs:

akuchlin (3) 
bwarsaw (3) 
dcjim (2) 
effbot (5) 
fdrake (4) 
gvanrossum (12) 
gward (1) 
jackjansen (1) 
jhylton (8) 
lemburg (2) 
mhammond (5) 
nascheme (3) 
tim_one (5)

I don't expect that every bug will be closed before 2.0 final, but
there are some open bugs about test failures and build problems with
2.0 beta releases.  We should address these if at all possible.

Please review your open bugs and make sure you aren't forgetting about
something.  If you have bugs that will not be fixed for 2.0, make sure
they have a fairly low priority.  If you have bugs you will not be
able to address, assign them to me.

Jeremy



From effbot at telia.com  Thu Oct  5 16:53:48 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Thu, 5 Oct 2000 16:53:48 +0200
Subject: [Python-Dev] Release candidate followed by feature freeze?
References: <200010011913.VAA01107@pandora.informatik.hu-berlin.de> <200010021919.OAA01232@cj20424-a.reston1.va.home.com> <20001002044859.A9639@glacier.fnational.com> <200010030236.VAA02702@cj20424-a.reston1.va.home.com> <20001004144350.A434@glacier.fnational.com> <00e301c02ea0$f3ea5680$0900a8c0@SPIFF> <20001004225938.A802@glacier.fnational.com>
Message-ID: <002501c02edc$1302b040$766940d5@hagrid>

what's the current release schedule, btw?

is the repository frozen, or do we still have a chance to fix
the GC tuple problem and SRE's "nothing to repeat" bug?

</F>




From effbot at telia.com  Thu Oct  5 16:51:25 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Thu, 5 Oct 2000 16:51:25 +0200
Subject: [Python-Dev] Release candidate followed by feature freeze?
References: <200010011913.VAA01107@pandora.informatik.hu-berlin.de> <200010021919.OAA01232@cj20424-a.reston1.va.home.com> <20001002044859.A9639@glacier.fnational.com> <200010030236.VAA02702@cj20424-a.reston1.va.home.com> <20001004144350.A434@glacier.fnational.com> <00e301c02ea0$f3ea5680$0900a8c0@SPIFF> <20001004225938.A802@glacier.fnational.com>
Message-ID: <002401c02edc$12aec3e0$766940d5@hagrid>

> > To check if Rob's program works better without it, you can comment
> > out the "_flatten = _tkinter._flatten" line in Tkinter.py (it's line 70 or
> > so, iirc).
> 
> That fixes the crash as well.

in other words, _PyTuple_Resize needs some work...

(or does _flatten do something wrong?  it starts by creating
a tuple, and if it needs more space, it doubles the size one or
more times, and ends by calling Resize again to set the final
size...)

:::

btw, the start of Resize looks a bit strange: should that
DECREF really be there?  should least be an XDECREF, or
am I missing something?

 if (v == NULL || !PyTuple_Check(v) || v->ob_refcnt != 1) {
  *pv = 0;
  Py_DECREF(v); /* really? what if v is NULL? */
  PyErr_BadInternalCall();
  return -1;
 }

</F>




From mal at lemburg.com  Thu Oct  5 17:00:12 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Thu, 05 Oct 2000 17:00:12 +0200
Subject: [Python-Dev] Proposal -- makefile patches and scripts to generate 
 python RPMs
References: <200010041717.NAA03509@snark.thyrsus.com> <002c01c02e28$1dc20d00$766940d5@hagrid> <20001004140219.A5125@kronos.cnri.reston.va.us>
Message-ID: <39DC977C.89D14AB1@lemburg.com>

Andrew Kuchling wrote:
> 
> On Wed, Oct 04, 2000 at 07:25:37PM +0200, Fredrik Lundh wrote:
> >isn't this a distutils thing?  see:
> >ftp://python.beopen.com/pub/docco/devel/dist/creating-rpms.html
> >(lazy programmers just press the "deploy" button, of course ;-)
> 
> It's not immediately obvious that the Distutils 1.0, which after all
> mostly aims to support installing Python modules, can be applied to
> installing Python itself, what with all the libraries and scripts and
> such that Python needs.  It certainly is something to aim for, and I
> intend to work on this some more after 2.0, but the attempt might run
> into missing Distutil features.  Whether it's worth adding rules for
> RPM in the meantime is up to the Pythoneers; I'm 0 on it.  (Not +0 or
> -0, just 0 -- a Nirvana-like state of utter unconcern.)

distutils is not useful for installing Python (it needs Python
to start with), but it does a pretty good job at finding the
needed files and can generate RPMs which can be used without
distutils or Python. It even allows adding handcrafted sections
to the resulting RPM.

If anybody plans to help in this direction, I'd suggest to add
those efforts to the build_rpm command in distutils (and the
build_deb command for that matter).

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From akuchlin at mems-exchange.org  Thu Oct  5 17:24:32 2000
From: akuchlin at mems-exchange.org (Andrew Kuchling)
Date: Thu, 5 Oct 2000 11:24:32 -0400
Subject: [Python-Dev] Proposal -- makefile patches and scripts to generate python RPMs
In-Reply-To: <39DC977C.89D14AB1@lemburg.com>; from mal@lemburg.com on Thu, Oct 05, 2000 at 05:00:12PM +0200
References: <200010041717.NAA03509@snark.thyrsus.com> <002c01c02e28$1dc20d00$766940d5@hagrid> <20001004140219.A5125@kronos.cnri.reston.va.us> <39DC977C.89D14AB1@lemburg.com>
Message-ID: <20001005112432.A30233@kronos.cnri.reston.va.us>

On Thu, Oct 05, 2000 at 05:00:12PM +0200, M.-A. Lemburg wrote:
>distutils is not useful for installing Python (it needs Python
>to start with), ...

Note that the Distutils doesn't need many C-based modules: _sre,
posix, and string are about it.  So those modules could be
automatically compiled into the Python binary (perhaps being moved
from Modules/ into Python/ to signify their new importance) and the
resulting binary should have enough marbles to run a setup.py script
that would build everything else in Modules/.  

The downside is that you could no longer compile those 3 modules as
dynamically loadable, but the upside is that the setup.py could be
smarter about detecting which libraries are available on the system,
and compiling everything which can be.  This would, one hopes, make
Setup file hacking a thing of the past...

--amk





From tismer at appliedbiometrics.com  Thu Oct  5 16:33:54 2000
From: tismer at appliedbiometrics.com (Christian Tismer)
Date: Thu, 05 Oct 2000 17:33:54 +0300
Subject: [Python-Dev] Stackless Python Mailing List
Message-ID: <39DC9152.7998DFC0@appliedbiometrics.com>

Hi Pythoneers (without or not without Stack (yet:))

there have been a couple of interviews, and some
articles on Stackless Python are published or in
preparation. I recognize an increasing number
of individual emails concerning Stackless Python.

This lets me take the opportunity to start a mailing
list on Stackless Python, an overdue task.

The goal of this list is two-fold:
On the one hand, people should have a forum to
discuss their use of SLP, its further development,
concurrency in general, and more.
The other reason is to increase the support for SLP,
with the final goal to get it merged into Standard Python.
There are a couple of ways to help me with that, see
http://starShip.python.net/mailman/listinfo/stackless

Everybody who is interested in Stackless Python and
all the related topics may feel invited to join this
discussion group.

cheers - chris

-- 
Christian Tismer             :^)   <mailto:tismer at appliedbiometrics.com>
Applied Biometrics GmbH      :     Have a break! Take a ride on Python's
Kaunstr. 26                  :    *Starship* http://starship.python.net
14163 Berlin                 :     PGP key -> http://wwwkeys.pgp.net
PGP Fingerprint       E182 71C7 1A9D 66E9 9D15  D3CC D4D7 93E2 1FAE F6DF
     where do you want to jump today?   http://www.stackless.com



From nas at arctrix.com  Thu Oct  5 10:40:28 2000
From: nas at arctrix.com (Neil Schemenauer)
Date: Thu, 5 Oct 2000 01:40:28 -0700
Subject: [Python-Dev] Release candidate followed by feature freeze?
In-Reply-To: <002401c02edc$12aec3e0$766940d5@hagrid>; from effbot@telia.com on Thu, Oct 05, 2000 at 04:51:25PM +0200
References: <200010011913.VAA01107@pandora.informatik.hu-berlin.de> <200010021919.OAA01232@cj20424-a.reston1.va.home.com> <20001002044859.A9639@glacier.fnational.com> <200010030236.VAA02702@cj20424-a.reston1.va.home.com> <20001004144350.A434@glacier.fnational.com> <00e301c02ea0$f3ea5680$0900a8c0@SPIFF> <20001004225938.A802@glacier.fnational.com> <002401c02edc$12aec3e0$766940d5@hagrid>
Message-ID: <20001005014028.A1055@glacier.fnational.com>

On Thu, Oct 05, 2000 at 04:51:25PM +0200, Fredrik Lundh wrote:
> in other words, _PyTuple_Resize needs some work...

Yup.  I've attached a patch which I believe fixes some GC bugs in
addition to making it simpler.

> btw, the start of Resize looks a bit strange: should that
> DECREF really be there?  should least be an XDECREF, or
> am I missing something?
> 
>  if (v == NULL || !PyTuple_Check(v) || v->ob_refcnt != 1) {
>   *pv = 0;
>   Py_DECREF(v); /* really? what if v is NULL? */
>   PyErr_BadInternalCall();
>   return -1;
>  }

I think your right.  Here's a fun little program:

    from _tkinter import _flatten
    import random # don't ask me why
    for x in xrange(10000):
        print x
        t = _flatten([(0,)*x]*x)

It gives:

    0
    1
    2
    3
    4
    5
    Segmentation fault

on the two Linux machines I've tested it on.  It also crashes
with GC disabled.

  Neil


*** Objects/tupleobject.c	Thu Oct  5 11:31:30 2000
--- tupleobject.c	Thu Oct  5 10:47:44 2000
***************
*** 500,531 ****
  	} else 
  #endif		
  	{
! #ifdef WITH_CYCLE_GC
! 		PyGC_Head *g = PyObject_AS_GC((PyObject *)v);
! 		PyObject_GC_Fini((PyObject *)v);
! 		g = (PyGC_Head *)
! 			PyObject_REALLOC((char *)g, sizeof(PyTupleObject) 
! 					+ PyGC_HEAD_SIZE
! 					+ newsize * sizeof(PyObject *));
! 		if (g == NULL) {
! 			sv = NULL;
! 		} else {
! 			sv = (PyTupleObject *)PyObject_FROM_GC(g);
! 		}
! #else
  		sv = (PyTupleObject *)
! 			PyObject_REALLOC((char *)v, sizeof(PyTupleObject) 
! 					+ PyGC_HEAD_SIZE
! 					+ newsize * sizeof(PyObject *));
! #endif
! 		*pv = (PyObject *) sv;
  		if (sv == NULL) {
! 			PyObject_GC_Init((PyObject *)v);
! 			v = (PyTupleObject *) PyObject_AS_GC(v);
  			PyObject_DEL(v);
  			PyErr_NoMemory();
  			return -1;
  		}
  	}
  	_Py_NewReference((PyObject *)sv);
  	for (i = sv->ob_size; i < newsize; i++)
--- 500,519 ----
  	} else 
  #endif		
  	{
! 		PyObject_GC_Fini(v);
! 		v = (PyObject *) PyObject_AS_GC(v);
  		sv = (PyTupleObject *)
! 			PyObject_REALLOC((char *)v, sizeof(PyTupleObject)
! 					 + PyGC_HEAD_SIZE
! 					 + newsize * sizeof(PyObject *));
  		if (sv == NULL) {
! 			*pv = NULL;
  			PyObject_DEL(v);
  			PyErr_NoMemory();
  			return -1;
  		}
+ 		sv = (PyTupleObject *) PyObject_FROM_GC(sv);
+ 		*pv = (PyObject *) sv;
  	}
  	_Py_NewReference((PyObject *)sv);
  	for (i = sv->ob_size; i < newsize; i++)






From guido at python.org  Thu Oct  5 20:22:49 2000
From: guido at python.org (Guido van Rossum)
Date: Thu, 05 Oct 2000 13:22:49 -0500
Subject: [Python-Dev] forwarded message from aahz@panix.com
In-Reply-To: Your message of "Wed, 04 Oct 2000 02:07:06 -0400."
             <14810.51466.486982.938180@anthem.concentric.net> 
References: <14810.51466.486982.938180@anthem.concentric.net> 
Message-ID: <200010051822.NAA14228@cj20424-a.reston1.va.home.com>

[Aahz]
> Someone just pointed out on c.l.py that we need an HTMLescape() function
> that takes a string and converts special characters to entities.  I'm
> not on python-dev, so could you please forward this and find out whether
> I need to run a PEP?

Has someone pointed out yet that this is done by cgi.escape()?

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



From guido at python.org  Thu Oct  5 20:24:20 2000
From: guido at python.org (Guido van Rossum)
Date: Thu, 05 Oct 2000 13:24:20 -0500
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules cPickle.c,2.52,2.53
In-Reply-To: Your message of "Wed, 04 Oct 2000 02:46:36 MST."
             <20001004024636.A13475@glacier.fnational.com> 
References: <200010041622.JAA17363@slayer.i.sourceforge.net>  
            <20001004024636.A13475@glacier.fnational.com> 
Message-ID: <200010051824.NAA14253@cj20424-a.reston1.va.home.com>

> I aways seem to think harder when reviewing a commit message than
> a diff. :(  I just realized that this commit subtly modifies
> cPickle's behavior.  Before the change instances __del__ methods
> would be called if allocating __dict__ failed.  After the change
> they are not.  I think the new behavior is better but the
> question is will it break existing code?  I think probably not.

This is goodness.  Don't worry about breaking code -- it probably
*fixes* code.  Most __del__ methods don't know what to do when the
instance variables haven't been defined yet!

> BTW, pickle seems to follow the new behavior.

Even better.

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



From guido at python.org  Thu Oct  5 20:29:27 2000
From: guido at python.org (Guido van Rossum)
Date: Thu, 05 Oct 2000 13:29:27 -0500
Subject: [Python-Dev] Adding a section to PEP 0042
In-Reply-To: Your message of "Wed, 04 Oct 2000 14:16:20 -0400."
             <20001004141620.A31293@ludwig.cnri.reston.va.us> 
References: <20001004141620.A31293@ludwig.cnri.reston.va.us> 
Message-ID: <200010051829.NAA14300@cj20424-a.reston1.va.home.com>

> I need to add an entry to PEP 0042 about the lack of cross-compilation
> support, because that's a bug report that was assigned to me, and needs
> to be marked "Closed/Feature Request/Later" and put in PEP 0042.  Seems
> to me that I should just add a section on "Build/Installation" to the
> PEP -- anyone disagree?  This might also be a good place to gather
> other gripes about Python's build/installation machinery...

+1

(I think the "Library" section is growing too big and may be split in
"Lib" and "Modules" sections.)

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



From guido at python.org  Thu Oct  5 20:33:47 2000
From: guido at python.org (Guido van Rossum)
Date: Thu, 05 Oct 2000 13:33:47 -0500
Subject: [Python-Dev] Proposal -- makefile patches and scripts to generate python RPMs
In-Reply-To: Your message of "Thu, 05 Oct 2000 09:44:52 +0200."
             <200010050744.JAA00782@loewis.home.cs.tu-berlin.de> 
References: <200010050744.JAA00782@loewis.home.cs.tu-berlin.de> 
Message-ID: <200010051833.NAA14356@cj20424-a.reston1.va.home.com>

Whatever the outcome of this discussion, this is too late for 2.0.

But I tend to side with Jeremy and Martin -- "explicit is better".
I do want Jeremy to check his RPM generation scripts in, so they can
be improved in a truly open source project.  (Maybe in Tools/rpm?)

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



From guido at python.org  Thu Oct  5 20:43:30 2000
From: guido at python.org (Guido van Rossum)
Date: Thu, 05 Oct 2000 13:43:30 -0500
Subject: [Python-Dev] Release candidate followed by feature freeze?
In-Reply-To: Your message of "Thu, 05 Oct 2000 16:53:48 +0200."
             <002501c02edc$1302b040$766940d5@hagrid> 
References: <200010011913.VAA01107@pandora.informatik.hu-berlin.de> <200010021919.OAA01232@cj20424-a.reston1.va.home.com> <20001002044859.A9639@glacier.fnational.com> <200010030236.VAA02702@cj20424-a.reston1.va.home.com> <20001004144350.A434@glacier.fnational.com> <00e301c02ea0$f3ea5680$0900a8c0@SPIFF> <20001004225938.A802@glacier.fnational.com>  
            <002501c02edc$1302b040$766940d5@hagrid> 
Message-ID: <200010051843.NAA14435@cj20424-a.reston1.va.home.com>

> what's the current release schedule, btw?

Let me give that a shot...

-   Feature Freeze Now.  I.e. it's too late for anything even vaguely
    resembling a feature -- even if it's been discussed to death.

-   Bugfix Checkin Freeze Saturday (Oct 7)
    Starting Saturday, all checkins must be coordinated with the
    releasemeister (still Jeremy).

-   Release Candidate Monday (Oct 9)

-   Final Release Monday week (Oct 16)

Between the Release Candidate and the Final Release, all checkins must
fix bugs and must be approved by the releasemeister.

> is the repository frozen, or do we still have a chance to fix
> the GC tuple problem and SRE's "nothing to repeat" bug?

Simple bugfixes are okay till Saturday.  Bugfixes that are complex and
may break other stuff should be discussed with the releasemeister,
possibly cc'ing python-dev.

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



From effbot at telia.com  Thu Oct  5 20:05:54 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Thu, 5 Oct 2000 20:05:54 +0200
Subject: [Python-Dev] Release candidate followed by feature freeze?
References: <200010011913.VAA01107@pandora.informatik.hu-berlin.de> <200010021919.OAA01232@cj20424-a.reston1.va.home.com> <20001002044859.A9639@glacier.fnational.com> <200010030236.VAA02702@cj20424-a.reston1.va.home.com> <20001004144350.A434@glacier.fnational.com> <00e301c02ea0$f3ea5680$0900a8c0@SPIFF> <20001004225938.A802@glacier.fnational.com> <002401c02edc$12aec3e0$766940d5@hagrid> <20001005014028.A1055@glacier.fnational.com>
Message-ID: <002a01c02ef6$ee698860$766940d5@hagrid>

neil wrote:
> Yup.  I've attached a patch which I believe fixes some GC bugs in
> addition to making it simpler.

don't have the slightest idea how the GC stuff works,
but it sure looks right: just go ahead and check it in...

> > btw, the start of Resize looks a bit strange: should that
> > DECREF really be there?  should least be an XDECREF, or
> > am I missing something?
> > 
> >  if (v == NULL || !PyTuple_Check(v) || v->ob_refcnt != 1) {
> >   *pv = 0;
> >   Py_DECREF(v); /* <- really? what if v is NULL? */
> >   PyErr_BadInternalCall();
> >   return -1;
> >  }
> 
> I think your right.  Here's a fun little program:
> 
>     from _tkinter import _flatten
>     import random # don't ask me why
>     for x in xrange(10000):
>         print x
>         t = _flatten([(0,)*x]*x)
> 
> It gives:
> 
>     0
>     1
>     2
>     3
>     4
>     5
>     Segmentation fault

guido?

</F>




From jim at digicool.com  Thu Oct  5 20:10:42 2000
From: jim at digicool.com (Jim Fulton)
Date: Thu, 05 Oct 2000 14:10:42 -0400
Subject: [Python-Dev] Re: [medusa] select, signals, and "interrupted system call" (EINTR)
References: <39D74AFB.322E5187@digicool.com> <14807.35727.423642.721873@seattle.nightmare.com>
Message-ID: <39DCC422.90E4D0D5@digicool.com>

Sam Rushing wrote:
> 
> Jim Fulton writes:
>  > The asyncore main loop should check for this error in it's select
>  > call and the select module should make this error easier to check
>  > for.
> 
> It might go better into the event_loop function, which I think of as a
> more user-serviceable part.  [for example, the default loop vs. the
> one in medusa/event_loop.py that supports schedulable events]

Don't you think anyone using select on Unix would want this?
This isn't really an application-specific thing is it?

>  > I presume that this works in Python 1.6/2.0, but I
>  > haven't tried it yet?
>  >
>  > This depends on the structure of select.error values
>  > and requires that we get EINTR from somewhere. (What
>  > should the value be on NT?)
> 
> If it's a big problem, I guess we could use a different default
> event_loop() function for win32 vs. unix.

Or we could put this in the poll function and reraise the error on 
NT, as my change does.
 
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 aahz at panix.com  Thu Oct  5 21:52:47 2000
From: aahz at panix.com (aahz at panix.com)
Date: Thu, 5 Oct 2000 12:52:47 -0700 (PDT)
Subject: [Python-Dev] forwarded message from aahz@panix.com
In-Reply-To: <200010051822.NAA14228@cj20424-a.reston1.va.home.com> from "Guido van Rossum" at Oct 05, 2000 01:22:49 PM
Message-ID: <200010051952.PAA05883@panix6.panix.com>

> [Aahz]
>> Someone just pointed out on c.l.py that we need an HTMLescape() function
>> that takes a string and converts special characters to entities.  I'm
>> not on python-dev, so could you please forward this and find out whether
>> I need to run a PEP?
> 
> Has someone pointed out yet that this is done by cgi.escape()?

Yeah, I missed that earlier.  But after thinking some more, there are a
fair number of browser-like bits of software that fail to render many of
the special characters correctly (e.g. trademark).  This is frequently
due to character set issues; entities almost always render correctly,
though.  Therefore a general translation routine is probably handy.

cgi.escape() only handles "&", "<", ">".  I'm not sure whether cgi.escape
ought to be expanded to handle all characters or a new routine should be
added.  Martin van Loewis suggested xml.sax.saxutils.escape(), but I
have zero familiarity with XML and am waiting for 2.0final.  Perhaps
this should be taken off-line?
-- 
                      --- Aahz (Copyright 2000 by aahz at pobox.com)

Androgynous poly kinky vanilla queer het    <*>     http://www.rahul.net/aahz/
Hugs and backrubs -- I break Rule 6

There's a difference between a person who gets shit zie doesn't
deserve and a person who gets more shit than zie deserves.  --Aahz



From skip at mojam.com  Thu Oct  5 21:54:56 2000
From: skip at mojam.com (Skip Montanaro)
Date: Thu, 5 Oct 2000 14:54:56 -0500 (CDT)
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src configure,1.157,1.158 configure.in,1.166,1.167
In-Reply-To: <200010051845.LAA16072@slayer.i.sourceforge.net>
References: <200010051845.LAA16072@slayer.i.sourceforge.net>
Message-ID: <14812.56464.380651.537610@beluga.mojam.com>

    Barry> Apparently, on SunOS 4.1.4_JL (and other?) OSes, -d on an empty
    Barry> string always returns true.  This closes SF bug #115392.

There was a big thread recently on the tramp mailing list (similar to efs
for remote file editing in Emacs, but uses ssh/scp instead) about trying to
find a portable way to test for the existence of a file.  After trying all
sorts of stuff, the final result was pretty ugly, as I recall.

-- 
Skip Montanaro (skip at mojam.com)
http://www.mojam.com/
http://www.musi-cal.com/



From guido at python.org  Thu Oct  5 23:07:29 2000
From: guido at python.org (Guido van Rossum)
Date: Thu, 05 Oct 2000 16:07:29 -0500
Subject: [Python-Dev] forwarded message from aahz@panix.com
In-Reply-To: Your message of "Thu, 05 Oct 2000 12:52:47 MST."
             <200010051952.PAA05883@panix6.panix.com> 
References: <200010051952.PAA05883@panix6.panix.com> 
Message-ID: <200010052107.QAA20988@cj20424-a.reston1.va.home.com>

> Yeah, I missed that earlier.  But after thinking some more, there are a
> fair number of browser-like bits of software that fail to render many of
> the special characters correctly (e.g. trademark).  This is frequently
> due to character set issues; entities almost always render correctly,
> though.  Therefore a general translation routine is probably handy.

But character set issues also make it impossible to provide such a
translation routine: the current party line is that the encoding of
8-bit strings is unknown and that only ASCII can be assumed.

> cgi.escape() only handles "&", "<", ">".  I'm not sure whether cgi.escape
> ought to be expanded to handle all characters or a new routine should be
> added.  Martin van Loewis suggested xml.sax.saxutils.escape(), but I
> have zero familiarity with XML and am waiting for 2.0final.  Perhaps
> this should be taken off-line?

xml.sax.saxutils.escape() is a generalization of cgi.escape() -- read
the source (Lib/xml/sax/saxutils.py).  It allows you to specify
additional things to be replaced by entities by passing in a
dictionary mapping chars (or strings) to entities.

If you know that you are dealing with Latin-1, you could use the table
in htmlentitydefs.py to construct a table.

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



From jeremy at beopen.com  Thu Oct  5 22:13:34 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Thu, 5 Oct 2000 16:13:34 -0400 (EDT)
Subject: [Python-Dev] forwarded message from aahz@panix.com
In-Reply-To: <200010051952.PAA05883@panix6.panix.com>
References: <200010051822.NAA14228@cj20424-a.reston1.va.home.com>
	<200010051952.PAA05883@panix6.panix.com>
Message-ID: <14812.57582.25916.131290@bitdiddle.concentric.net>

>>>>> "AM" == aahz  <aahz at panix.com> writes:

  >> [Aahz]
  >>> Someone just pointed out on c.l.py that we need an HTMLescape()
  >>> function that takes a string and converts special characters to
  >>> entities.  I'm not on python-dev, so could you please forward
  >>> this and find out whether I need to run a PEP?
  >>
  >> Has someone pointed out yet that this is done by cgi.escape()?

  AM> Yeah, I missed that earlier.  But after thinking some more,
  AM> there are a fair number of browser-like bits of software that
  AM> fail to render many of the special characters correctly
  AM> (e.g. trademark).  This is frequently due to character set
  AM> issues; entities almost always render correctly, though.
  AM> Therefore a general translation routine is probably handy.

  AM> cgi.escape() only handles "&", "<", ">".  I'm not sure whether
  AM> cgi.escape ought to be expanded to handle all characters or a
  AM> new routine should be added.  Martin van Loewis suggested
  AM> xml.sax.saxutils.escape(), but I have zero familiarity with XML
  AM> and am waiting for 2.0final.  Perhaps this should be taken
  AM> off-line?

Perhaps we should take it to python-list -- or maybe we should form a
web-sig and work on it there.

There are definitely some tricky issues to work out.  I attempted to
work out some of the same issues for internationalization support in
Mailman's pipermail archives.

The escape function in cgi should stay minimal, because it deals with
the only truly essential characters.  If the browser interprets an
HTML page as iso-8859-1 ("Latin 1") then characters > chr(127) are
going to be rendered properly.  You can add an explicit meta tag to
the HTML page and the server will return the charset in the headers.

This seems quite a bit simpler than trying to escape all characters >
chr(127), except if you have to deal with old browsers that don't
support the charset specified by the HTTP header.

Jeremy



From thomas at xs4all.net  Thu Oct  5 23:40:22 2000
From: thomas at xs4all.net (Thomas Wouters)
Date: Thu, 5 Oct 2000 23:40:22 +0200
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src configure,1.157,1.158 configure.in,1.166,1.167
In-Reply-To: <200010051845.LAA16072@slayer.i.sourceforge.net>; from bwarsaw@users.sourceforge.net on Thu, Oct 05, 2000 at 11:45:55AM -0700
References: <200010051845.LAA16072@slayer.i.sourceforge.net>
Message-ID: <20001005234022.I12812@xs4all.nl>

On Thu, Oct 05, 2000 at 11:45:55AM -0700, Barry Warsaw wrote:
> Update of /cvsroot/python/python/dist/src
> In directory slayer.i.sourceforge.net:/tmp/cvs-serv14007

> Modified Files:
> 	configure configure.in 
> Log Message:
> Change all occurances of
> 
> 	test -d "$directory"
> to
> 	test ! -z "directory" -a -d "directory"

> Apparently, on SunOS 4.1.4_JL (and other?) OSes, -d on an empty string
> always returns true.  This closes SF bug #115392.

> --- 3103,3110 ----
>       USE_THREAD_MODULE="#"
>   else
> !     if test ! -z $with_threads -a -d $with_threads
>       then LDFLAGS="$LDFLAGS -L$with_threads"
>       fi
> !     if test ! -z $withval -a -d $withval
>       then LDFLAGS="$LDFLAGS -L$withval"
>       fi

Is this really going to work ? I always see 'portable' shell code do
something like

if [ "X${spam}" != "X" ] ...

instead of 'test -z', eventhough even BSDI test has -z. (The portable code
I'm talking about are mostly BSDI /etc/rc* scripts... BSDI's /bin/sh is
minimal, compared to modern day equivalents.) My /bin/sh-knowledge is
decidedly less impressive than my Python knowledge, but I thought something
like 

if test ! -z $withval -a -d $withval

where $withval is empty, would be parsed as

if test ! -z -a -d

which would be, uhm, wrong ? But like I said, I don't really know what I'm
talking about here, there could be another perfectly valid reason for BSDI
to use the roundabout way, instead of using -z.

-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!



From jeremy at beopen.com  Fri Oct  6 00:12:09 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Thu, 5 Oct 2000 18:12:09 -0400 (EDT)
Subject: [Python-Dev] Proposal -- makefile patches and scripts to generate python RPMs
In-Reply-To: <200010051833.NAA14356@cj20424-a.reston1.va.home.com>
References: <200010050744.JAA00782@loewis.home.cs.tu-berlin.de>
	<200010051833.NAA14356@cj20424-a.reston1.va.home.com>
Message-ID: <14812.64697.601359.920302@bitdiddle.concentric.net>

>>>>> "GvR" == Guido van Rossum <guido at python.org> writes:

  GvR> Whatever the outcome of this discussion, this is too late for
  GvR> 2.0.  But I tend to side with Jeremy and Martin -- "explicit is
  GvR> better".  I do want Jeremy to check his RPM generation scripts
  GvR> in, so they can be improved in a truly open source project.
  GvR> (Maybe in Tools/rpm?)

I don't actually use a script to generate the RPM.  I wrote a .spec
file by hand and use it to generate the RPMs using the rpm command.
I could check in the spec file, which I would end up changing every
time we do a release -- to update the version number, change the
Setup.in patch, etc.  I should probably also include the patch file
along with the .spec file.

I also wrote a smal distutils setup script for 2.0b2, which I should
check in somewhere.  Not sure where...

BTW, I've attached the spec file below.  You can get it from the
.src.rpm on pythonlabs.com, but that's pretty inconvenient if you're
merely curious.

Jeremy

%define name BeOpen-Python
%define version 2.0b2
%define release 1
%define __prefix /usr/local

Summary: An interpreted, interactive, object-oriented programming language.
Name: %{name}
Version: %{version}
Release: %{release}
Copyright: Modified CNRI Open Source License
Group: Development/Languages
Source: %{name}-%{version}.tar.bz2
Source1: html-%{version}.tar.bz2
Patch0: %{name}-%{version}-Setup.patch
BuildRoot: /var/tmp/%{name}-%{version}-root
Prefix: %{__prefix}
URL: http://www.pythonlabs.com/
Vendor: BeOpen PythonLabs
Packager: Jeremy Hylton <jeremy at beopen.com>

%description
Python is an interpreted, interactive, object-oriented programming
language.  It incorporates modules, exceptions, dynamic typing, very high
level dynamic data types, and classes. Python combines remarkable power
with very clear syntax. It has interfaces to many system calls and
libraries, as well as to various window systems, and is extensible in C or
C++. It is also usable as an extension language for applications that need
a programmable interface.  Finally, Python is portable: it runs on many
brands of UNIX, on PCs under Windows, MS-DOS, and OS/2, and on the
Mac.

%changelog
* Thu Oct  5 2000 Jeremy Hylton <jeremy at beopen.com>
- added bin/python2.0 to files list (suggested by Martin v. L?wis)

* Tue Sep 26 2000 Jeremy Hylton <jeremy at beopen.com>
- updated for release 1 of 2.0b2
- use .bz2 version of Python source

* Tue Sep 12 2000 Jeremy Hylton <jeremy at beopen.com>
- Version 2 of 2.0b1
- Make the package relocatable.  Thanks to Suchandra Thapa.
- Exclude Tkinter from main RPM.  If it is in a separate RPM, it is
  easier to track Tk releases.

%prep
%setup -n Python-%{version}
%patch0 
%setup -D -T -a 1 -n Python-%{version}
# This command drops the HTML files in the top-level build directory.
# That's not perfect, but it will do for now.

%build
./configure
make

%install
[ -d $RPM_BUILD_ROOT ] && rm -fr $RPM_BUILD_ROOT
mkdir -p $RPM_BUILD_ROOT%{__prefix}
make prefix=$RPM_BUILD_ROOT%{__prefix} install

%clean
rm -fr $RPM_BUILD_ROOT

%files
%defattr(-, root, root)
%{__prefix}/bin/python
%{__prefix}/bin/python2.0
%{__prefix}/man/man1/python.1
%doc Misc/README Misc/HYPE Misc/cheatsheet Misc/unicode.txt Misc/Porting
%doc LICENSE Misc/ACKS Misc/BLURB.* Misc/HISTORY Misc/NEWS
%doc index.html modindex.html api dist doc ext inst lib mac ref tut icons

%dir %{__prefix}/include/python2.0
%{__prefix}/include/python2.0/*.h
%dir %{__prefix}/lib/python2.0/
%{__prefix}/lib/python2.0/*.py*
%{__prefix}/lib/python2.0/pdb.doc
%{__prefix}/lib/python2.0/profile.doc
%dir %{__prefix}/lib/python2.0/config
%{__prefix}/lib/python2.0/config/Makefile
%{__prefix}/lib/python2.0/config/Makefile.pre.in
%{__prefix}/lib/python2.0/config/Setup
%{__prefix}/lib/python2.0/config/Setup.config
%{__prefix}/lib/python2.0/config/Setup.local
%{__prefix}/lib/python2.0/config/config.c
%{__prefix}/lib/python2.0/config/config.c.in
%{__prefix}/lib/python2.0/config/install-sh
%{__prefix}/lib/python2.0/config/libpython2.0.a
%{__prefix}/lib/python2.0/config/makesetup
%{__prefix}/lib/python2.0/config/python.o
%dir %{__prefix}/lib/python2.0/curses
%{__prefix}/lib/python2.0/curses/*.py*
%dir %{__prefix}/lib/python2.0/distutils
%{__prefix}/lib/python2.0/distutils/*.py*
%{__prefix}/lib/python2.0/distutils/README
%dir %{__prefix}/lib/python2.0/distutils/command
%{__prefix}/lib/python2.0/distutils/command/*.py*
%{__prefix}/lib/python2.0/distutils/command/command_template
%dir %{__prefix}/lib/python2.0/encodings
%{__prefix}/lib/python2.0/encodings/*.py*
%dir %{__prefix}/lib/python2.0/lib-dynload
%dir %{__prefix}/lib/python2.0/lib-tk
%{__prefix}/lib/python2.0/lib-tk/*.py*
%{__prefix}/lib/python2.0/lib-dynload/_codecsmodule.so
%{__prefix}/lib/python2.0/lib-dynload/_cursesmodule.so
%{__prefix}/lib/python2.0/lib-dynload/_localemodule.so
%{__prefix}/lib/python2.0/lib-dynload/arraymodule.so
%{__prefix}/lib/python2.0/lib-dynload/binascii.so
%{__prefix}/lib/python2.0/lib-dynload/cPickle.so
%{__prefix}/lib/python2.0/lib-dynload/cStringIO.so
%{__prefix}/lib/python2.0/lib-dynload/cmathmodule.so
%{__prefix}/lib/python2.0/lib-dynload/errnomodule.so
%{__prefix}/lib/python2.0/lib-dynload/fcntlmodule.so
%{__prefix}/lib/python2.0/lib-dynload/gdbmmodule.so
%{__prefix}/lib/python2.0/lib-dynload/grpmodule.so
%{__prefix}/lib/python2.0/lib-dynload/linuxaudiodev.so
%{__prefix}/lib/python2.0/lib-dynload/mathmodule.so
%{__prefix}/lib/python2.0/lib-dynload/md5module.so
%{__prefix}/lib/python2.0/lib-dynload/mmapmodule.so
%{__prefix}/lib/python2.0/lib-dynload/newmodule.so
%{__prefix}/lib/python2.0/lib-dynload/operator.so
%{__prefix}/lib/python2.0/lib-dynload/parsermodule.so
%{__prefix}/lib/python2.0/lib-dynload/pwdmodule.so
%{__prefix}/lib/python2.0/lib-dynload/pyexpat.so
%{__prefix}/lib/python2.0/lib-dynload/readline.so
%{__prefix}/lib/python2.0/lib-dynload/resource.so
%{__prefix}/lib/python2.0/lib-dynload/rotormodule.so
%{__prefix}/lib/python2.0/lib-dynload/selectmodule.so
%{__prefix}/lib/python2.0/lib-dynload/shamodule.so
%{__prefix}/lib/python2.0/lib-dynload/_socketmodule.so
%{__prefix}/lib/python2.0/lib-dynload/stropmodule.so
%{__prefix}/lib/python2.0/lib-dynload/structmodule.so
%{__prefix}/lib/python2.0/lib-dynload/syslogmodule.so
%{__prefix}/lib/python2.0/lib-dynload/termios.so
%{__prefix}/lib/python2.0/lib-dynload/timemodule.so
%{__prefix}/lib/python2.0/lib-dynload/ucnhash.so
%{__prefix}/lib/python2.0/lib-dynload/unicodedata.so
%{__prefix}/lib/python2.0/lib-dynload/zlibmodule.so
%dir %{__prefix}/lib/python2.0/lib-old
%{__prefix}/lib/python2.0/lib-old/*.py*
%dir %{__prefix}/lib/python2.0/plat-linux2
%{__prefix}/lib/python2.0/plat-linux2/*.py*
%{__prefix}/lib/python2.0/plat-linux2/regen
%dir %{__prefix}/lib/python2.0/site-packages
%{__prefix}/lib/python2.0/site-packages/README
%dir %{__prefix}/lib/python2.0/test
%{__prefix}/lib/python2.0/test/*.py*
%{__prefix}/lib/python2.0/test/README
%{__prefix}/lib/python2.0/test/audiotest.au
%{__prefix}/lib/python2.0/test/greyrgb.uue
%{__prefix}/lib/python2.0/test/test.xml
%{__prefix}/lib/python2.0/test/testimg.uue
%{__prefix}/lib/python2.0/test/testimgr.uue
%{__prefix}/lib/python2.0/test/testrgb.uue
%dir %{__prefix}/lib/python2.0/test/output
%{__prefix}/lib/python2.0/test/output/test_*
%dir %{__prefix}/lib/python2.0/xml
%{__prefix}/lib/python2.0/xml/*.py*
%dir %{__prefix}/lib/python2.0/xml/dom
%{__prefix}/lib/python2.0/xml/dom/*.py*
%dir %{__prefix}/lib/python2.0/xml/sax
%{__prefix}/lib/python2.0/xml/sax/*.py*



From fdrake at beopen.com  Fri Oct  6 02:14:20 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Thu, 5 Oct 2000 20:14:20 -0400 (EDT)
Subject: [Python-Dev] forwarded message from Gerald Pfeifer
Message-ID: <14813.6492.879919.445014@cj42289-a.reston1.va.home.com>


  I just got this message from the gcc-announce list.  We've seen bug
reports related to GCC 2.96 (which may or may not be the problem).  We
need to be aware that these releases are out there and can be a
problem.
  I've noticed that the version of GCC shipped with Mandrake 7.1 is
"gcc version 2.95.3 19991030 (prerelease)", which doesn't give my much
confidence either.  ;(


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member

-------------- next part --------------
An embedded message was scrubbed...
From: Gerald Pfeifer <pfeifer at dbai.tuwien.ac.at>
Subject: GCC 2.96
Date: Fri, 6 Oct 2000 01:58:11 +0200 (CEST)
Size: 3308
URL: <http://mail.python.org/pipermail/python-dev/attachments/20001005/53f9aeda/attachment-0001.eml>

From thomas at xs4all.net  Fri Oct  6 02:29:11 2000
From: thomas at xs4all.net (Thomas Wouters)
Date: Fri, 6 Oct 2000 02:29:11 +0200
Subject: [Python-Dev] forwarded message from Gerald Pfeifer
In-Reply-To: <14813.6492.879919.445014@cj42289-a.reston1.va.home.com>; from fdrake@beopen.com on Thu, Oct 05, 2000 at 08:14:20PM -0400
References: <14813.6492.879919.445014@cj42289-a.reston1.va.home.com>
Message-ID: <20001006022910.J12812@xs4all.nl>

On Thu, Oct 05, 2000 at 08:14:20PM -0400, Fred L. Drake, Jr. wrote:

>   I just got this message from the gcc-announce list.  We've seen bug
> reports related to GCC 2.96 (which may or may not be the problem).  We
> need to be aware that these releases are out there and can be a
> problem.
>   I've noticed that the version of GCC shipped with Mandrake 7.1 is
> "gcc version 2.95.3 19991030 (prerelease)", which doesn't give my much
> confidence either.  ;(

The 'unstable' branch of Debian currently ships with:
gcc version 2.95.2 20000220 (Debian GNU/Linux)

and it seems to be working fine. I did notice a problem, but it was related
to glibc 2.1.94, not gcc: LONG_BIT was wrongly defined to 64. Tim's
sanity-check, which checks LONG_BIT against (SIZEOF_LONG * 8), would have
caught that one, but I found it on my machine before he checked in that fix
;) For me, that problem was caused by the /usr/include/bits/xopen_lim.h
include file:

/* Number of bits in a word of type ong int'.  */
#if LONG_MAX == 2147483647
# define LONG_BIT       32
#else
/* Safe assumption.  */
# define LONG_BIT       64
#endif

where LONG_MAX was not defined (yet). I fixed it 'manually' for more than
just Python by adding

#ifndef LONG_MAX
#define LONG_MAX 2147483647
#endif

above it. I had to laugh, though, when I saw that assuming longs had 64 bits
is considered 'a safe assumption'. I guess most people use 64 bit machines
nowadays ? :-) 

I'm not complaining about this, though. Woody (Debian's current unstable
tree) is bleeding edge, and I'm fully prepared to live with it. In fact, I
love it! But people testing out glibc 2.1.90+ should keep this in mind. I'm
also wondering where to send my bugreport, but I think I'll read some
documentation before I do that, first ;)

-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!



From fdrake at beopen.com  Fri Oct  6 03:37:40 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Thu, 5 Oct 2000 21:37:40 -0400 (EDT)
Subject: [Python-Dev] forwarded message from Gerald Pfeifer
In-Reply-To: <20001006022910.J12812@xs4all.nl>
References: <14813.6492.879919.445014@cj42289-a.reston1.va.home.com>
	<20001006022910.J12812@xs4all.nl>
Message-ID: <14813.11492.123197.791450@cj42289-a.reston1.va.home.com>

Thomas Wouters writes:
 > The 'unstable' branch of Debian currently ships with:
 > gcc version 2.95.2 20000220 (Debian GNU/Linux)
 > 
 > and it seems to be working fine. I did notice a problem, but it was related

  I understand this to be the latest "stable" version of GCC, and it
appearantly it has been accepted as such for a while now.

 > above it. I had to laugh, though, when I saw that assuming longs had 64 bits
 > is considered 'a safe assumption'. I guess most people use 64 bit machines
 > nowadays ? :-) 

  Hey, my machine is 4294967296 bits!  Forget those ancient 64 bit
machines!  ;-)

 > I'm not complaining about this, though. Woody (Debian's current unstable
 > tree) is bleeding edge, and I'm fully prepared to live with it. In fact, I
 > love it! But people testing out glibc 2.1.90+ should keep this in mind. I'm

  I'm less concerned about people who know they're deliberatly putting
themselves on the bleeding edge than the people that pick up the
latest version of some Linux distribution and find they have a buggy
compiler because the distribution builders weren't as careful as
perhaps they should have been.  Putting together a professional grade
Linux distro is still a very hard thing.
  There's no such thing as enough testing here!


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From MarkH at ActiveState.com  Fri Oct  6 05:52:13 2000
From: MarkH at ActiveState.com (Mark Hammond)
Date: Fri, 6 Oct 2000 14:52:13 +1100
Subject: [Python-Dev] RE: buffer overlow in PC/getpathp.c
In-Reply-To: <ECEPKNMJLHAPFFJHDOJBEEGADLAA.MarkH@ActiveState.com>
Message-ID: <ECEPKNMJLHAPFFJHDOJBIEHDDMAA.MarkH@ActiveState.com>

[Me, responding to Jeremy's request I look for potential buffer exploits on
Windows...]

> I will be happy to look into this.

And was :-)

If anyone has time over the next day or 2, any holes I either missed, or
added(!) in
http://sourceforge.net/patch/?func=detailpatch&patch_id=101801&group_id=547
0 would be appreciated!

Thanks,

Mark.




From thomas.heller at ion-tof.com  Fri Oct  6 09:20:56 2000
From: thomas.heller at ion-tof.com (Thomas Heller)
Date: Fri, 6 Oct 2000 09:20:56 +0200
Subject: [Python-Dev] Proposal -- makefile patches and scripts to generate python RPMs
References: <200010050744.JAA00782@loewis.home.cs.tu-berlin.de><200010051833.NAA14356@cj20424-a.reston1.va.home.com> <14812.64697.601359.920302@bitdiddle.concentric.net>
Message-ID: <003d01c02f65$fb409550$4500a8c0@thomasnotebook>

> I don't actually use a script to generate the RPM.  I wrote a .spec
> file by hand and use it to generate the RPMs using the rpm command.
> I could check in the spec file, which I would end up changing every
> time we do a release -- to update the version number, change the
> Setup.in patch, etc.  I should probably also include the patch file
> along with the .spec file.
> 
> I also wrote a smal distutils setup script for 2.0b2, which I should
> check in somewhere.  Not sure where...
> 
Could you post this script?

Thomas




From loewis at informatik.hu-berlin.de  Thu Oct  5 21:49:26 2000
From: loewis at informatik.hu-berlin.de (Martin von Loewis)
Date: Thu, 5 Oct 2000 21:49:26 +0200 (MET DST)
Subject: [Python-Dev] PEP 4: Deprecation of standard modules
Message-ID: <200010051949.VAA04764@pandora.informatik.hu-berlin.de>

I just finished a first draft of a PEP on deprecating (and eventually
removing) modules from the standard Python library; it is available
from

http://python.sourceforge.net/peps/pep-0004.html

If you have comments or suggestions on the proposed procedures, or the
wording of the text, please send me a message. According to the PEP
procedures (PEP 1), this is the preferred way of progressing this PEP
(rather than discussing it on these lists), at least initially.

Regards,
Martin




From loewis at informatik.hu-berlin.de  Fri Oct  6 14:39:05 2000
From: loewis at informatik.hu-berlin.de (Martin von Loewis)
Date: Fri, 6 Oct 2000 14:39:05 +0200 (MET DST)
Subject: [Python-Dev] htmllib.HTMLescape()
Message-ID: <200010061239.OAA13090@pandora.informatik.hu-berlin.de>

> The difficulty, I assume, lies in figuring out which encodings
> support what characters.

It's not that difficult to write a set of new codecs; with the module
below, I can do

>>> import xmlenc
>>> u'\u0416'.encode('latin-1-xml')
'&#x416;'
>>> unicode('X&#x245;Y','latin-1-xml')
u'X\u0245Y'

The difficulty is that the algorithm is not very efficient if there
are many unsupported characters in a string.

Regards,
Martin

# Module implementing a set of new encodings of the form <enc>-xml
# Copyright Martin v. L&ouml;wis
# It currently supports hex character references only

import codecs

class CodecWrapper:
    def __init__(self,encoder,decoder):
        self.encoder = encoder
        self.decoder = decoder

    def encode(self,input,errors='strict'):
        try:
            return self.encoder(input,"strict")
        except ValueError:
            l = len(input)
            if l==1:
                return "&#x%x;" % ord(input), 1
            s1,l1 = self.encode(input[:l/2])
            s2,l2 = self.encode(input[l/2:])
            return s1+s2,l1+l2

    def decode(self,input,errors='strict'):
        input = str(input) # might be buffer object
        pos = input.find("&#x")
        if pos == -1:
            return self.decoder(input,errors)
        r1,l1 = self.decode(input[:pos],errors)
        end = input.find(";",pos)
        try:
            if end==-1:
                raise ValueError # goto failure code below
            val = int(input[pos+3:end],16)
            r2,l2 = self.decode(input[end+1:],errors)
            return r1+unichr(val)+r2,l1+end-pos+l2
        except ValueError:
            # how to deal with errors in decode?
            r2,l2 = self.decode(input[pos+2:],errors)
            return r1+"&#x"+r2,l1+3+l2

    def mkreader(self):
        r = codecs.StreamReader()
        r.decode = self.decode
        r.encode = self.encode
        return r

    def mkwriter(self):
        r = codecs.StreamWriter()
        r.decode = self.decode
        r.encode = self.encode
        return r

def search_function(encoding):
    if not encoding.endswith("-xml"):
        return None
    enc,dec,reader,writer = codecs.lookup(encoding[:-4])
    c = CodecWrapper(enc,dec)
    return c.encode,c.decode,c.mkreader,c.mkwriter

codecs.register(search_function)



From jeremy at beopen.com  Fri Oct  6 16:54:03 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Fri, 6 Oct 2000 10:54:03 -0400 (EDT)
Subject: [Python-Dev] Proposal -- makefile patches and scripts to generate python RPMs
In-Reply-To: <003d01c02f65$fb409550$4500a8c0@thomasnotebook>
References: <200010050744.JAA00782@loewis.home.cs.tu-berlin.de>
	<200010051833.NAA14356@cj20424-a.reston1.va.home.com>
	<14812.64697.601359.920302@bitdiddle.concentric.net>
	<003d01c02f65$fb409550$4500a8c0@thomasnotebook>
Message-ID: <14813.59275.350667.580400@bitdiddle.concentric.net>

Here is the setup script I used to build the Tk RPMs.  The name and
version part is a mess and I would welcome suggestions on how to fix
it.  The problem is that Tkinter gets built against a particular
version of Python and a particular version of Tcl/Tk.  I want the name
of the RPM to indiciate both versions, but didn't seem an obvious way
to accomplish it.  Thus, I put the Python version number in the name
and the Tcl/Tk version number in the version.  Otherwise, I think this
is pretty straightforward distutils stuff (although the documentation
was out of date last I checked).

I've attached three files.  I wrote setup.py and setup.cfg.  Distutils
created MANIFEST.

Jeremy

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: setup.py
URL: <http://mail.python.org/pipermail/python-dev/attachments/20001006/f815d426/attachment-0002.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: setup.cfg
URL: <http://mail.python.org/pipermail/python-dev/attachments/20001006/f815d426/attachment-0001.asc>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: MANIFEST
URL: <http://mail.python.org/pipermail/python-dev/attachments/20001006/f815d426/attachment-0003.txt>

From jeremy at beopen.com  Fri Oct  6 21:11:43 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Fri, 6 Oct 2000 15:11:43 -0400 (EDT)
Subject: [Python-Dev] linuxaudiodev module
Message-ID: <14814.9199.422989.273484@bitdiddle.concentric.net>

I just fixed a number of major bugs in the undocumented linuxaudiodev
module.  I ended up spending about an hour reading the excellent Open
Sound System (OSS) Programmer's Guide to figure out what the module
was trying to do and why it wasn't working on my Linux box.

After reading the module and the OSS guide, it is clear to me that we
need a complete re-write.  The module itself is just a wrapper around
a bunch of read, write, and ioctl calls.  It could all be implemented
in pure Python.

I propose we develop a Python module for Python 2.1 and call it
osslib.  There is nothing at all that is Linux-specific about the
interface being used.  The OSS guide mentions a plethora of platforms
that it supports.

In the interim, I have fixed some of the most egregious problems.  I
would appreciate it if Linux users could try out the fixes and the new
test case.  On my machine it still sounds awful, but at least the
sound can be heard.

Jeremy



From akuchlin at mems-exchange.org  Fri Oct  6 21:17:39 2000
From: akuchlin at mems-exchange.org (Andrew Kuchling)
Date: Fri, 6 Oct 2000 15:17:39 -0400
Subject: [Python-Dev] linuxaudiodev module
In-Reply-To: <14814.9199.422989.273484@bitdiddle.concentric.net>; from jeremy@beopen.com on Fri, Oct 06, 2000 at 03:11:43PM -0400
References: <14814.9199.422989.273484@bitdiddle.concentric.net>
Message-ID: <20001006151739.A31189@kronos.cnri.reston.va.us>

On Fri, Oct 06, 2000 at 03:11:43PM -0400, Jeremy Hylton wrote:
>After reading the module and the OSS guide, it is clear to me that we
>need a complete re-write.  The module itself is just a wrapper around
>a bunch of read, write, and ioctl calls.  It could all be implemented
>in pure Python.

So, is there any point in releasing linuxaudiodev at all, then, if it
needs a complete rewrite?

--amk




From DavidA at ActiveState.com  Fri Oct  6 21:39:21 2000
From: DavidA at ActiveState.com (David Ascher)
Date: Fri, 6 Oct 2000 12:39:21 -0700 (Pacific Daylight Time)
Subject: [Python-Dev] linuxaudiodev module
In-Reply-To: <14814.9199.422989.273484@bitdiddle.concentric.net>
Message-ID: <Pine.WNT.4.21.0010061238130.844-100000@loom>

> I propose we develop a Python module for Python 2.1 and call it
> osslib.  There is nothing at all that is Linux-specific about the
> interface being used.  The OSS guide mentions a plethora of platforms
> that it supports.

Have you evaluated http://net.indra.com/~tim/ossmodule/

?






From jeremy at beopen.com  Fri Oct  6 21:47:27 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Fri, 6 Oct 2000 15:47:27 -0400 (EDT)
Subject: [Python-Dev] linuxaudiodev module
In-Reply-To: <20001006151739.A31189@kronos.cnri.reston.va.us>
References: <14814.9199.422989.273484@bitdiddle.concentric.net>
	<20001006151739.A31189@kronos.cnri.reston.va.us>
Message-ID: <14814.11343.988335.520786@bitdiddle.concentric.net>

>>>>> "AMK" == Andrew Kuchling <akuchlin at mems-exchange.org> writes:

  AMK> On Fri, Oct 06, 2000 at 03:11:43PM -0400, Jeremy Hylton wrote:
  >> After reading the module and the OSS guide, it is clear to me
  >> that we need a complete re-write.  The module itself is just a
  >> wrapper around a bunch of read, write, and ioctl calls.  It could
  >> all be implemented in pure Python.

  AMK> So, is there any point in releasing linuxaudiodev at all, then,
  AMK> if it needs a complete rewrite?

I would be include to chuck it, except that it also shipped with 1.6.
I would hestitate to deprecate it so far into the release process.

jeremy



From jeremy at beopen.com  Fri Oct  6 21:47:48 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Fri, 6 Oct 2000 15:47:48 -0400 (EDT)
Subject: [Python-Dev] linuxaudiodev module
In-Reply-To: <Pine.WNT.4.21.0010061238130.844-100000@loom>
References: <14814.9199.422989.273484@bitdiddle.concentric.net>
	<Pine.WNT.4.21.0010061238130.844-100000@loom>
Message-ID: <14814.11364.360443.940965@bitdiddle.concentric.net>

I had no idea it existed.

Jeremy



From jeremy at beopen.com  Fri Oct  6 21:54:35 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Fri, 6 Oct 2000 15:54:35 -0400 (EDT)
Subject: [Python-Dev] linuxaudiodev module
In-Reply-To: <Pine.WNT.4.21.0010061238130.844-100000@loom>
References: <14814.9199.422989.273484@bitdiddle.concentric.net>
	<Pine.WNT.4.21.0010061238130.844-100000@loom>
Message-ID: <14814.11771.731237.214646@bitdiddle.concentric.net>

>>>>> "DA" == David Ascher <DavidA at ActiveState.com> writes:

  DA> Have you evaluated http://net.indra.com/~tim/ossmodule/

Okay.  I took a quick look.  It's really old (July 1997).  It looks
like a more reasonable wrapping than linuxaudiodev, although I would
want to review it more carefully against the OSS programmer's guide.

I would prefer a pure Python solution, because the code would be
shorter and easier to read and maintain.  It may be, however, that the
ossmodule is still up-to-date; if so, it may be easier to use it than
to rewrite it.

Jeremy




From ping at lfw.org  Fri Oct  6 23:13:39 2000
From: ping at lfw.org (Ka-Ping Yee)
Date: Fri, 6 Oct 2000 16:13:39 -0500 (CDT)
Subject: [Python-Dev] linuxaudiodev module
In-Reply-To: <14814.9199.422989.273484@bitdiddle.concentric.net>
Message-ID: <Pine.LNX.4.10.10010061609370.9837-100000@server1.lfw.org>

On Fri, 6 Oct 2000, Jeremy Hylton wrote:
> After reading the module and the OSS guide, it is clear to me that we
> need a complete re-write.  The module itself is just a wrapper around
> a bunch of read, write, and ioctl calls.  It could all be implemented
> in pure Python.

True.  I think your osslib is a good idea.  I wanted to take on this
sort of project myself a few weeks ago but never had the time to really
get started.  From playing with the test script, i think all we care
about having in C is audioop (and that's just for ulaw conversion).
I would like to fix audioop so we can expect it to be present as a
standard module; then we can have a module written in Python that
provides uniform sound support for all platforms.

> On my machine it still sounds awful, but at least the
> sound can be heard.

It should not sound awful.  If it sounds too loud and scratchy, then
maybe you need to use audioop to convert from Sun .au (ulaw) to raw
samples first.  This was the case with the Spanish inquisition clip.


-- ?!ng




From jeremy at beopen.com  Sat Oct  7 00:28:57 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Fri, 6 Oct 2000 18:28:57 -0400 (EDT)
Subject: [Python-Dev] linuxaudiodev module
In-Reply-To: <Pine.LNX.4.10.10010061609370.9837-100000@server1.lfw.org>
References: <14814.9199.422989.273484@bitdiddle.concentric.net>
	<Pine.LNX.4.10.10010061609370.9837-100000@server1.lfw.org>
Message-ID: <14814.21033.195290.728159@bitdiddle.concentric.net>

>>>>> "KPY" == Ka-Ping Yee <ping at lfw.org> writes:

  >> On my machine it still sounds awful, but at least the sound can
  >> be heard.

  KPY> It should not sound awful.  If it sounds too loud and scratchy,
  KPY> then maybe you need to use audioop to convert from Sun .au
  KPY> (ulaw) to raw samples first.  This was the case with the
  KPY> Spanish inquisition clip.

I don't think I know how to do that.  I tried using sox to convert
audiotest.au to audiotest.raw and it sounded just as bad on my
machine.  Perhaps I have my machine configured incorrectly, although
CDs and Real Audio sound fine.

Have you tried the new code, BTW?  Does the test work on your machine?

Jeremy



From tim_one at email.msn.com  Sat Oct  7 00:28:53 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Fri, 6 Oct 2000 18:28:53 -0400
Subject: [Python-Dev] test_StringIO broken
Message-ID: <LNBBLJKPBEHFEDALKOLCCEAMHKAA.tim_one@email.msn.com>

test test_StringIO failed -- Writing: "'abcde'", expected: 'abcdefg'
1 test failed: test_StringIO

This on Win98SE, broke sometime late this afternoon (EDT).  Working
elsewhere?





From jeremy at beopen.com  Sat Oct  7 00:59:41 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Fri, 6 Oct 2000 18:59:41 -0400 (EDT)
Subject: [Python-Dev] test_StringIO broken
In-Reply-To: <LNBBLJKPBEHFEDALKOLCCEAMHKAA.tim_one@email.msn.com>
References: <LNBBLJKPBEHFEDALKOLCCEAMHKAA.tim_one@email.msn.com>
Message-ID: <14814.22877.882280.651958@bitdiddle.concentric.net>

The test was changed in a number of ways, but whoever checked it in
didn't actually run the regression test!

Also, the last messsage I see printed is:
Failed to catch ValueError writing to closed StringIO.

This ain't a case of forgetting to generate new output.  This is just
plain wrong.

Jeremy



From thomas at xs4all.net  Sat Oct  7 00:56:08 2000
From: thomas at xs4all.net (Thomas Wouters)
Date: Sat, 7 Oct 2000 00:56:08 +0200
Subject: [Python-Dev] test_StringIO broken
In-Reply-To: <LNBBLJKPBEHFEDALKOLCCEAMHKAA.tim_one@email.msn.com>; from tim_one@email.msn.com on Fri, Oct 06, 2000 at 06:28:53PM -0400
References: <LNBBLJKPBEHFEDALKOLCCEAMHKAA.tim_one@email.msn.com>
Message-ID: <20001007005608.K12812@xs4all.nl>

On Fri, Oct 06, 2000 at 06:28:53PM -0400, Tim Peters wrote:
> test test_StringIO failed -- Writing: "'abcde'", expected: 'abcdefg'
> 1 test failed: test_StringIO

> This on Win98SE, broke sometime late this afternoon (EDT).  Working
> elsewhere?

No. Fails the same way on my Linux box. And the problem is probably that the
test was updated (two tests were uncommented) but the output file wasn't
updated. Jim Fulton did the checkin, so he looks like the right person to
fix it (and manually check that the generated output file is *correct*, of
course ! ;)

-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!



From DavidA at ActiveState.com  Sat Oct  7 01:01:37 2000
From: DavidA at ActiveState.com (David Ascher)
Date: Fri, 6 Oct 2000 16:01:37 -0700 (Pacific Daylight Time)
Subject: [Python-Dev] linuxaudiodev module
In-Reply-To: <14814.11771.731237.214646@bitdiddle.concentric.net>
Message-ID: <Pine.WNT.4.21.0010061600590.844-100000@loom>

> Okay.  I took a quick look.  It's really old (July 1997).  It looks
> like a more reasonable wrapping than linuxaudiodev, although I would
> want to review it more carefully against the OSS programmer's guide.
> 
> I would prefer a pure Python solution, because the code would be
> shorter and easier to read and maintain.  It may be, however, that the
> ossmodule is still up-to-date; if so, it may be easier to use it than
> to rewrite it.

Absolutely.  I just remember some announcement about it.  I suspect that
what I remember is not that old, so it may make sense to do a little more
digging than I did in the archives...

--david




From thomas at xs4all.net  Sat Oct  7 00:58:19 2000
From: thomas at xs4all.net (Thomas Wouters)
Date: Sat, 7 Oct 2000 00:58:19 +0200
Subject: [Python-Dev] test_StringIO broken
In-Reply-To: <14814.22877.882280.651958@bitdiddle.concentric.net>; from jeremy@beopen.com on Fri, Oct 06, 2000 at 06:59:41PM -0400
References: <LNBBLJKPBEHFEDALKOLCCEAMHKAA.tim_one@email.msn.com> <14814.22877.882280.651958@bitdiddle.concentric.net>
Message-ID: <20001007005819.L12812@xs4all.nl>

On Fri, Oct 06, 2000 at 06:59:41PM -0400, Jeremy Hylton wrote:

> Also, the last messsage I see printed is:
> Failed to catch ValueError writing to closed StringIO.

> This ain't a case of forgetting to generate new output.  This is just
> plain wrong.

Hm, are you sure you re-built your modules before doing that ? The output
looks okay on my linux box, in any case. The last message is 'Caught
expected ValueError writing to closed StringIO: I/O operation on closed
file', for me. If you recompiled cStringIO, something odd is going on ;)

-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!



From jeremy at beopen.com  Sat Oct  7 01:06:32 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Fri, 6 Oct 2000 19:06:32 -0400 (EDT)
Subject: [Python-Dev] test_StringIO broken
In-Reply-To: <20001007005819.L12812@xs4all.nl>
References: <LNBBLJKPBEHFEDALKOLCCEAMHKAA.tim_one@email.msn.com>
	<14814.22877.882280.651958@bitdiddle.concentric.net>
	<20001007005819.L12812@xs4all.nl>
Message-ID: <14814.23288.490631.990498@bitdiddle.concentric.net>

>>>>> "TW" == Thomas Wouters <thomas at xs4all.net> writes:

  TW> On Fri, Oct 06, 2000 at 06:59:41PM -0400, Jeremy Hylton wrote:
  >> Also, the last messsage I see printed is: Failed to catch
  >> ValueError writing to closed StringIO.

  >> This ain't a case of forgetting to generate new output.  This is
  >> just plain wrong.

  TW> Hm, are you sure you re-built your modules before doing that ?

This is probably what went wrong for me.

Jeremy



From guido at python.org  Sat Oct  7 15:51:12 2000
From: guido at python.org (Guido van Rossum)
Date: Sat, 07 Oct 2000 08:51:12 -0500
Subject: [Python-Dev] Tcl and Unicode
In-Reply-To: Your message of "Fri, 06 Oct 2000 16:09:03 MST."
             <200010062309.QAA32052@slayer.i.sourceforge.net> 
References: <200010062309.QAA32052@slayer.i.sourceforge.net> 
Message-ID: <200010071351.IAA02962@cj20424-a.reston1.va.home.com>

> Fix for next iteration of SF bug 115690 (Unicode headaches in IDLE).  The
> parsing functions in support of auto-indent weren't expecting Unicode
> strings, but text.get() can now return them (although it remains muddy as
> to exactly when or why that can happen).  Fixed that with a Big Hammer.

I apologize, I should have explained when text.get() returns Unicode:

Any string returned from Tcl/Tk that contains a byte with the 8th bit
set is translated from UTF-8 into Unicode, unless the translation
fails (in which case the original raw 8-bit string is returned as a
fallback).

This *should* be correct because Tcl/Tk always uses UTF-8 internally.
(Even though it is "lenient" when receiving strings -- if a sequence
of characters has no valid Unicode representation, it appears to falls
back to Latin-1; I don't know the details of this algorithm.)

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



From tim_one at email.msn.com  Sat Oct  7 20:43:55 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Sat, 7 Oct 2000 14:43:55 -0400
Subject: [Python-Dev] Tcl and Unicode
In-Reply-To: <200010071351.IAA02962@cj20424-a.reston1.va.home.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCMECEHKAA.tim_one@email.msn.com>

>> Fix for next iteration of SF bug 115690 (Unicode headaches in
>> IDLE). ...

[Guido]
> I apologize, I should have explained when text.get() returns Unicode:
>
> Any string returned from Tcl/Tk that contains a byte with the 8th bit
> set is translated from UTF-8 into Unicode, unless the translation
> fails (in which case the original raw 8-bit string is returned as a
> fallback).

Except that's *why* it was muddy <wink>:  in the specific case that popped
up in the bug, text.get() appeared to return a Unicode string of length 1
containing only a newline.  No high-bit byte appeared to be involved.
However, that was an illusion I didn't unmask until later.  All is clear
now.

> This *should* be correct because Tcl/Tk always uses UTF-8 internally.
> (Even though it is "lenient" when receiving strings -- if a sequence
> of characters has no valid Unicode representation, it appears to falls
> back to Latin-1; I don't know the details of this algorithm.)

Dunno, but wouldn't be surprised if they had a notion of default encoding,
and that it simply appears to be Latin-1 to us because American Windows uses
a superset of Latin-1.  If BeOpen would like to buy me a version of Chinese
Windows, happy to lend it to you <wink>.

as-american-as-they-come-ly y'rs  - tim





From guido at python.org  Sun Oct  8 03:41:11 2000
From: guido at python.org (Guido van Rossum)
Date: Sat, 07 Oct 2000 20:41:11 -0500
Subject: [Python-Dev] linuxaudiodev module
In-Reply-To: Your message of "Fri, 06 Oct 2000 18:28:57 -0400."
             <14814.21033.195290.728159@bitdiddle.concentric.net> 
References: <14814.9199.422989.273484@bitdiddle.concentric.net> <Pine.LNX.4.10.10010061609370.9837-100000@server1.lfw.org>  
            <14814.21033.195290.728159@bitdiddle.concentric.net> 
Message-ID: <200010080141.UAA19858@cj20424-a.reston1.va.home.com>

I think I fixed the linuxaudio test -- see if it sounds reasonable
now!

The crux of the matter seemed to be that the last, optional argument
to setparameters(), meaning "emulate the format if the sound card
doesn't support it", is not supported right.  It suppresses the error
message, and the ioctl to set the format succeeds, but the emulation
doesn't work (at least not on my system, or on Jeremy's).

So I've used a subterfuge: assuming most sound cards support signed
16-bit native-endian format, I convert the data to that format, and
use the appropriate format code: AFMT_S16_LE for little-endian
machines, AFMT_S16_BE for big-endian machines.  I've only tested
little-endian.

I use the new sys.byteorder variable to determine the endianness.

I use the audioop module to do the conversion.  Much simpler than sox!
(Oh feeling of nostalgia...  I wrote several of the file format
handlers for sox, and fixed lots of bugs in it too...  I even started
the audio file formats FAQ, now maintained by Chris Bagwell, who also
took over sox...)

Downside: test_linuxaudiodev will now be skipped if you don't have the
audioop enabled in your Setup file.  But that's fixed easily.

By the way -- the checkin freeze for the release candidate should go
in just about now...

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



From tim_one at email.msn.com  Sun Oct  8 12:32:36 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Sun, 8 Oct 2000 06:32:36 -0400
Subject: [Python-Dev] A standard lexer?
In-Reply-To: <00f201bfe475$d5e00c40$f2a6b5d4@hagrid>
Message-ID: <LNBBLJKPBEHFEDALKOLCAEDGHKAA.tim_one@email.msn.com>

Blast from the past!

[/F]
>         for phrase, action in lexicon:
>             p.append("(?:%s)(?P#%d)" % (phrase, len(p)))

[Tim]
> How about instead enhancing existing (?P<name>pattern) notation, to
> set a new match object attribute to name if & when pattern matches?
> Then arbitrary info associated with a named pattern can be gotten at
> via dicts via the pattern name, & the whole mess should be more
> readable.

[/F
 Sent: Sunday, July 02, 2000 6:35 PM]
> I just added "lastindex" and "lastgroup" attributes to the match object.
>
> "lastindex" is the integer index of the last matched capturing group,
> "lastgroup" the corresponding name (or None, if the group didn't have
> a name).  both attributes are None if no group were matched.

Reviewing this before 2.0 has been on my todo list for 3+ months, and
finally got to it.  Good show!  I converted some of my by-hand scanners to
use lastgroup, and like it a whole lot.  I know you understand why this is
Good, so here's a simple example of an "after" tokenizer for those who don't
(this one happens to tokenize REXX-like PARSE stmts):

import re
_token = re.compile(r"""
        (?P<space> \s+)
    |   (?P<var> [a-zA-Z_]\w*)
    |   (?P<dontcare> \.)
    |   (?P<number> \d+)
    |   (?P<punc> [-+=()])
    |   (?P<string> " [^"\\\n]* (?: \\. [^"\\\n]*)* "
        |           ' [^'\\\n]* (?: \\. [^'\\\n]*)* '
        )
""", re.VERBOSE).match
del re

(T_SPACE,
 T_VAR,
 T_DONTCARE,
 T_NUMBER,
 T_PUNC,
 T_STRING,
 T_EOF,
)           = range(7)

# For debug output.
_enum2name = ["T_SPACE",
              "T_VAR",
              "T_DONTCARE",
              "T_NUMBER",
              "T_PUNC",
              "T_STRING",
              "T_EOF",
             ]

_group2action = {
    "space":    (T_SPACE, None),
    "var":      (T_VAR, None),
    "dontcare": (T_DONTCARE, None),
    "number":   (T_NUMBER, int),
    "punc":     (T_PUNC, None),
    "string":   (T_STRING, eval),
}

def tokenize(s, tokeneater):
    i, n = 0, len(s)
    while i < n:
        m = _token(s, i)
        if not m:
            raise ParseError(s, i)
        group = m.lastgroup
        enum, action = _group2action[group]
        val = m.group(group)
        if action is not None:
            val = action(val)
        tokeneater(enum, val)
        i = m.end()
    tokeneater(T_EOF, None)

The tokenize function here used to be a mass of if/elif stmts trying to
figure out which group had matched.  Now it's all table-driven:  easier to
write, reuse & maintain, and quicker to boot.  +1.

the-aged-may-be-slow-but-they-never-forget<wink>-ly y'rs  - tim





From effbot at telia.com  Sun Oct  8 13:04:50 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Sun, 8 Oct 2000 13:04:50 +0200
Subject: [Python-Dev] Tcl and Unicode
References: <LNBBLJKPBEHFEDALKOLCMECEHKAA.tim_one@email.msn.com>
Message-ID: <016b01c03117$a3cb6a80$766940d5@hagrid>

guido:
> > This *should* be correct because Tcl/Tk always uses UTF-8 internally.
> > (Even though it is "lenient" when receiving strings -- if a sequence
> > of characters has no valid Unicode representation, it appears to falls
> > back to Latin-1; I don't know the details of this algorithm.)

Tcl/Tk uses a 16-bit (UCS-2) unicode string type internally, but
their 8-bit strings use UTF-8.

When converting from external 8-bit strings to unicode, they
convert valid UTF-8 sequences to unicode characters just like
Python, but "a lead-byte not followed by enough trail-bytes
represents itself." (in other words, it's cast from an unsigned
char to an unsigned short).

And the chance that any reasonable Latin-1 string would contain
a UTF-8 lead bytes followed by the right number of UTF-8 trail
bytes is close to zero...

(in case anyone wonders, Python's codec thinks that "close
to zero" isn't good enough, so it raises an exception instead)

tim:
> Dunno, but wouldn't be surprised if they had a notion of default encoding,
> and that it simply appears to be Latin-1 to us because American Windows uses
> a superset of Latin-1.

They have a system encoding, but it's not used here -- it's just
that Latin-1 is a subset of Unicode...

</F>




From thomas at xs4all.net  Sun Oct  8 13:14:33 2000
From: thomas at xs4all.net (Thomas Wouters)
Date: Sun, 8 Oct 2000 13:14:33 +0200
Subject: [Python-Dev] Release candidate
Message-ID: <20001008131433.M12812@xs4all.nl>

Is there any chance we can get the 'release candidate' released on the SF
File Module thingy as well ? Mailman uses this for the betas, for instance,
and I think it would attract that bit more attention to it. I believe the
'release' gets listed on various SF pages that way.

-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!



From barry at scottb.demon.co.uk  Sun Oct  8 16:36:45 2000
From: barry at scottb.demon.co.uk (Barry Scott)
Date: Sun, 8 Oct 2000 15:36:45 +0100
Subject: [Python-Dev] Python 2.0b2 note for Windows developers
In-Reply-To: <LNBBLJKPBEHFEDALKOLCCEILHIAA.tim_one@email.msn.com>
Message-ID: <000401c03135$2ebd4ec0$060210ac@private>

Tim,
	Two requests:

1. Can you ship the .PDB files for the debug images so devo's
   do not need to build the python sources to debug extensions.
   And Yes I know the .ZIP will be huge. If you want a
   compromise only include the .PDB for python20_d.dll.

2. Place the files into libs, pyd etc dirs. I had to extract
   the groups into the right places which is a bit tedious
   and error prone.

		BArry

> -----Original Message-----
> From: python-dev-admin at python.org [mailto:python-dev-admin at python.org]On
> Behalf Of Tim Peters
> Sent: 27 September 2000 23:40
> To: PythonDev; Python list
> Subject: [Python-Dev] Python 2.0b2 note for Windows developers
> 
> 
> Since most Python users on Windows don't have any use for them, I trimmed
> the Python 2.0b2 installer by leaving out the debug-build .lib, .pyd, .exe
> and .dll files.  If you want them, they're available in a separate zip
> archive; read the Windows Users notes at
> 
> http://www.pythonlabs.com/products/python2.0/download_python2.0b2.html
> 
> for info and a download link.  If you don't already know *why* you might
> want them, trust me:  you don't want them <wink>.
> 
> they-don't-even-make-good-paperweights-ly y'rs  - tim
> 
> 
> 
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://www.python.org/mailman/listinfo/python-dev
> 



From ping at lfw.org  Sun Oct  8 20:19:51 2000
From: ping at lfw.org (Ka-Ping Yee)
Date: Sun, 8 Oct 2000 11:19:51 -0700 (PDT)
Subject: [Python-Dev] linuxaudiodev module
In-Reply-To: <14814.21033.195290.728159@bitdiddle.concentric.net>
Message-ID: <Pine.LNX.4.10.10010081109230.454-100000@skuld.kingmanhall.org>

On Fri, 6 Oct 2000, Jeremy Hylton wrote:
> 
> Have you tried the new code, BTW?  Does the test work on your machine?

Works okay (i updated after Guido's last edit).  Sounds fine to me.

But it bugs me that some of the descriptions say "audio" and others say
"format".  This seems arbitrary -- is there a reason?

Excerpt of Modules/linuxaudiodev.c:
    {  8, ??????AFMT_MU_LAW, "Logarithmic mu-law audio" },
    {  8, ??????AFMT_A_LAW,  "Logarithmic A-law audio" },
    {  8,???????AFMT_U8,     "Standard unsigned 8-bit audio" },
    {  8, ??????AFMT_S8,     "Standard signed 8-bit audio" },
    { 16, ??????AFMT_U16_BE, "Big-endian 16-bit unsigned format" },
    { 16, ??????AFMT_U16_LE, "Little-endian 16-bit unsigned format" },
    { 16, ??????AFMT_S16_BE, "Big-endian 16-bit signed format" },
    { 16, ??????AFMT_S16_LE, "Little-endian 16-bit signed format" },

If you don't mind, i'd prefer something like:
    {  8, ??????AFMT_MU_LAW, "logarithmic mu-law 8-bit audio" },
    {  8, ??????AFMT_A_LAW,  "logarithmic A-law 8-bit audio" },
    {  8,???????AFMT_U8,     "linear unsigned 8-bit audio" },
    {  8, ??????AFMT_S8,     "linear signed 8-bit audio" },
    { 16, ??????AFMT_U16_BE, "linear unsigned 16-bit big-endian audio" },
    { 16, ??????AFMT_U16_LE, "linear unsigned 16-bit little-endian audio" },
    { 16, ??????AFMT_S16_BE, "linear signed 16-bit big-endian audio" },
    { 16, ??????AFMT_S16_LE, "linear signed 16-bit little-endian audio" },

The above conforms to:

    <format> <width> "audio"

    where <format> ::= "logarithmic" ("mu-law" | "A-law") |
                       "linear" ("unsigned" | "signed")

          <width> ::= "8-bit" | "16-bit" ("big-endian" | "little-endian")


-- ?!ng

"Simple, yet complex."
    -- Lenore Snell




From tim_one at email.msn.com  Sun Oct  8 21:28:55 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Sun, 8 Oct 2000 15:28:55 -0400
Subject: [Python-Dev] Python 2.0b2 note for Windows developers
In-Reply-To: <000401c03135$2ebd4ec0$060210ac@private>
Message-ID: <LNBBLJKPBEHFEDALKOLCGEEEHKAA.tim_one@email.msn.com>

[Barry]
> 	Two requests:
>
> 1. Can you ship the .PDB files for the debug images so devo's
>    do not need to build the python sources to debug extensions.
>    And Yes I know the .ZIP will be huge. If you want a
>    compromise only include the .PDB for python20_d.dll.

Sure!  Most .pdb files are highly compressible, and the zip size hit isn't
anything to worry about.

> 2. Place the files into libs, pyd etc dirs. I had to extract
>    the groups into the right places which is a bit tedious
>    and error prone.

No.  If you want a directory structure that doesn't match the actual build
directory structure, I can't read your mind, and have no reason to believe
that the specific artificial structure you have in mind is of use to anyone
but you.  Don't be so helpless <wink>:  write a tiny Python script to move
the files where you want them after unpacking.  What I upload will be an
exact image of the build directory structure.  Most feedback I've gotten is
that people want exactly that, because they *want* to compile Python
themselves and just want to avoid jumping thru all the snaky hoops needed to
compile the 3rd-party subprojects (from _tkinter to zlib).

alphabetically y'rs  - tim





From guido at python.org  Sun Oct  8 22:52:54 2000
From: guido at python.org (Guido van Rossum)
Date: Sun, 08 Oct 2000 15:52:54 -0500
Subject: [Python-Dev] linuxaudiodev module
In-Reply-To: Your message of "Sun, 08 Oct 2000 11:19:51 MST."
             <Pine.LNX.4.10.10010081109230.454-100000@skuld.kingmanhall.org> 
References: <Pine.LNX.4.10.10010081109230.454-100000@skuld.kingmanhall.org> 
Message-ID: <200010082052.PAA27119@cj20424-a.reston1.va.home.com>

> But it bugs me that some of the descriptions say "audio" and others say
> "format".  This seems arbitrary -- is there a reason?

Okay, you're right.  (But there are sooooo many other things wrong
with the code still...  E.g. the bogus reference to "ctl". :-( )

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



From paul at prescod.net  Mon Oct  9 08:04:55 2000
From: paul at prescod.net (Paul Prescod)
Date: Sun, 08 Oct 2000 23:04:55 -0700
Subject: [Python-Dev] A standard lexer?
References: <LNBBLJKPBEHFEDALKOLCAEDGHKAA.tim_one@email.msn.com>
Message-ID: <39E16007.5F1DDF9A@prescod.net>

Tim Peters wrote:
> 
> ...
> 
> Reviewing this before 2.0 has been on my todo list for 3+ months, and
> finally got to it.  Good show!  I converted some of my by-hand scanners to
> use lastgroup, and like it a whole lot.  I know you understand why this is
> Good, so here's a simple example of an "after" tokenizer for those who don't
> (this one happens to tokenize REXX-like PARSE stmts):

Is there a standard technique for taking a regexp like this and applying
it to data fed in a little at a time? Other than buffering the data
forever? That's something else I would like in a "standard Python
lexer", if that's the goal.

-- 
 Paul Prescod - Not encumbered by corporate consensus
Simplicity does not precede complexity, but follows it. 
	- http://www.cs.yale.edu/homes/perlis-alan/quotes.html



From guido at beopen.com  Thu Oct  5 15:16:14 2000
From: guido at beopen.com (Guido van Rossum)
Date: Thu, 5 Oct 2000 09:16:14 -0400
Subject: [Python-Dev] htmllib.HTMLescape()
References: <200010042031.WAA17378@pandora.informatik.hu-berlin.de>
Message-ID: <000701c031f4$59507440$7aa41718@reston1.va.home.com>

Note that cgi.escape() does this too.

--Guido

----- Original Message ----- 
From: "Martin von Loewis" <loewis at informatik.hu-berlin.de>
To: <aahz at panix.com>
Cc: <python-dev at python.org>
Sent: Wednesday, October 04, 2000 4:31 PM
Subject: [Python-Dev] htmllib.HTMLescape()


> > Someone just pointed out on c.l.py that we need an HTMLescape()
> > function that takes a string and converts special characters to
> > entities.  I'm not on python-dev, so could you please forward this
> > and find out whether I need to run a PEP?
> 
> Doesn't xml.sax.saxutils.escape do what you want (together with
> htmlentitydefs)? I was going to say that this is quite a small change
> to warrant a PEP - but there are two obvious approaches (working from
> scratch, or working on top of xml.sax.saxutils.escape - perhaps
> modifying and relocating that function), so *some* design probably
> needs to be recorded in a PEP.
> 
> Regards,
> Martin
> 
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://www.python.org/mailman/listinfo/python-dev
> 




From loewis at informatik.hu-berlin.de  Mon Oct  9 16:01:10 2000
From: loewis at informatik.hu-berlin.de (Martin von Loewis)
Date: Mon, 9 Oct 2000 16:01:10 +0200 (MET DST)
Subject: [Python-Dev] htmllib.HTMLescape()
In-Reply-To: <000701c031f4$59507440$7aa41718@reston1.va.home.com>
	(guido@beopen.com)
References: <200010042031.WAA17378@pandora.informatik.hu-berlin.de> <000701c031f4$59507440$7aa41718@reston1.va.home.com>
Message-ID: <200010091401.QAA21515@pandora.informatik.hu-berlin.de>

> Note that cgi.escape() does this too.

Indeed. That justifies a PEP that proposes to concentrate the
functionality in one place, deprecating the other places.

One approach would be to enhance the codec facilites, so that
"string".encode("iso-entities") becomes possible - but that is already
in the middle of discussing the PEP.

Regards,
Martin



From jeremy at beopen.com  Mon Oct  9 16:35:48 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Mon, 9 Oct 2000 10:35:48 -0400 (EDT)
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules zlibmodule.c,2.35,2.36
In-Reply-To: <200010091418.HAA08765@slayer.i.sourceforge.net>
References: <200010091418.HAA08765@slayer.i.sourceforge.net>
Message-ID: <14817.55236.288126.338665@bitdiddle.concentric.net>

Thanks.  I didn't get to it on Friday.

Jeremy



From trentm at ActiveState.com  Tue Oct 10 00:56:00 2000
From: trentm at ActiveState.com (Trent Mick)
Date: Mon, 9 Oct 2000 15:56:00 -0700
Subject: [Python-Dev] test_sre.py fails on Win64 because PyOS_CheckStack *never* fails
In-Reply-To: <000b01c02e4c$2ac63980$766940d5@hagrid>; from effbot@telia.com on Wed, Oct 04, 2000 at 11:43:41PM +0200
References: <20001004141737.A16659@ActiveState.com> <000b01c02e4c$2ac63980$766940d5@hagrid>
Message-ID: <20001009155600.A27929@ActiveState.com>

[Trent notes that PyOS_CheckStack never fails on Win64 hence test_[s]re.py
    fail on the overflow checks]

[Fredrik gives me a simple test C program to test PyOS_CHeckStack
    independently (The test program is included at the bottom of this
    email.)]

SOrry I took so long to reply to this but I spent a little bit of time
playing with PyOS_CheckStack on Win32 and Win64 and I am now just frustrated.
Here is what I found:

- The simple test program shows that PyOS_CheckStack will fire as intended
  on both Win32 and Win64 with either Visual C's default optimization OR no
  optimization.
- The simple test program will *not* fire as intended with the '-O2'
  optimization which Python *does* use for pythonrun.c (where
  PyOS_CheckStack lives). So, likely the '-O2' optimization will
  optimize-away the _alloca() call. Fine. But why then does it *not* get
  optimized away when pythonrun.c is compiled? Does the context around other
  code in the same file affect that optimization?
- When I apply this patch to _sre.c on *Win32* (basically the same test as
  the test file that Fredrik gave me to try) the "callme(0)" call *never*
  returns -- infinite loop. Note that this happens on the Release *and* Debug
  builds so nothing is being optimized away.

***************
*** 560,565 ****
--- 560,569 ----
  }
  #endif

+
+
+ void callme(int i);
+
  LOCAL(int)
  SRE_MATCH(SRE_STATE* state, SRE_CODE* pattern, int level)
  {
***************
*** 578,583 ****
--- 582,588 ----
      TRACE(("|%p|%p|ENTER %d\n", pattern, ptr, level));

  #if defined(USE_STACKCHECK)
+     callme(0);
      if (level % 10 == 0 && PyOS_CheckStack())
          return SRE_ERROR_RECURSION_LIMIT;
  #endif
***************
*** 2337,2340 ****
--- 2342,2357 ----
      Py_InitModule("_" MODULE, _functions);
  }

+ void callme(int i)
+ {
+     char buf[100000];
+     if (PyOS_CheckStack())
+         return;
+     printf("%d\n", i);
+     memset(buf, 0, sizeof buf);
+     callme(i+1);
+ }
+
+
+
  #endif /* !defined(SRE_RECURSIVE) */

- I am not smart enough and/or (you decide :) do not have the inclination to
  figure this out (i.e. start looking at assembly code) just so _sre can use
  stack checking instead of the existing RECURSION_LIMIT framework (albeit
  the limited general usefullness of this) on Win64 so that test_sre.py can
  pass.

  Would it be alright for me to apply:


*** python/dist/src/Include/pythonrun.h       Sat Sep 16 09:31:31 2000
--- python/dist/src/Include/pythonrun.h  Sun Oct  8 10:20:02 2000
***************
*** 88,94 ****
     to a 8k margin. */
  #define PYOS_STACK_MARGIN 2048

! #if defined(WIN32) && defined(_MSC_VER)
  /* Enable stack checking under Microsoft C */
  #define USE_STACKCHECK
  #endif
--- 88,94 ----
     to a 8k margin. */
  #define PYOS_STACK_MARGIN 2048

! #if defined(WIN32) && !defined(MS_WIN64) && defined(_MSC_VER)
  /* Enable stack checking under Microsoft C */
  #define USE_STACKCHECK
  #endif


  to disable stack checking on Win64 until Win64 become more mainstream and
  others can bang away at this? The important thing, I would think, is
  getting the test suite passing for Python 2.0.


------- test file mentioned above --------------------------------
#include <malloc.h>
#include <excpt.h>

int __inline
PyOS_CheckStack()
{
    __try {
        _alloca(100000);
        return 0;
    } __except (EXCEPTION_EXECUTE_HANDLER) {
        /* just ignore all errors */
    }
    return 1;
}

void
callme(int i)
{
    char buf[100000];
    if (PyOS_CheckStack())
        return;
    printf("%d\n", i);
    memset(buf, 0, sizeof buf);
    callme(i+1);
}

int
main()
{
    callme(0);
}
-----------------------------------------------------


-- 
Trent Mick
TrentM at ActiveState.com



From jeremy at beopen.com  Tue Oct 10 02:26:27 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Mon, 9 Oct 2000 20:26:27 -0400 (EDT)
Subject: [Python-Dev] Pre-release copies of the 2.0c1 source tarball
Message-ID: <14818.25139.747635.586267@bitdiddle.concentric.net>

I have placed pre-release copies of the 2.0 release candidate 1 source
tarballs at ftp://python.beopen.com/pub/python/2.0c1/.  We reserve the
right two change these without notice prior to the official release
:-).

Jeremy



From nas at arctrix.com  Mon Oct  9 21:06:08 2000
From: nas at arctrix.com (Neil Schemenauer)
Date: Mon, 9 Oct 2000 12:06:08 -0700
Subject: [Python-Dev] test_import failing
Message-ID: <20001009120608.A13588@glacier.fnational.com>

I assume the CVS sources are basicly the same as 2.0c1.  Anyhow,
test_import is failing on my Debian machine.  The script is
creating "@test.py" and then trying to import it.  "." is not in
sys.path for some reason.

  Neil



From jeremy at beopen.com  Tue Oct 10 04:17:31 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Mon, 9 Oct 2000 22:17:31 -0400 (EDT)
Subject: [Python-Dev] Re: test_import failing
In-Reply-To: <20001009120608.A13588@glacier.fnational.com>
References: <20001009120608.A13588@glacier.fnational.com>
Message-ID: <14818.31803.227516.852814@bitdiddle.concentric.net>

I assume that you are running the test some way other than using 
"make test."  It seems that make test executes python this way --
PYTHONPATH= ./python
-- which causes the current directory to be added to the path.
If you run python without having the current directory on your path
test_import file fail.

Unless you are having a different problem, this isn't important enough
to fix in 2.0c1, although it seems good to fix for 2.0 final.

Jeremy

PS We have left GC turned on by default in 2.0c1 and plan to do the
same for 2.0 final.




From fdrake at beopen.com  Tue Oct 10 04:09:34 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Mon, 9 Oct 2000 22:09:34 -0400 (EDT)
Subject: [Python-Dev] test_import failing
In-Reply-To: <20001009120608.A13588@glacier.fnational.com>
References: <20001009120608.A13588@glacier.fnational.com>
Message-ID: <14818.31326.292172.223405@cj42289-a.reston1.va.home.com>

Neil Schemenauer writes:
 > I assume the CVS sources are basicly the same as 2.0c1.  Anyhow,
 > test_import is failing on my Debian machine.  The script is
 > creating "@test.py" and then trying to import it.  "." is not in
 > sys.path for some reason.

  Jeremy & I finally figured this out.  "make test" runs python with
PYTHONPATH set to '' (an empty string).  This is decidedly different
from running with PYTHONPATH unset (I consider this a bug that should
be fixed in 2.1).
  The empty string is interpreted as the current directory (as
expected), so running "make test" adds the current directory to
sys.path, but running the regression test (test_import or regrtest) as
a script does not.
  We decided not to fix this now, since it's too late to be sure it's
the right change, and adjusting the test case also means a very late
change.  So whoever runs the tests is responsible for making sure the
current directory is on sys.path.  (*Really* bogus!)


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From fdrake at beopen.com  Tue Oct 10 04:20:11 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Mon, 9 Oct 2000 22:20:11 -0400 (EDT)
Subject: [Python-Dev] Re: test_import failing
In-Reply-To: <14818.31803.227516.852814@bitdiddle.concentric.net>
References: <20001009120608.A13588@glacier.fnational.com>
	<14818.31803.227516.852814@bitdiddle.concentric.net>
Message-ID: <14818.31963.385267.336885@cj42289-a.reston1.va.home.com>

Jeremy Hylton writes:
 > Unless you are having a different problem, this isn't important enough
 > to fix in 2.0c1, although it seems good to fix for 2.0 final.

  And it's questionable how many bugs are hiding here as well.  I
count two:

  - test_import.py assumes the current directory is on the path; this
    is just plain fragile, and should explicitly pick the directory
    off of test_support.TESTFN, and add it to sys.path for the
    duration of the test (which does indeed fix this bug)

  - Modules/getpath.c interprets an empty definition of $PYTHONPATH as
    adding '' to sys.path, where I assert it should not add anything
    to sys.path.  Everywhere else I've recall seeing an environment
    variable used as a data source, the test is done like this:

    char *cp = getenv("VARIABLE");
    if (cp != NULL && cp[0] != '\0') {
        ...
    }

    (with some spelling variations).


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From jeremy at beopen.com  Tue Oct 10 08:52:48 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Mon, 9 Oct 2000 23:52:48 -0700 (PDT)
Subject: [Python-Dev] Python 2.0 release candidate 1
Message-ID: <200010100652.XAA74600@python.beopen.com>

Python 2.0c1 is released.  The BeOpen PythonLabs and our cast of
SourceForge volunteers have fixed many bugs since the beta releases
last month.  Please pick up the new release at

    http://www.pythonlabs.com/products/python2.0/

There's a tarball, a Windows installer, RedHat RPMs, online
documentation, and a long list of fixed bugs.

The final release of Python 2.0 will be next week.  We would
appreciate feedback on the release candidate in order to fix any
remaining bugs before the final release.  Confirmation of build and
test success on less common platforms is also helpful.n

All major reported bugs have been fixed in the release candidate.  We
do not plan to make any changes between now and the final release,
except to fix bugs reported in the next week.  We encourage potential
users of Python 2.0 to try the release candidate with their programs
and report any remaining bugs.

To report a new bug, use the SourceForge bug tracker
http://sourceforge.net/bugs/?func=addbug&group_id=5470

Python 2.0 has many new features, including the following:

  - Augmented assignment, e.g. x += 1
  - List comprehensions, e.g. [x**2 for x in range(10)]
  - Extended import statement, e.g. import Module as Name
  - Extended print statement, e.g. print >> file, "Hello"
  - Collection of cyclical garbage

For a fuller discussion of the changes in Python 2.0, please see the
article "What's New in Python 2.0" by Andrew Kuchling and Moshe Zadke:
http://starship.python.net/crew/amk/python/writing/new-python/

-- Jeremy Hylton <http://www.python.org/~jeremy/>




From tismer at appliedbiometrics.com  Tue Oct 10 12:33:36 2000
From: tismer at appliedbiometrics.com (Christian Tismer)
Date: Tue, 10 Oct 2000 13:33:36 +0300
Subject: [Python-Dev] Stackless Python 1.2 + Continuations 0.9
Message-ID: <39E2F080.86ED1DA3@appliedbiometrics.com>

ANNOUNCING:

               Stackless Python 1.2
           A Python Implementation That
             Does Not Use The C Stack

               * plus the real toy *

              Continuation Module 0.9
        Continuations as First Class Objects
            with support for MicroThreads

What is it?
A plugin-replacement for core Python.
It should run any program which runs under Python 1.5.2 .
But it does not need space on the C stack.

For further info, see the new site at 
   
              http://www.stackless.com

You might also want to join the mailing list at

     http://starship.python.net/mailman/listinfo/stackless

Major changes in this release:
Extra reference counting reduces continuation frame creation
Better exception handling avoids cycles.

Next to come:
- A port to Python 2.0 will be the first thing to do.
- Long-term project is a complete redesign and
  rewrite for inclusion with Python 2.1

ciao - Christian Tismer / Mission Impossible 5oftware Team

<P><A HREF="http://www.tismer.com/research/stackless/">Stackless
Python 1.2 + Continuations 0.9</A> - a version of Python 1.5.2 that
does not need space on the C stack, first-class callable
continuation objects for Python, and Microthread-support. 
(10-Oct-2000)
</P>

-- 
http://www.python.org/mailman/listinfo/python-list



From guido at python.org  Tue Oct 10 15:04:39 2000
From: guido at python.org (Guido van Rossum)
Date: Tue, 10 Oct 2000 08:04:39 -0500
Subject: [Python-Dev] test_import failing
In-Reply-To: Your message of "Mon, 09 Oct 2000 22:09:34 -0400."
             <14818.31326.292172.223405@cj42289-a.reston1.va.home.com> 
References: <20001009120608.A13588@glacier.fnational.com>  
            <14818.31326.292172.223405@cj42289-a.reston1.va.home.com> 
Message-ID: <200010101304.IAA13010@cj20424-a.reston1.va.home.com>

> Neil Schemenauer writes:
>  > I assume the CVS sources are basicly the same as 2.0c1.  Anyhow,
>  > test_import is failing on my Debian machine.  The script is
>  > creating "@test.py" and then trying to import it.  "." is not in
>  > sys.path for some reason.
> 
>   Jeremy & I finally figured this out.  "make test" runs python with
> PYTHONPATH set to '' (an empty string).  This is decidedly different
> from running with PYTHONPATH unset (I consider this a bug that should
> be fixed in 2.1).
>   The empty string is interpreted as the current directory (as
> expected), so running "make test" adds the current directory to
> sys.path, but running the regression test (test_import or regrtest) as
> a script does not.
>   We decided not to fix this now, since it's too late to be sure it's
> the right change, and adjusting the test case also means a very late
> change.  So whoever runs the tests is responsible for making sure the
> current directory is on sys.path.  (*Really* bogus!)

Proper fix, which I will check in momentarily: put

    import sys
    sys.path.insert(0, os.curdir)

in front of test_import.py; and add

    del sys.path[0]

to the end.

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



From guido at python.org  Tue Oct 10 15:06:54 2000
From: guido at python.org (Guido van Rossum)
Date: Tue, 10 Oct 2000 08:06:54 -0500
Subject: [Python-Dev] Re: test_import failing
In-Reply-To: Your message of "Mon, 09 Oct 2000 22:20:11 -0400."
             <14818.31963.385267.336885@cj42289-a.reston1.va.home.com> 
References: <20001009120608.A13588@glacier.fnational.com> <14818.31803.227516.852814@bitdiddle.concentric.net>  
            <14818.31963.385267.336885@cj42289-a.reston1.va.home.com> 
Message-ID: <200010101306.IAA13031@cj20424-a.reston1.va.home.com>

>   And it's questionable how many bugs are hiding here as well.  I
> count two:
> 
>   - test_import.py assumes the current directory is on the path; this
>     is just plain fragile, and should explicitly pick the directory
>     off of test_support.TESTFN, and add it to sys.path for the
>     duration of the test (which does indeed fix this bug)

I'll fix this.

>   - Modules/getpath.c interprets an empty definition of $PYTHONPATH as
>     adding '' to sys.path, where I assert it should not add anything
>     to sys.path.  Everywhere else I've recall seeing an environment
>     variable used as a data source, the test is done like this:
> 
>     char *cp = getenv("VARIABLE");
>     if (cp != NULL && cp[0] != '\0') {
>         ...
>     }
> 
>     (with some spelling variations).

Agreed, but please *don't fix this in 2.0!*

Who knows how many other hidden bugs (in 3rd party code) this will
trigger...

OK to fix it after 2.0final is released.

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



From mal at lemburg.com  Tue Oct 10 14:58:09 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Tue, 10 Oct 2000 14:58:09 +0200
Subject: [Python-Dev] LICENSE file in Python 2.0c1
Message-ID: <39E31261.166F1601@lemburg.com>

I've just had a glance at the releas candidate 1. The file LICENSE
has grown somewhat, but not as much as I feared... looking
at the contents I find the following as only reference to the
CNRI license (which holds all the surprises we talked about in
the early beta stages):

"""
CNRI OPEN SOURCE LICENSE AGREEMENT
----------------------------------

Python 1.6 is made available subject to the terms and conditions in
CNRI's License Agreement.  This Agreement together with Python 1.6 may
be located on the Internet using the following unique, persistent
identifier (known as a handle): 1895.22/1012.  This Agreement may also
be obtained from a proxy server on the Internet using the following
URL: http://hdl.handle.net/1895.22/1012.
"""

Such a note is nice and short, but not legally binding and 
confusing since it is not clear whether the "handle" for the
document will always return the same license text or if it
will return a license text at all.

It would be more appropriate to include the original CNRI license
text, IMHO. Or is there some hidden motivation behind using the
handle ?

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From thomas.heller at ion-tof.com  Tue Oct 10 15:06:05 2000
From: thomas.heller at ion-tof.com (Thomas Heller)
Date: Tue, 10 Oct 2000 15:06:05 +0200
Subject: [Python-Dev] distutils and bdist_wininst confusion: clarification
Message-ID: <01be01c032ba$dc889ba0$4500a8c0@thomasnotebook>

There has been some confusion about distutils, especially the
bdist_wininst command.
I hope I can clarify these things with this post.

1. The current Distutils version 1.0, which is also
   included in the Python 2.0 release candidate is perfectly
   usable apart from one bug:
   You should create windows installers (by running
   'setup.py bdist_wininst' or 'setup.py bdist --formats=wininst')
   ONLY with an external zip utility (info-zip would do).
   Using the zipfile module results in corrupted installations
   (all files are created with zero length).
   Details about the cause for this can be found in the patch
   I posted to SF.


2. I submitted a patch to SF
   http://sourceforge.net/patch/?func=detailpatch&patch_id=101844&group_id=5470
   which corrects this bug.
   Normally I would have checked this code in immediately,
   because it is in _my_ code, and that's what my checkin rights
   are for ;-).
   I did not because I did not want to interfere with the release process of
   python 2.0 rc 1.


3. How does bdist_wininst work?
   bdist_wininst creates a self-extracting zipfile from two
   components: a stub program (wininst.exe) plus a zip-file
   containing the code to be distributed. Because I did not
   liked wininst.exe as binary file checked in into CVS,
   the actual bytes of this exe are included base64-encoded
   in the bdist_wininst.py module as string. I'm not sure
   whether this is a wise design or not, but that is a different
   topic.
   The downside of this design is that when the source to 
   wininst.exe changes, it must be recompiled, and bdist_wininst.py
   must be regenerated. The context-diffs for bdist_wininst.py
   are so very large.


4. To understand the patch, you should know the following:
   Distutils is a separate toplevel module in the repository
   on sourceforge. Parts of this repository are symbolically
   linked somewhere into the python tree. Thus, this patch must
   be applied to the distutils _module_ in the repository.

   Distutils directory structure is as follows:

   distutils
     dd
     distutils
       command
     doc
       dist
       inst
     examples
       sample1
       sample2
       sample3
     misc
     test
     text

   Relevant part of python directory structure:

   python
     dist
       src
         Lib
           distutils
             command

   The source code for wininst.exe is in CVS in the distutils/misc
   directory.
   The patch I posted to SF does not include the compiled
   wininst.exe, neither does it include the (regenerated)
   bdist_wininst.py module.

5. If nobody objects, I will check in the changes I made tomorrow, recompile
   the exe, regenerate the bdist_wininst.py, and everything should be
   fine again.
   Greg will then hopefully, when he is back, increase the distutils version
   number to 1.0.1 (or whatever) and this version will then be delivered with
   python 2.0 final.

Sorry for the confusion.

Cheers,

Thomas






From guido at python.org  Tue Oct 10 16:36:57 2000
From: guido at python.org (Guido van Rossum)
Date: Tue, 10 Oct 2000 09:36:57 -0500
Subject: [Python-Dev] LICENSE file in Python 2.0c1
In-Reply-To: Your message of "Tue, 10 Oct 2000 14:58:09 +0200."
             <39E31261.166F1601@lemburg.com> 
References: <39E31261.166F1601@lemburg.com> 
Message-ID: <200010101436.JAA13237@cj20424-a.reston1.va.home.com>

> I've just had a glance at the releas candidate 1. The file LICENSE
> has grown somewhat, but not as much as I feared...

Since when?  It hasn't changed since it was first released, for 2.0b1.

> looking
> at the contents I find the following as only reference to the
> CNRI license (which holds all the surprises we talked about in
> the early beta stages):
> 
> """
> CNRI OPEN SOURCE LICENSE AGREEMENT
> ----------------------------------
> 
> Python 1.6 is made available subject to the terms and conditions in
> CNRI's License Agreement.  This Agreement together with Python 1.6 may
> be located on the Internet using the following unique, persistent
> identifier (known as a handle): 1895.22/1012.  This Agreement may also
> be obtained from a proxy server on the Internet using the following
> URL: http://hdl.handle.net/1895.22/1012.
> """
> 
> Such a note is nice and short, but not legally binding and 
> confusing since it is not clear whether the "handle" for the
> document will always return the same license text or if it
> will return a license text at all.

Why do you say it's not legally binding?  The CNRI license explicitly
allows you to use this exact text instead of including the whole CNRI
license.

> It would be more appropriate to include the original CNRI license
> text, IMHO. Or is there some hidden motivation behind using the
> handle ?

I was just trying to save space.  ActivePython does the same thing as
far as I remember.

BTW, I haven't heard from CNRI in two weeks, but the last thing I
heard from them was that their lawyers had talked to Stallman's lawyer
and that they were optimistic about a successful resolution.

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



From guido at python.org  Tue Oct 10 16:41:50 2000
From: guido at python.org (Guido van Rossum)
Date: Tue, 10 Oct 2000 09:41:50 -0500
Subject: [Python-Dev] distutils and bdist_wininst confusion: clarification
In-Reply-To: Your message of "Tue, 10 Oct 2000 15:06:05 +0200."
             <01be01c032ba$dc889ba0$4500a8c0@thomasnotebook> 
References: <01be01c032ba$dc889ba0$4500a8c0@thomasnotebook> 
Message-ID: <200010101441.JAA13276@cj20424-a.reston1.va.home.com>

Thomas, thanks for the explanation.  I agree that you can check in the
changes yourself as you proposed.

There's one issue I still don't understand (not having the time to
read the full distutils docs): how does a typical Windows developer
decide whether to use an external zip utility or the zipfile module?

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



From thomas.heller at ion-tof.com  Tue Oct 10 15:58:32 2000
From: thomas.heller at ion-tof.com (Thomas Heller)
Date: Tue, 10 Oct 2000 15:58:32 +0200
Subject: [Python-Dev] distutils and bdist_wininst confusion: clarification
References: <01be01c032ba$dc889ba0$4500a8c0@thomasnotebook>  <200010101441.JAA13276@cj20424-a.reston1.va.home.com>
Message-ID: <020001c032c2$3060fa40$4500a8c0@thomasnotebook>

> Thomas, thanks for the explanation.  I agree that you can check in the
> changes yourself as you proposed.
> 
> There's one issue I still don't understand (not having the time to
> read the full distutils docs): how does a typical Windows developer
> decide whether to use an external zip utility or the zipfile module?
I'm afraid it is not documented.

Distutils first tries to spawn an external zip program,
then tries the zipfile module, if nothing is found,
a warning is issued.

So, the windows developer currently _must_ install zip.exe
somewhere in the path. (As often, the default is wrong,
because a zip utility is not included in windows).

Thomas




From mal at lemburg.com  Tue Oct 10 16:03:14 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Tue, 10 Oct 2000 16:03:14 +0200
Subject: [Python-Dev] LICENSE file in Python 2.0c1
References: <39E31261.166F1601@lemburg.com> <200010101436.JAA13237@cj20424-a.reston1.va.home.com>
Message-ID: <39E321A2.2BD99E35@lemburg.com>

Guido van Rossum wrote:
> 
> > I've just had a glance at the releas candidate 1. The file LICENSE
> > has grown somewhat, but not as much as I feared...
> 
> Since when?  It hasn't changed since it was first released, for 2.0b1.

Since the old 1.5.2 LICENSE file.
 
> > looking
> > at the contents I find the following as only reference to the
> > CNRI license (which holds all the surprises we talked about in
> > the early beta stages):
> >
> > """
> > CNRI OPEN SOURCE LICENSE AGREEMENT
> > ----------------------------------
> >
> > Python 1.6 is made available subject to the terms and conditions in
> > CNRI's License Agreement.  This Agreement together with Python 1.6 may
> > be located on the Internet using the following unique, persistent
> > identifier (known as a handle): 1895.22/1012.  This Agreement may also
> > be obtained from a proxy server on the Internet using the following
> > URL: http://hdl.handle.net/1895.22/1012.
> > """
> >
> > Such a note is nice and short, but not legally binding and
> > confusing since it is not clear whether the "handle" for the
> > document will always return the same license text or if it
> > will return a license text at all.
> 
> Why do you say it's not legally binding?  The CNRI license explicitly
> allows you to use this exact text instead of including the whole CNRI
> license.

Sure, but not including the verbatim text will produce an
unpleasent feeling of not being sure about the completeness
of the license text.

<nitpicker-suite>

In a law suit the above construct would
certainly not hold, since URLs only describe the location of
information and don't hold any information about the validity
or origin of it. The situation would be a little better if CNRI
had provided a PGP signature or fingerprint of the license,
since this is (in some countries) a legally accepted way of
determining those two criteria.

Just a side note: the URL given for the license results in a 
redirect to a different URL -
http://www.handle.net/python_licenses/python1.6_9-5-00.html
(note the date !): this doesn't really give the impression of
persistent unchangeable information.

</nitpicker-suite>

Not that there's much to fear about... but why add any extra areas
of uncertainty ?

> > It would be more appropriate to include the original CNRI license
> > text, IMHO. Or is there some hidden motivation behind using the
> > handle ?
> 
> I was just trying to save space.  ActivePython does the same thing as
> far as I remember.

Space?... the download is 3.9 Megs ;-)
 
> BTW, I haven't heard from CNRI in two weeks, but the last thing I
> heard from them was that their lawyers had talked to Stallman's lawyer
> and that they were optimistic about a successful resolution.

Great ! This would be really good news indeed :-)

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From just at letterror.com  Tue Oct 10 17:47:00 2000
From: just at letterror.com (Just van Rossum)
Date: Tue, 10 Oct 2000 16:47:00 +0100
Subject: [Python-Dev] Re: [Stackless] Stackless Python 1.2 + Continuations 0.9
In-Reply-To: <39E2F080.86ED1DA3@appliedbiometrics.com>
Message-ID: <l03102806b608e84fd7de@[193.78.237.153]>

In response to the new release of Stackless Python (see
http://www.stackless.com/), here's a new stackless binary for MacPython
1.5.2:

  http://starship.python.net/~just/MacStacklessPython.sit.hqx

(The archive contains a replacement for the PythonCore shared library)

Just





From guido at python.org  Tue Oct 10 17:50:07 2000
From: guido at python.org (Guido van Rossum)
Date: Tue, 10 Oct 2000 10:50:07 -0500
Subject: [Python-Dev] LICENSE file in Python 2.0c1
In-Reply-To: Your message of "Tue, 10 Oct 2000 16:03:14 +0200."
             <39E321A2.2BD99E35@lemburg.com> 
References: <39E31261.166F1601@lemburg.com> <200010101436.JAA13237@cj20424-a.reston1.va.home.com>  
            <39E321A2.2BD99E35@lemburg.com> 
Message-ID: <200010101550.KAA18130@cj20424-a.reston1.va.home.com>

> > > Such a note is nice and short, but not legally binding and
> > > confusing since it is not clear whether the "handle" for the
> > > document will always return the same license text or if it
> > > will return a license text at all.
> > 
> > Why do you say it's not legally binding?  The CNRI license explicitly
> > allows you to use this exact text instead of including the whole CNRI
> > license.
> 
> Sure, but not including the verbatim text will produce an
> unpleasent feeling of not being sure about the completeness
> of the license text.
> 
> <nitpicker-suite>
> 
> In a law suit the above construct would
> certainly not hold, since URLs only describe the location of
> information and don't hold any information about the validity
> or origin of it. The situation would be a little better if CNRI
> had provided a PGP signature or fingerprint of the license,
> since this is (in some countries) a legally accepted way of
> determining those two criteria.
> 
> Just a side note: the URL given for the license results in a 
> redirect to a different URL -
> http://www.handle.net/python_licenses/python1.6_9-5-00.html
> (note the date !): this doesn't really give the impression of
> persistent unchangeable information.
> 
> </nitpicker-suite>

Funny...  I agree that's not very confidence-inspiring.  CNRI always
advertises handles as better than URLs for long-term persistent
documents, but it's clear that they didn't think of this!  Or maybe
(warning: fake conspiracy theory ahead :-) they intend to change the
license terms after the fact...

> Not that there's much to fear about... but why add any extra areas
> of uncertainty ?

Agreed.  I'll add the full text back in.

> > I was just trying to save space.  ActivePython does the same thing as
> > far as I remember.
> 
> Space?... the download is 3.9 Megs ;-)

I meant less text for the reader to wade through.  But you've
convinced me already.

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



From bjorn at roguewave.com  Tue Oct 10 20:35:15 2000
From: bjorn at roguewave.com (Bjorn Pettersen)
Date: Tue, 10 Oct 2000 12:35:15 -0600
Subject: [Python-Dev] Re: Python 2.0 release candidate 1
References: <200010100652.XAA74600@python.beopen.com>
Message-ID: <39E36163.33291FAB@roguewave.com>

Are there any instructions on how to build this for Win64/itanium
anywhere?

-- bjorn

Jeremy Hylton wrote:
> 
> Python 2.0c1 is released.  The BeOpen PythonLabs and our cast of
> SourceForge volunteers have fixed many bugs since the beta releases
> last month.  Please pick up the new release at
> 
>     http://www.pythonlabs.com/products/python2.0/
> 
> There's a tarball, a Windows installer, RedHat RPMs, online
> documentation, and a long list of fixed bugs.
> 
> The final release of Python 2.0 will be next week.  We would
> appreciate feedback on the release candidate in order to fix any
> remaining bugs before the final release.  Confirmation of build and
> test success on less common platforms is also helpful.n
> 
> All major reported bugs have been fixed in the release candidate.  We
> do not plan to make any changes between now and the final release,
> except to fix bugs reported in the next week.  We encourage potential
> users of Python 2.0 to try the release candidate with their programs
> and report any remaining bugs.
> 
> To report a new bug, use the SourceForge bug tracker
> http://sourceforge.net/bugs/?func=addbug&group_id=5470
> 
> Python 2.0 has many new features, including the following:
> 
>   - Augmented assignment, e.g. x += 1
>   - List comprehensions, e.g. [x**2 for x in range(10)]
>   - Extended import statement, e.g. import Module as Name
>   - Extended print statement, e.g. print >> file, "Hello"
>   - Collection of cyclical garbage
> 
> For a fuller discussion of the changes in Python 2.0, please see the
> article "What's New in Python 2.0" by Andrew Kuchling and Moshe Zadke:
> http://starship.python.net/crew/amk/python/writing/new-python/
> 
> -- Jeremy Hylton <http://www.python.org/~jeremy/>
> 
> --
> http://www.python.org/mailman/listinfo/python-list



From trentm at ActiveState.com  Tue Oct 10 21:51:55 2000
From: trentm at ActiveState.com (Trent Mick)
Date: Tue, 10 Oct 2000 12:51:55 -0700
Subject: Building for Win64 (was: Re: [Python-Dev] Re: Python 2.0 release candidate 1)
In-Reply-To: <39E36163.33291FAB@roguewave.com>; from bjorn@roguewave.com on Tue, Oct 10, 2000 at 12:35:15PM -0600
References: <200010100652.XAA74600@python.beopen.com> <39E36163.33291FAB@roguewave.com>
Message-ID: <20001010125155.B3221@ActiveState.com>

On Tue, Oct 10, 2000 at 12:35:15PM -0600, Bjorn Pettersen wrote:
> Are there any instructions on how to build this for Win64/itanium
> anywhere?
> 

Um... not really.  I did/am doing the Win64 port but I have not really given
the information required to build it, which, I agree, kind of sucks. I have
not done so because:

  - the Python build system on Windows uses DevStudio project files
  - AFAIK there is no DevStudio yet for Win64 (if there were, building Python
    would be trivial, just setup a new configuration in DevStudio)
  - I am currently using a cross-compiler for Win64 provided by Intel (as
    part of a contract that ActiveState has to port Python to Win64 and other
    OSes for the IA-64 platform). I don't know if there is a publicly
    available compiler for Win64 (I haven't looked).
  - My method for building for Win64 involves:
    (1) exporting Win32 build makefile from the Python *.dsp files from
        within DevStudio.
    (2) running a hack script of my own to convert those to makefile to ones
        that will build for Win64 (these makefiles are extremely specific to
        my system, i.e. it is a hack)
    (3) run those makefiles

I *could* checkin this hack script of mine and provide some documentation in
Python's standard readme, if the other python-dev'ers would be ammenable to
this. [Note: my files would be isolated to one directory, say PCbuild/win64.]
As I said, I have not done this because I expected to just wait until
DevStudio for Win64 came on the scene and then the build system for it would
fit in smoothly to the current .dsp's.

I would rather not become a separate provider of the Win64 build scripts
because I don't want to support them outside of Python's mechanisms (i.e.
through SourceForge).  In other words, I'll check them into the Python core
if others think that that is okay, otherwise  I am afraid the answer is
"please wait until DevStudio for Win64 comes along".

Trent

-- 
Trent Mick
TrentM at ActiveState.com



From bjorn at roguewave.com  Tue Oct 10 22:24:00 2000
From: bjorn at roguewave.com (Bjorn Pettersen)
Date: Tue, 10 Oct 2000 14:24:00 -0600
Subject: Building for Win64 (was: Re: [Python-Dev] Re: Python 2.0 release 
 candidate 1)
References: <200010100652.XAA74600@python.beopen.com> <39E36163.33291FAB@roguewave.com> <20001010125155.B3221@ActiveState.com>
Message-ID: <39E37AE0.C7380FFD@roguewave.com>

To answer some of your questions:

- there is no win64 devstudio (and I haven't found a way of getting the
current devstudio to use the new compiler)
- Intel does have a native compiler for win64 (don't use it, see below).
- If you look in ia64xdevsdk\bin\win64 there is a cl.exe which is the
Microsoft compiler. It works MUCH better. It's also binary compatible
with the Intel ecl compiler, and they didn't have any problems with us
switching.

My main interest is in having a python version that runs on the itanium
box with socket support (they included socket support in sdk2 didn't
they?) I.e. no need to provide a build mechanism for my needs if you can
refer me to an executable ;-)

-- bjorn

Trent Mick wrote:
> 
> On Tue, Oct 10, 2000 at 12:35:15PM -0600, Bjorn Pettersen wrote:
> > Are there any instructions on how to build this for Win64/itanium
> > anywhere?
> >
> 
> Um... not really.  I did/am doing the Win64 port but I have not really given
> the information required to build it, which, I agree, kind of sucks. I have
> not done so because:
> 
>   - the Python build system on Windows uses DevStudio project files
>   - AFAIK there is no DevStudio yet for Win64 (if there were, building Python
>     would be trivial, just setup a new configuration in DevStudio)
>   - I am currently using a cross-compiler for Win64 provided by Intel (as
>     part of a contract that ActiveState has to port Python to Win64 and other
>     OSes for the IA-64 platform). I don't know if there is a publicly
>     available compiler for Win64 (I haven't looked).
>   - My method for building for Win64 involves:
>     (1) exporting Win32 build makefile from the Python *.dsp files from
>         within DevStudio.
>     (2) running a hack script of my own to convert those to makefile to ones
>         that will build for Win64 (these makefiles are extremely specific to
>         my system, i.e. it is a hack)
>     (3) run those makefiles
> 
> I *could* checkin this hack script of mine and provide some documentation in
> Python's standard readme, if the other python-dev'ers would be ammenable to
> this. [Note: my files would be isolated to one directory, say PCbuild/win64.]
> As I said, I have not done this because I expected to just wait until
> DevStudio for Win64 came on the scene and then the build system for it would
> fit in smoothly to the current .dsp's.
> 
> I would rather not become a separate provider of the Win64 build scripts
> because I don't want to support them outside of Python's mechanisms (i.e.
> through SourceForge).  In other words, I'll check them into the Python core
> if others think that that is okay, otherwise  I am afraid the answer is
> "please wait until DevStudio for Win64 comes along".
> 
> Trent
> 
> --
> Trent Mick
> TrentM at ActiveState.com



From trentm at ActiveState.com  Tue Oct 10 22:20:42 2000
From: trentm at ActiveState.com (Trent Mick)
Date: Tue, 10 Oct 2000 13:20:42 -0700
Subject: [Python-Dev] Monterey (64-bit AIX) screws up the poll() implementation, I think
Message-ID: <20001010132042.B22561@ActiveState.com>

test_poll.py currently fails on Monterey (64-bit AIX) because of a difference
in the system poll() function as compared to Linux.

On Linux (and as required by the Signle Unix Specification:
http://www.opengroup.org/onlinepubs/007908799/xsh/poll.html) if you "poll()"
a bogus file descriptor you get a POLLNVAL return value in the 'revents'
field of the structure sent to poll(). This is tested like so in
test_poll.py:

    # returns NVAL for invalid file descriptor
    FD = 42
    try:
        os.close(FD)
    except OSError:
        pass
    p = select.poll()
    p.register(FD)
    r = p.poll()
    assert r[0] == (FD, select.POLLNVAL)

Monterey decided to return -1 instead. [Aside: However, 'revents's type is
"short" so the Python interface to poll() (using PyInt_FromLong) actually
interprets that as -32768 instead.]

Questions:
1. Can anybody offer an opinion if this is Python's or Monterey's problem?

2. Can anybody tell me where I can browse the POSIX spec to see if this
   breaks POSIX compliance as well?

3. Could someone (Vladimir?) run this test program on a normal AIX box and
   tell me what the output is (does the return value == POLLNVAL?)?

----------------------------------------------------------------------
#include <stdio.h>
#include <poll.h>

#define NFDS 1

int main(void)
{
    struct pollfd ufds[NFDS];
    int pollResult;

    printf("hello\n");

    /* poll for any event on a bogus file descriptor */
    ufds[0].fd = 42;
    ufds[0].events = POLLIN | POLLPRI | POLLOUT;
    pollResult = poll(ufds, NFDS, -1);

    if (pollResult != 1) {
        printf("*** poll result was %d, I expected 1.\n", pollResult);
    }

    printf("ufds[0].revents = %hd\n", ufds[0].revents);
    printf("POLLNVAL = %ld\n", POLLNVAL);

    return 0;
}
----------------------------------------------------------------------


Thanks,
Trent

-- 
Trent Mick
TrentM at ActiveState.com



From trentm at ActiveState.com  Tue Oct 10 22:30:03 2000
From: trentm at ActiveState.com (Trent Mick)
Date: Tue, 10 Oct 2000 13:30:03 -0700
Subject: Building for Win64 (was: Re: [Python-Dev] Re: Python 2.0 release candidate 1)
In-Reply-To: <39E37AE0.C7380FFD@roguewave.com>; from bjorn@roguewave.com on Tue, Oct 10, 2000 at 02:24:00PM -0600
References: <200010100652.XAA74600@python.beopen.com> <39E36163.33291FAB@roguewave.com> <20001010125155.B3221@ActiveState.com> <39E37AE0.C7380FFD@roguewave.com>
Message-ID: <20001010133003.C22561@ActiveState.com>

On Tue, Oct 10, 2000 at 02:24:00PM -0600, Bjorn Pettersen wrote:
> - If you look in ia64xdevsdk\bin\win64 there is a cl.exe which is the
> Microsoft compiler. It works MUCH better. It's also binary compatible
> with the Intel ecl compiler, and they didn't have any problems with us
> switching.

Yes, I knew that that was there. I remember either some earlier problem with
it or some recommnedation to use the ecl.exe one. Anyway, ecl has worked for
me well enough, I just haven't tried the one in Win64/.

 
> My main interest is in having a python version that runs on the itanium
> box with socket support (they included socket support in sdk2 didn't
> they?) I.e. no need to provide a build mechanism for my needs if you can
> refer me to an executable ;-)

Well, Python's test_socket runs on my Win64 box so yes, socket support is
there. As far as referring you to an exe, I would rather not go down that
distribution road in preference to checking in my build scripts.

Trent


-- 
Trent Mick
TrentM at ActiveState.com



From mal at lemburg.com  Tue Oct 10 22:37:30 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Tue, 10 Oct 2000 22:37:30 +0200
Subject: [Python-Dev] -Wall output for the Python 2.0c1
Message-ID: <39E37E0A.90176759@lemburg.com>

FYI, Here's what gcc -Wall gives on Linux:

ceval.c: In function `eval_code2':
ceval.c:345: warning: `v' might be used uninitialized in this function
ceval.c:346: warning: `w' might be used uninitialized in this function
ceval.c:347: warning: `u' might be used uninitialized in this function
ceval.c:348: warning: `t' might be used uninitialized in this function
errors.c: In function `PyErr_Format':
errors.c:409: warning: value computed is not used
errors.c:415: warning: value computed is not used

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From mal at lemburg.com  Tue Oct 10 22:45:00 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Tue, 10 Oct 2000 22:45:00 +0200
Subject: [Python-Dev] What will happen to cycle GC in the 2.0 final ?
Message-ID: <39E37FCC.9925555A@lemburg.com>

It was mentioned early in the beta phase that cycle GC would be
enabled only during the beta cycle and disabled in the final.

Is this still true ?

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From tim_one at email.msn.com  Tue Oct 10 22:47:06 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Tue, 10 Oct 2000 16:47:06 -0400
Subject: [Python-Dev] Monterey (64-bit AIX) screws up the poll() implementation, I think
In-Reply-To: <20001010132042.B22561@ActiveState.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCAEKLHKAA.tim_one@email.msn.com>

[Trent Mick]
> test_poll.py currently fails on Monterey (64-bit AIX) because of
> a difference in the system poll() function as compared to Linux.
>
> On Linux (and as required by the Signle Unix Specification:
> http://www.opengroup.org/onlinepubs/007908799/xsh/poll.html) if
> you "poll()" a bogus file descriptor you get a POLLNVAL return value in
> the 'revents' field of the structure sent to poll().
> ...
> Monterey decided to return -1 instead. [Aside: However, 'revents's type is
> "short" so the Python interface to poll() (using PyInt_FromLong) actually
> interprets that as -32768 instead.]
>
> Questions:
> 1. Can anybody offer an opinion if this is Python's or Monterey's
>    problem?

Both.  "Another day, another incompatible flavor of Unix(tm)."  In the early
days, Guido actually hoped he could get away without a massive hack like
autoconf <wink>.

> 2. Can anybody tell me where I can browse the POSIX spec to see if this
>    breaks POSIX compliance as well?

Nowhere:  ISO/ANSI stds are generally never available online.  They get the
bulk of their money from selling standards.

    http://webstore.ansi.org/

is a good place to buy.  There are about 20 POSIX-related stds documents;
the C API spec is US$245.00.  You may get a cheaper answer on comp.unix.aix,
of course.

may-be-worth-more-than-$245-to-weed-out-the-wrong-answers-though-ly y'rs
    - tim





From tim_one at email.msn.com  Tue Oct 10 22:58:54 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Tue, 10 Oct 2000 16:58:54 -0400
Subject: [Python-Dev] What will happen to cycle GC in the 2.0 final ?
In-Reply-To: <39E37FCC.9925555A@lemburg.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCAEKNHKAA.tim_one@email.msn.com>

[M.-A. Lemburg]
> It was mentioned early in the beta phase that cycle GC would be
> enabled only during the beta cycle and disabled in the final.
>
> Is this still true ?

No, and it probably never was <wink>:  the intent of enabling gc during the
betas was to determine *whether* to enable it for the final release.  The
beta experience with gc was very good:  a few subtle problems were
uncovered, and Neil fixed them quickly.  It should probably get a ton of
performance testing that never happened, but then so should have all of
2.0 -- no particular reason to pick on gc alone for that.

full-cycle-ahead-ly y'rs  - tim





From fdrake at beopen.com  Tue Oct 10 23:13:47 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Tue, 10 Oct 2000 17:13:47 -0400 (EDT)
Subject: [Python-Dev] -Wall output for the Python 2.0c1
In-Reply-To: <39E37E0A.90176759@lemburg.com>
References: <39E37E0A.90176759@lemburg.com>
Message-ID: <14819.34443.951260.635718@cj42289-a.reston1.va.home.com>

M.-A. Lemburg writes:
 > ceval.c: In function `eval_code2':
 > ceval.c:345: warning: `v' might be used uninitialized in this function
 > ceval.c:346: warning: `w' might be used uninitialized in this function
 > ceval.c:347: warning: `u' might be used uninitialized in this function
 > ceval.c:348: warning: `t' might be used uninitialized in this function

  These would be a real tedium to fix, and I'm not convinced the loss
of clarity is worth it.  From looking at the code in the DUP_TOPX
code, I'm led to think that the compiler just isn't smart enough (it
should figure out that oparg won't change before the second case
statement, and figure it out more carefully.  I'll bet *that* would
remove these warnings and still right in all cases.

 > errors.c: In function `PyErr_Format':
 > errors.c:409: warning: value computed is not used
 > errors.c:415: warning: value computed is not used

  Fixed.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From guido at python.org  Wed Oct 11 01:16:42 2000
From: guido at python.org (Guido van Rossum)
Date: Tue, 10 Oct 2000 18:16:42 -0500
Subject: [Python-Dev] pythonlabs.com website down -- 2.0c1 still available!
Message-ID: <200010102316.SAA20071@cj20424-a.reston1.va.home.com>

We're experiencing a serious problem with the pythonlabs.com website.
Unfortunately the site is down with no estimated time for when it will
be back up.  Our bestest brains are working on the problem!

In the mean time, the Python 2.0c1 source tree can be downloaded from
this address:

    http://www.beopen.com/products/python2.0/BeOpen-Python-2.0c1.tar.gz

The Windows installer is here:

    http://www.beopen.com/products/python2.0/BeOpen-Python-2.0c1.exe

And the 2.0c1 documentation is still here (on-line browseable and
downloadable):

    http://www.python.org/doc/2.0c1/

If the outage lasts for more than a day, we'll find another place to
hold the full distribution.

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



From tim_one at email.msn.com  Wed Oct 11 00:47:19 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Tue, 10 Oct 2000 18:47:19 -0400
Subject: [Python-Dev] -Wall output for the Python 2.0c1
In-Reply-To: <14819.34443.951260.635718@cj42289-a.reston1.va.home.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCMELAHKAA.tim_one@email.msn.com>

[MAL]
> ceval.c: In function `eval_code2':
> ceval.c:345: warning: `v' might be used uninitialized in this function
> ceval.c:346: warning: `w' might be used uninitialized in this function
> ceval.c:347: warning: `u' might be used uninitialized in this function
> ceval.c:348: warning: `t' might be used uninitialized in this function

[Fred]
>   These would be a real tedium to fix, and I'm not convinced the loss
> of clarity is worth it.

I'll take this one.  It looks easy to fix, and to my eye doing *everything*
needed for oparg == 5 in a single block (ditto for 4, 3, 2, 1 in their own
blocks) would be much clearer than the current distributed trickiness
(faster, too -- the code now is branching more than computing).

> From looking at the code in the DUP_TOPX code, I'm led to think that
> the compiler just isn't smart enough (it should figure out that oparg
> won't change before the second case statement, and figure it out more
> carefully.  I'll bet *that* would remove these warnings and still right
> in all cases.

I agree, except that it wasn't trivial for *me* to decide the compiler was
being stupid.  Code that's obviously correct is better than code that's not
obviously wrong.

>> errors.c: In function `PyErr_Format':
>> errors.c:409: warning: value computed is not used
>> errors.c:415: warning: value computed is not used

Thanks!

>   Fixed.

Thanks!





From thomas at xs4all.net  Wed Oct 11 00:49:37 2000
From: thomas at xs4all.net (Thomas Wouters)
Date: Wed, 11 Oct 2000 00:49:37 +0200
Subject: [Python-Dev] -Wall output for the Python 2.0c1
In-Reply-To: <14819.34443.951260.635718@cj42289-a.reston1.va.home.com>; from fdrake@beopen.com on Tue, Oct 10, 2000 at 05:13:47PM -0400
References: <39E37E0A.90176759@lemburg.com> <14819.34443.951260.635718@cj42289-a.reston1.va.home.com>
Message-ID: <20001011004937.Q12812@xs4all.nl>

On Tue, Oct 10, 2000 at 05:13:47PM -0400, Fred L. Drake, Jr. wrote:

> M.-A. Lemburg writes:
>  > ceval.c: In function `eval_code2':
>  > ceval.c:345: warning: `v' might be used uninitialized in this function
>  > ceval.c:346: warning: `w' might be used uninitialized in this function
>  > ceval.c:347: warning: `u' might be used uninitialized in this function
>  > ceval.c:348: warning: `t' might be used uninitialized in this function

>   These would be a real tedium to fix, and I'm not convinced the loss
> of clarity is worth it.  From looking at the code in the DUP_TOPX
> code, I'm led to think that the compiler just isn't smart enough (it
> should figure out that oparg won't change before the second case
> statement, and figure it out more carefully.  I'll bet *that* would
> remove these warnings and still right in all cases.

Well, I'm certain I compiled my code (which included DUP_TOPX) with -Wall
sometime before, and I didn't get those warnings then. Probably depends on
the version of gcc. As a colleague of mine would say, "insert clue" (into
gcc, that is ;)

-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!



From guido at python.org  Wed Oct 11 01:57:38 2000
From: guido at python.org (Guido van Rossum)
Date: Tue, 10 Oct 2000 18:57:38 -0500
Subject: [Python-Dev] Re: pythonlabs.com website down -- 2.0c1 still available!
In-Reply-To: Your message of "Tue, 10 Oct 2000 18:16:42 EST."
             <200010102316.SAA20071@cj20424-a.reston1.va.home.com> 
References: <200010102316.SAA20071@cj20424-a.reston1.va.home.com> 
Message-ID: <200010102357.SAA20163@cj20424-a.reston1.va.home.com>

I wrote:
> We're experiencing a serious problem with the pythonlabs.com website.
> Unfortunately the site is down with no estimated time for when it will
> be back up.  Our bestest brains are working on the problem!

With the help of Digital Creations' bestest brain, Jim Fulton, the
site is back up in record time.  We'll try not to break it again, Jim!
And thanks to Digital Creations for helping us out on such a short
notice.

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



From fdrake at beopen.com  Wed Oct 11 02:57:11 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Tue, 10 Oct 2000 20:57:11 -0400 (EDT)
Subject: [Python-Dev] -Wall output for the Python 2.0c1
In-Reply-To: <20001011004937.Q12812@xs4all.nl>
References: <39E37E0A.90176759@lemburg.com>
	<14819.34443.951260.635718@cj42289-a.reston1.va.home.com>
	<20001011004937.Q12812@xs4all.nl>
Message-ID: <14819.47847.268859.42306@cj42289-a.reston1.va.home.com>

Thomas Wouters writes:
 > Well, I'm certain I compiled my code (which included DUP_TOPX) with -Wall
 > sometime before, and I didn't get those warnings then. Probably depends on
 > the version of gcc. As a colleague of mine would say, "insert clue" (into
 > gcc, that is ;)

  This is very reasonable.  I don't think we'll give you too many
demerits for this.  ;)


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From tim_one at email.msn.com  Wed Oct 11 06:40:41 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Wed, 11 Oct 2000 00:40:41 -0400
Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison)
In-Reply-To: <slrn8u73ug.8jj.hzhu@rock.localdomain>
Message-ID: <LNBBLJKPBEHFEDALKOLCKELGHKAA.tim_one@email.msn.com>

We need a glibc expert!  Anyone qualify?

[Huaiyu Zhu]
> ...
> This is very likely to be a 2.0 bug.

Or a 1.5.2 bug.  I have to keep saying this stuff is a platform-dependent
crap shoot, because it is (I too prefer that Python underflow silently by
default, though).

> Just to make sure, I have used freshly downloaded source code of
> both 1.5.2 and 2.0b2, then

> ./configure
> make
> ./python
>
> from math import *
> exp(-746)
>
> I got 0.0 from 1.5.2 but OverflowError: math range error from 2.0b2.
>
> The file mathmodule.c has quite some differences between the two versions,
> mostly related to the ANSIfication.  I'm not sure where the problem is.

It's not in mathmodule.c.

> I haven't tried the 2.0c1 yet, as the site is not available.  Can
> other Unix users confirm this behavior?

I went over to Guido's and forced him to try it.  He sees the same behavior:
after building 1.5.2 and some flavor of 2.0 w/ the same gcc and libraries,
1.5.2 Python silently returns 0 and (some flavor of) 2.0 raises
OverflowError.

But there is no code in Python that accounts for the difference.  Running it
under the debugger, the platform exp leaves errno at 0 under 1.5.2 but sets
errno to ERANGE (34) under 2.0.  Since the platform exp was the only
conceivable cause for this difference, it's not surprising that the debugger
confirmed that the platform exp is in fact the cause.

So the remaining question is why the same exp from the same library has
different errno behavior depending on which version of Python it's called
from.  *That* one we couldn't answer, after a fruitless time digging thru
the Byzantine glibc source code trying to reverse engineer it.  Their exp
*can* display different error behavior at runtime depending on several
obscure things, but they're too obscure to relate back clearly to anything
Python is doing.

The 2.0 behavior (set errno to ERANGE on exp underflow) appears to be what
the glibc exp author believes POSIX mandates, and is one of their exp's
possible runtime behaviors, and your own little C program (which you posted
earlier) suggests that's the default behavior under gcc + glibc.  So
presumably 1.5.2 config was such as to inhibit the default behavior.
However, nobody changed this on purpose, so it smells like an unintended
side effect of some other (currently unknown) config change.

I don't know what to do next.  I can't pursue it myself, and you've seen
from the lack of replies to your posts that I'm the only who'll even listen
to you <wink>.  Guido suggests that one big change in 2.0 is that we're
including a lot more std headers than we used to.  It could well be that one
of those #defines some God-forsaken preprocessor symbol one of whose five
meanings (documented or not) is "use POSIX-conformant libm error reporting",
but which someone #include'd in 2.0 to make (who knows?) sockets work right
on some other flavor of Unix.  Don't know.  Unix config is a mess, and so is
glibc.  Best hope now is for someone intimately familiar with glibc
internals to jump in and own this.

staring-at-the-python-source-remains-pointless-for-this-one-ly y'rs  - tim





From huaiyu_zhu at yahoo.com  Wed Oct 11 10:12:37 2000
From: huaiyu_zhu at yahoo.com (Huaiyu Zhu)
Date: Wed, 11 Oct 2000 01:12:37 -0700 (PDT)
Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich
 comparison)
In-Reply-To: <LNBBLJKPBEHFEDALKOLCKELGHKAA.tim_one@email.msn.com>
Message-ID: <Pine.LNX.4.10.10010110044370.25593-100000@rock.localdomain>

[Tim Peters]

> We need a glibc expert!  Anyone qualify?

If there is none here, maybe someone cares to ask in some gcc or gnu news
groups?

> The 2.0 behavior (set errno to ERANGE on exp underflow) appears to be what
> the glibc exp author believes POSIX mandates, and is one of their exp's
> possible runtime behaviors, and your own little C program (which you posted
> earlier) suggests that's the default behavior under gcc + glibc.  So
> presumably 1.5.2 config was such as to inhibit the default behavior.
> However, nobody changed this on purpose, so it smells like an unintended
> side effect of some other (currently unknown) config change.

So can we set a flag to explicitly discount ERANGE?  There are only 19 lines
in the source code that contain ERANGE, and 8 lines containing math_error.
All the latter are in Modules/{c,}mathmodule.c.  Could we just add an ifdef
IEEE754 on these 8 lines?  This would go a long way to aleviate this problem
before we find a perfect solution, if there is one.

> I don't know what to do next.  I can't pursue it myself, and you've seen
> from the lack of replies to your posts that I'm the only who'll even listen
> to you <wink>.  Guido suggests that one big change in 2.0 is that we're
> including a lot more std headers than we used to.  It could well be that one
> of those #defines some God-forsaken preprocessor symbol one of whose five
> meanings (documented or not) is "use POSIX-conformant libm error reporting",
> but which someone #include'd in 2.0 to make (who knows?) sockets work right
> on some other flavor of Unix.  Don't know.  Unix config is a mess, and so is
> glibc.  Best hope now is for someone intimately familiar with glibc
> internals to jump in and own this.

I'm not interested in where this comes from - the only thing that matters is
that it worked in 1.5.2 and breaks in 2.0.  Whether the 1.5.2 behavior was
intended or not, it's not a bug.  The 2.0 behavior is a bug.  If Posix
conflicts with IEEE floating point arithmetic, then confirming to Posix in
this regard is a bug.

I would suggest the next thing to do is to introduce an IEEE754 flag and let
those who do not like it to voice their opinions.  Since this is the same
behavior as 1.5.2 I doubt any running code would be broken by this.

Huaiyu




From thomas at xs4all.net  Wed Oct 11 10:26:14 2000
From: thomas at xs4all.net (Thomas Wouters)
Date: Wed, 11 Oct 2000 10:26:14 +0200
Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison)
In-Reply-To: <LNBBLJKPBEHFEDALKOLCKELGHKAA.tim_one@email.msn.com>; from tim_one@email.msn.com on Wed, Oct 11, 2000 at 12:40:41AM -0400
References: <slrn8u73ug.8jj.hzhu@rock.localdomain> <LNBBLJKPBEHFEDALKOLCKELGHKAA.tim_one@email.msn.com>
Message-ID: <20001011102614.R12812@xs4all.nl>

On Wed, Oct 11, 2000 at 12:40:41AM -0400, Tim Peters wrote:
> We need a glibc expert!  Anyone qualify?

No, at least not me ;)

> So the remaining question is why the same exp from the same library has
> different errno behavior depending on which version of Python it's called
> from.  *That* one we couldn't answer, after a fruitless time digging thru
> the Byzantine glibc source code trying to reverse engineer it.  Their exp
> *can* display different error behavior at runtime depending on several
> obscure things, but they're too obscure to relate back clearly to anything
> Python is doing.

Well, I've seen & heard about compilers doing slightly different things
depending on ANSI or K&R style C, so perhaps the presence of ANSI C
definitions triggered this. I sincerely doubt it, though, but you never
know, and it's fairly easy to test.

> I don't know what to do next.  I can't pursue it myself, and you've seen
> from the lack of replies to your posts that I'm the only who'll even listen
> to you <wink>.  Guido suggests that one big change in 2.0 is that we're
> including a lot more std headers than we used to.  It could well be that one
> of those #defines some God-forsaken preprocessor symbol one of whose five
> meanings (documented or not) is "use POSIX-conformant libm error reporting",
> but which someone #include'd in 2.0 to make (who knows?) sockets work right
> on some other flavor of Unix.  Don't know.  Unix config is a mess, and so is
> glibc.  Best hope now is for someone intimately familiar with glibc
> internals to jump in and own this.

Actually, there was some activity to define the right combination of
_GNU_SOURCE, _POSIX_SOURCE, _XOPEN_SOURCE, _BSD_SOURCE, et al, but I'm not
sure what the end result was. If any #define changes the behaviour of glibc,
these would definately be it ! A simple test might be to compile 1.5.2 with
the config.h from 2.0, and manually add whatever _*_SOURCE defines aren't in
1.5.2. (They reside in Python.h and config.h, currently.) I'll see if I can
reproduce it on the glibc almost-2.2 (that is, glibc-2.1.94) systems here,
and do some of the above tests.

Computers-suck-ly y'rs,
-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!



From thomas at xs4all.net  Wed Oct 11 10:31:49 2000
From: thomas at xs4all.net (Thomas Wouters)
Date: Wed, 11 Oct 2000 10:31:49 +0200
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Python ceval.c,2.207,2.208
In-Reply-To: <200010110704.AAA12861@slayer.i.sourceforge.net>; from tim_one@users.sourceforge.net on Wed, Oct 11, 2000 at 12:04:52AM -0700
References: <200010110704.AAA12861@slayer.i.sourceforge.net>
Message-ID: <20001011103148.S12812@xs4all.nl>

On Wed, Oct 11, 2000 at 12:04:52AM -0700, Tim Peters wrote:

>   			default:
>   				fprintf(stderr, "Invalid argument to DUP_TOPX: %d!\n", oparg);

Hm, this fprintf is stray debugging code, added because I wasn't sure that a
SystemError wouldn't crash the interpreter, given that the stack is utterly
fu*d up at this point and we don't know what the compiler thinks is the
stack size or block size here. (The snippet doesn't show it, but it also
raises a SystemError.) Is it okay if I remove/comment this fprintf() before
2.0 final ?

(At least it didn't say "awoogah, stray debugging code detected, this
machine will self-destruct in 10 seconds" :-)

Another-day-another-demerit<wink>-ly y'rs,
-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!



From tim_one at email.msn.com  Wed Oct 11 11:52:59 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Wed, 11 Oct 2000 05:52:59 -0400
Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison)
In-Reply-To: <Pine.LNX.4.10.10010110044370.25593-100000@rock.localdomain>
Message-ID: <LNBBLJKPBEHFEDALKOLCOELMHKAA.tim_one@email.msn.com>

[Huaiyu Zhu]
> ...
> So can we set a flag to explicitly discount ERANGE?  There are
> only 19 lines in the source code that contain ERANGE, and 8 lines
> containing math_error.
> All the latter are in Modules/{c,}mathmodule.c.  Could we just
> add an ifdef IEEE754 on these 8 lines?  This would go a long way to
> aleviate this problem before we find a perfect solution, if there
> is one.

That would stop the exception on exp() underflow, which is what you're
concerned about.  It would also stop exceptions on exp() overflow, and on
underflow and overflow for all other math functions too.  I doubt Guido will
ever let Python ignore overflow by default, #ifdef'ed or not.  A semantic
change that jarring certainly won't happen for 2.0 (which is just a week
away).

> ...
> I'm not interested in where this comes from - the only thing that
> matters is that it worked in 1.5.2 and breaks in 2.0.

The behavior of underflowing exp() is hardly the only thing that matters,
although it's becoming clear it may be the only thing you care about <0.9
wink>.  I would like to change that too for 2.0, but give a thought to the
other consequences.  If some change to the Python config screwed up
exp(-1000) for you, what else is going wrong?  You're not going to get an
answer to that until we know exactly "where this comes from".

> Whether the 1.5.2 behavior was> intended or not, it's not a bug.  The
> 2.0 behavior is a bug.  If Posix conflicts with IEEE floating point
> arithmetic, then confirming to Posix in this regard is a bug.

POSIX doesn't conflict w/ 754 here, as 754 is silent on the matter of errno,
as is POSIX on 754 issues.  It was Python's decision (not POSIX's) to raise
an exception when errno gets set.  Python wasn't designed to support 754,
and makes no claim to support any part of it, so conformance to 754 may be
presented as a feature request, but trying to beat Python over the head with
it won't work:  there's no bug here, in the strong sense that no documented
(or even intended!) behavior has changed.  What happened is that one
platform accident got changed to a different platform accident.  You
certainly get sympathy for that, but not enough to buy radical last-minute
changes.

> I would suggest the next thing to do is to introduce an IEEE754
> flag and let those who do not like it to voice their opinions.

Nothing like that will happen without a PEP first.  I would like to see
*serious* 754 support myself, but that depends too on many platform experts
contributing real work (if everyone ran WinTel, I could do it myself
<wink>).

> Since this is the same behavior as 1.5.2 I doubt any running code would be
> broken by this.

Ignoring ERANGE entirely is not at all the same behavior as 1.5.2, and
current code certainly relies on detecting overflows in math functions.  It
would also break code on platforms that were setting errno to ERANGE all
along on underflow (as POSIX appears to require, and ANSI C doesn't appear
to forbid; I don't know of such a platform for sure offhand, but to judge
from their manpages, HPUX looks like one).

In no case can you expect to see overflow ignored in 2.0.

I want to know where this comes from, so we have *some* handle on what other
surprises may be lurking.

If no progress is made on determining the true cause over the next few days,
I'll hack mathmodule.c to ignore ERANGE in the specific case the result
returned is a zero (which would "fix" your exp underflow problem without
stopping overflow detection).  Since this will break code on any platform
where errno was set to ERANGE on underflow in 1.5.2, I'll need to have a
long discussion w/ Guido first.  I *believe* that much is actually sellable
for 2.0, because it moves Python in a direction I know he likes regardless
of whether he ever becomes a 754 True Believer.

like-herding-cats-indeed-ly y'rs  - tim





From tim_one at email.msn.com  Wed Oct 11 12:02:05 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Wed, 11 Oct 2000 06:02:05 -0400
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Python ceval.c,2.207,2.208
In-Reply-To: <20001011103148.S12812@xs4all.nl>
Message-ID: <LNBBLJKPBEHFEDALKOLCMELNHKAA.tim_one@email.msn.com>

> >   			default:
> >   				fprintf(stderr, "Invalid argument
> to DUP_TOPX: %d!\n", oparg);

[Thomas Wouters]
> Hm, this fprintf is stray debugging code, added because I wasn't
> sure that a SystemError wouldn't crash the interpreter, given that the
> stack is utterly fu*d up at this point and we don't know what the
> compiler thinks is the stack size or block size here. (The snippet
> doesn't show it, but it also raises a SystemError.) Is it okay if I
> remove/comment this fprintf() before 2.0 final ?

Suggest replacing it with:

    assert(!"Invalid argument to DUP_TOPX");

Then there's no cost in release mode, but we have a useful check in debug
mode.  ("assert(!string)" is a handy C debugging idiom more people should
know about!  It's semantically the same as assert(0) (i.e. will fail if ever
reached), but unlike using a comment, using a string gets a useful msg
displayed if it ever does fail).

> (At least it didn't say "awoogah, stray debugging code detected, this
> machine will self-destruct in 10 seconds" :-)

Beats "Unto the root this day a brother is born" <wink -- a famous "can't
happen" msg that, of course, got displayed, many years ago in a different
project -- except the original was in Latin!>.

> Another-day-another-demerit<wink>-ly y'rs,

That's a funny thing about working on Python:  collect 5 demerits and you
can exchange them for 1 brownie point!  If you're not leaving crap behind,
you're not eating enough Python code.

continuous-recoding-is-as-effective-as-it-is-rare-ly y'rs  - tim





From guido at python.org  Wed Oct 11 16:39:06 2000
From: guido at python.org (Guido van Rossum)
Date: Wed, 11 Oct 2000 09:39:06 -0500
Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison)
In-Reply-To: Your message of "Wed, 11 Oct 2000 05:52:59 -0400."
             <LNBBLJKPBEHFEDALKOLCOELMHKAA.tim_one@email.msn.com> 
References: <LNBBLJKPBEHFEDALKOLCOELMHKAA.tim_one@email.msn.com> 
Message-ID: <200010111439.JAA02783@cj20424-a.reston1.va.home.com>

Incidentally, math.exp(800) returns inf in 1.5, and raises
OverflowError in 2.0.  So at least it's consistent.

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



From moshez at math.huji.ac.il  Wed Oct 11 14:38:21 2000
From: moshez at math.huji.ac.il (Moshe Zadka)
Date: Wed, 11 Oct 2000 15:38:21 +0300 (IDT)
Subject: [Python-Dev] OS Dependant Bugs
Message-ID: <Pine.GSO.4.10.10010111534170.7162-100000@sundial>

Many of the sourceforge bugs are platform dependant. Unfortunately, it is
impossible, from the main bugs page, to see which are platform dependant,
and which platform the occur on.

I suggest that, until SF supports it properly, each bug report we enter
will have an optional [Platform] in front, if it seems to be platform
dependant. 

Any opinions? Anyone thinks submitting an SF request to add this field
is foolish?

--
Moshe Zadka <moshez at math.huji.ac.il>
There is no IGLU cabal.
http://advogato.org/person/moshez




From guido at python.org  Wed Oct 11 16:41:47 2000
From: guido at python.org (Guido van Rossum)
Date: Wed, 11 Oct 2000 09:41:47 -0500
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Python ceval.c,2.207,2.208
In-Reply-To: Your message of "Wed, 11 Oct 2000 06:02:05 -0400."
             <LNBBLJKPBEHFEDALKOLCMELNHKAA.tim_one@email.msn.com> 
References: <LNBBLJKPBEHFEDALKOLCMELNHKAA.tim_one@email.msn.com> 
Message-ID: <200010111441.JAA02813@cj20424-a.reston1.va.home.com>

> Suggest replacing it with:
> 
>     assert(!"Invalid argument to DUP_TOPX");

Actually, I would recommend

	Py_FatalError("Invalid argument to DUP_TOPX")

It's not quite the same since it also triggers in release mode.  If,
as Thomas says, this should never happen and can only be caused by
garbled bytecode, a fatal error is proper rather than a SystemError.

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



From moshez at math.huji.ac.il  Wed Oct 11 14:41:27 2000
From: moshez at math.huji.ac.il (Moshe Zadka)
Date: Wed, 11 Oct 2000 15:41:27 +0300 (IDT)
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Python
 ceval.c,2.207,2.208
In-Reply-To: <200010111441.JAA02813@cj20424-a.reston1.va.home.com>
Message-ID: <Pine.GSO.4.10.10010111539440.7162-100000@sundial>

On Wed, 11 Oct 2000, Guido van Rossum wrote:

> 	Py_FatalError("Invalid argument to DUP_TOPX")
> 
> It's not quite the same since it also triggers in release mode.  If,
> as Thomas says, this should never happen and can only be caused by
> garbled bytecode, a fatal error is proper rather than a SystemError.

Can't user Python code, fiddling around with bytecode, produce garbled
bytecode? In that case, it seems  even better to raise an exception.

Unless I misunderstand the discussion completely.

jumping-to-discussions-in-the-middle-ly y'rs, Z.

--
Moshe Zadka <moshez at math.huji.ac.il>
There is no IGLU cabal.
http://advogato.org/person/moshez




From fdrake at beopen.com  Wed Oct 11 15:42:57 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Wed, 11 Oct 2000 09:42:57 -0400 (EDT)
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Python ceval.c,2.207,2.208
In-Reply-To: <200010110704.AAA12861@slayer.i.sourceforge.net>
References: <200010110704.AAA12861@slayer.i.sourceforge.net>
Message-ID: <14820.28257.836222.958973@cj42289-a.reston1.va.home.com>

Tim Peters writes:
 > Update of /cvsroot/python/python/dist/src/Python
 > Attempt to fix bogus gcc -Wall warnings reported by Marc-Andre Lemburg,
 > by making the DUP_TOPX code utterly straightforward.  This also gets rid
 > of all normal-case internal DUP_TOPX if/branches, and allows replacing one
 > POP() with TOP() in each case, so is a good idea regardless.

Tim,
  There's still one left:

gcc -Wall -O2 -Wstrict-prototypes -I../../Python/../Include -I.. -DHAVE_CONFIG_H   -c -o ceval.o ../../Python/ceval.c
../../Python/ceval.c: In function `eval_code2':
../../Python/ceval.c:346: warning: `w' might be used uninitialized in
this function

  Cruising through this code, it looks like the problem might be in
the PRINT_NEWLINE case:

		case PRINT_NEWLINE:
			if (stream == NULL || stream == Py_None) {
				w = PySys_GetObject("stdout");
				if (w == NULL)
					PyErr_SetString(PyExc_RuntimeError,
							"lost sys.stdout");
			}
			if (w != NULL) {
	/* If PRINT_NEWLINE is the opcode, w might not be initialized
         * here (I think), since I don't see it initialize before the
         * switch.  Since we can't initialize it to NULL with the case
         * (doing so would break the PRINT_NEWLINE_TO case), it would
         * have to be initialized before the main loop is entered.
         */
				err = PyFile_WriteString("\n", w);
				if (err == 0)
					PyFile_SoftSpace(w, 0);
			}
			Py_XDECREF(stream);
			stream = NULL;
			break;

  Ok.... yep, initializing that seems to work.
  I'll check in the fix for this one after I've run the regression test.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From guido at python.org  Wed Oct 11 16:54:14 2000
From: guido at python.org (Guido van Rossum)
Date: Wed, 11 Oct 2000 09:54:14 -0500
Subject: [Python-Dev] OS Dependant Bugs
In-Reply-To: Your message of "Wed, 11 Oct 2000 15:38:21 +0300."
             <Pine.GSO.4.10.10010111534170.7162-100000@sundial> 
References: <Pine.GSO.4.10.10010111534170.7162-100000@sundial> 
Message-ID: <200010111454.JAA03006@cj20424-a.reston1.va.home.com>

> Many of the sourceforge bugs are platform dependant. Unfortunately, it is
> impossible, from the main bugs page, to see which are platform dependant,
> and which platform the occur on.
> 
> I suggest that, until SF supports it properly, each bug report we enter
> will have an optional [Platform] in front, if it seems to be platform
> dependant. 
> 
> Any opinions? Anyone thinks submitting an SF request to add this field
> is foolish?

I think it's sufficient (actually better) if the platform name is
mentioned in the summary.  Note that you can edit the summary of
existing bug reports.

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




From guido at python.org  Wed Oct 11 16:54:54 2000
From: guido at python.org (Guido van Rossum)
Date: Wed, 11 Oct 2000 09:54:54 -0500
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Python ceval.c,2.207,2.208
In-Reply-To: Your message of "Wed, 11 Oct 2000 15:41:27 +0300."
             <Pine.GSO.4.10.10010111539440.7162-100000@sundial> 
References: <Pine.GSO.4.10.10010111539440.7162-100000@sundial> 
Message-ID: <200010111454.JAA03020@cj20424-a.reston1.va.home.com>

> Can't user Python code, fiddling around with bytecode, produce garbled
> bytecode? In that case, it seems  even better to raise an exception.

Yes, they can produce garbled bytecode, and if that is detected, it's
not safe to proceed.  So a fatal error is the right thing.

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



From moshez at math.huji.ac.il  Wed Oct 11 14:56:17 2000
From: moshez at math.huji.ac.il (Moshe Zadka)
Date: Wed, 11 Oct 2000 15:56:17 +0300 (IDT)
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Python
 ceval.c,2.207,2.208
In-Reply-To: <200010111454.JAA03020@cj20424-a.reston1.va.home.com>
Message-ID: <Pine.GSO.4.10.10010111555020.7162-100000@sundial>

On Wed, 11 Oct 2000, Guido van Rossum wrote:

> > Can't user Python code, fiddling around with bytecode, produce garbled
> > bytecode? In that case, it seems  even better to raise an exception.
> 
> Yes, they can produce garbled bytecode, and if that is detected, it's
> not safe to proceed.  So a fatal error is the right thing.

The problem with letting Python code cause fatal errors is that it makes
restricted execution much more difficult. Well, something to think about
for 2.1...

--
Moshe Zadka <moshez at math.huji.ac.il>
There is no IGLU cabal.
http://advogato.org/person/moshez




From akuchlin at mems-exchange.org  Wed Oct 11 15:56:50 2000
From: akuchlin at mems-exchange.org (Andrew Kuchling)
Date: Wed, 11 Oct 2000 09:56:50 -0400
Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison)
In-Reply-To: <20001011102614.R12812@xs4all.nl>; from thomas@xs4all.net on Wed, Oct 11, 2000 at 10:26:14AM +0200
References: <slrn8u73ug.8jj.hzhu@rock.localdomain> <LNBBLJKPBEHFEDALKOLCKELGHKAA.tim_one@email.msn.com> <20001011102614.R12812@xs4all.nl>
Message-ID: <20001011095650.A17931@kronos.cnri.reston.va.us>

On Wed, Oct 11, 2000 at 10:26:14AM +0200, Thomas Wouters wrote:
>Actually, there was some activity to define the right combination of
>_GNU_SOURCE, _POSIX_SOURCE, _XOPEN_SOURCE, _BSD_SOURCE, et al, but I'm not
>sure what the end result was. If any #define changes the behaviour of glibc,
>these would definately be it ! A simple test might be to compile 1.5.2 with

That seems the likely cause.  Another faint possibility might be
threading, since 2.0 automatically uses threads but 1.5.2 needs to
have them enabled. (Perhaps Tim remembered this and supplied
--with-thread to the 1.5.2 configure script.)

--amk




From guido at python.org  Wed Oct 11 17:03:00 2000
From: guido at python.org (Guido van Rossum)
Date: Wed, 11 Oct 2000 10:03:00 -0500
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Python ceval.c,2.207,2.208
In-Reply-To: Your message of "Wed, 11 Oct 2000 15:56:17 +0300."
             <Pine.GSO.4.10.10010111555020.7162-100000@sundial> 
References: <Pine.GSO.4.10.10010111555020.7162-100000@sundial> 
Message-ID: <200010111503.KAA03123@cj20424-a.reston1.va.home.com>

> > > Can't user Python code, fiddling around with bytecode, produce garbled
> > > bytecode? In that case, it seems  even better to raise an exception.
> > 
> > Yes, they can produce garbled bytecode, and if that is detected, it's
> > not safe to proceed.  So a fatal error is the right thing.
> 
> The problem with letting Python code cause fatal errors is that it makes
> restricted execution much more difficult. Well, something to think about
> for 2.1...

Huh?  In restricted execution you shouldn't be allowed to mess with
bytecode!

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



From guido at python.org  Wed Oct 11 17:25:32 2000
From: guido at python.org (Guido van Rossum)
Date: Wed, 11 Oct 2000 10:25:32 -0500
Subject: [Python-Dev] Re: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison)
In-Reply-To: Your message of "Wed, 11 Oct 2000 09:56:50 -0400."
             <20001011095650.A17931@kronos.cnri.reston.va.us> 
References: <slrn8u73ug.8jj.hzhu@rock.localdomain> <LNBBLJKPBEHFEDALKOLCKELGHKAA.tim_one@email.msn.com> <20001011102614.R12812@xs4all.nl>  
            <20001011095650.A17931@kronos.cnri.reston.va.us> 
Message-ID: <200010111525.KAA03324@cj20424-a.reston1.va.home.com>

Bingo!

1.5.2 links with -lieee while 2.0 doesn't.  Removing -lieee from the
1.5.2 link line makes is raise OverflowError too.  Adding it to the
2.0 link line makes it return 0.0 for exp(-1000) and inf for
exp(1000).

Next question: what changed in the configure script, and why?

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



From thomas at xs4all.net  Wed Oct 11 16:24:37 2000
From: thomas at xs4all.net (Thomas Wouters)
Date: Wed, 11 Oct 2000 16:24:37 +0200
Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison)
In-Reply-To: <20001011102614.R12812@xs4all.nl>; from thomas@xs4all.net on Wed, Oct 11, 2000 at 10:26:14AM +0200
References: <slrn8u73ug.8jj.hzhu@rock.localdomain> <LNBBLJKPBEHFEDALKOLCKELGHKAA.tim_one@email.msn.com> <20001011102614.R12812@xs4all.nl>
Message-ID: <20001011162436.T12812@xs4all.nl>

On Wed, Oct 11, 2000 at 10:26:14AM +0200, Thomas Wouters wrote:

[ Py2.0 mathmodule behaves differently when doing math.exp(-1000) and such ]

> Actually, there was some activity to define the right combination of
> _GNU_SOURCE, _POSIX_SOURCE, _XOPEN_SOURCE, _BSD_SOURCE, et al, but I'm not
> sure what the end result was. If any #define changes the behaviour of glibc,
> these would definately be it ! A simple test might be to compile 1.5.2 with
> the config.h from 2.0, and manually add whatever _*_SOURCE defines aren't in
> 1.5.2. (They reside in Python.h and config.h, currently.) I'll see if I can
> reproduce it on the glibc almost-2.2 (that is, glibc-2.1.94) systems here,
> and do some of the above tests.

Well, that was no success. I do see the difference between 1.5.2 and 2.0,
but *damned* if I can figure out where it comes from. It doesn't seem to be
any of the properly placed defines, and it doesn't seem to be the changes in
mathmodule itself. Not autoconf, either. What I did:

old tree (stock Python 1.5.2): math.exp(-1000) returns 0.0
new tree (current CVS): math.exp(-1000) raises OverflowError

(No difference between threads enabled and disabled.)

Use new config.h in old tree: math.exp(-1000) returned 0.0

Add _GNU_SOURCE and _XOPEN_SOURCE definitions (respectively 1 and 500, just
like new Python.h does) to Python.h in old tree: math.exp(-1000) returns 0.0

Copy mathmodule.c and mymath.h from old tree to new tree: math.exp(-1000)
raises OverflowError

Copy new mathmodule.c to old tree (adding an 'include math.h' because the
old Python.h isn't doing that): math.exp(-1000) returns 0.0

Copy config.h and Python.h from new tree to old one (removing the include of
unicodestring.h and codecs.h, and including mymalloc.h rather than pymem.h
to make it compile): math.exp(-1000) returns 0.0

So, as far as I can tell, it's not related to any code in mathmodule.c
itself, nor any defines in config.h or Python.h. mymath.h isn't used either,
as far as I can tell it only contains stuff for broken math stuff on obscure
platforms. Sounds like time for that glibc expert right about now ;-P

-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!



From akuchlin at mems-exchange.org  Wed Oct 11 16:32:23 2000
From: akuchlin at mems-exchange.org (Andrew Kuchling)
Date: Wed, 11 Oct 2000 10:32:23 -0400
Subject: [Python-Dev] Re: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison)
In-Reply-To: <200010111525.KAA03324@cj20424-a.reston1.va.home.com>; from guido@python.org on Wed, Oct 11, 2000 at 10:25:32AM -0500
References: <slrn8u73ug.8jj.hzhu@rock.localdomain> <LNBBLJKPBEHFEDALKOLCKELGHKAA.tim_one@email.msn.com> <20001011102614.R12812@xs4all.nl> <20001011095650.A17931@kronos.cnri.reston.va.us> <200010111525.KAA03324@cj20424-a.reston1.va.home.com>
Message-ID: <20001011103223.C17931@kronos.cnri.reston.va.us>

On Wed, Oct 11, 2000 at 10:25:32AM -0500, Guido van Rossum wrote:
>1.5.2 links with -lieee while 2.0 doesn't.  
>Next question: what changed in the configure script, and why?

The patch from revisions 1.138 to 1.139 of configure.in is:

853c1139,1142
< AC_CHECK_LIB(ieee, __fpu_control)
---
> AC_CHECK_FUNC(__fpu_control,
>   [],
>   [AC_CHECK_LIB(ieee, __fpu_control)
> ])

The check-in comment is "Only link with -lieee when it's necessary".
If it only checks for -lieee when the __fpu_control function is
defined, perhaps the function disappeared in glibc 2.1.

--amk



From thomas at xs4all.net  Wed Oct 11 16:32:45 2000
From: thomas at xs4all.net (Thomas Wouters)
Date: Wed, 11 Oct 2000 16:32:45 +0200
Subject: [Python-Dev] Re: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison)
In-Reply-To: <200010111525.KAA03324@cj20424-a.reston1.va.home.com>; from guido@python.org on Wed, Oct 11, 2000 at 10:25:32AM -0500
References: <slrn8u73ug.8jj.hzhu@rock.localdomain> <LNBBLJKPBEHFEDALKOLCKELGHKAA.tim_one@email.msn.com> <20001011102614.R12812@xs4all.nl> <20001011095650.A17931@kronos.cnri.reston.va.us> <200010111525.KAA03324@cj20424-a.reston1.va.home.com>
Message-ID: <20001011163244.U12812@xs4all.nl>

On Wed, Oct 11, 2000 at 10:25:32AM -0500, Guido van Rossum wrote:

> 1.5.2 links with -lieee while 2.0 doesn't.  Removing -lieee from the
> 1.5.2 link line makes is raise OverflowError too.  Adding it to the
> 2.0 link line makes it return 0.0 for exp(-1000) and inf for
> exp(1000).

Ack, that's the one thing I didn't check: link libraries ;-P

> Next question: what changed in the configure script, and why?

Well, that's easy. 

Old configure.in:

# Linux requires this for correct f.p. operations
AC_CHECK_LIB(ieee, __fpu_control)

New configure.in:

# Linux requires this for correct f.p. operations
AC_CHECK_FUNC(__fpu_control,
  [],
  [AC_CHECK_LIB(ieee, __fpu_control)
])

I remember the patch that did this, on SF. It was titled "don't link with
-lieee if it isn't necessary" or something. Not sure what it would break,
but mayhaps declaring -lieee necessary on glibc systems is the right fix ?

(For the non-autoconf readers among us: the first snippet writes a test
program to see if the function '__fpu_control' exists when linking with
-lieee in addition to $LIBS, and if so, adds -lieee to $LIBS. The second
snippet writes a test program to see if the function '__fpu_control' exists
with the current collection of $LIBS. If it doesn't, it tries it again with
-lieee, and adds -lieee to $LIBS if it finds it then.)

Pesonally, I think the patch should just be reversed... The comment above
the check certainly could be read as 'Linux requires -lieee for correct f.p.
operations', and perhaps that's how it was meant.

-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!



From skip at mojam.com  Wed Oct 11 18:31:48 2000
From: skip at mojam.com (Skip Montanaro)
Date: Wed, 11 Oct 2000 11:31:48 -0500 (CDT)
Subject: [Python-Dev] -Wall output for the Python 2.0c1
In-Reply-To: <LNBBLJKPBEHFEDALKOLCMELAHKAA.tim_one@email.msn.com>
References: <14819.34443.951260.635718@cj42289-a.reston1.va.home.com>
	<LNBBLJKPBEHFEDALKOLCMELAHKAA.tim_one@email.msn.com>
Message-ID: <14820.38388.827883.710489@beluga.mojam.com>

    Tim> I'll take this one.  It looks easy to fix ...

Seems to me like a patch that ought to wait until after 2.0final.  It's
definitely not a show-stopping bug...

Skip



From thomas at xs4all.net  Wed Oct 11 20:04:31 2000
From: thomas at xs4all.net (Thomas Wouters)
Date: Wed, 11 Oct 2000 20:04:31 +0200
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Python ceval.c,2.207,2.208
In-Reply-To: <200010111503.KAA03123@cj20424-a.reston1.va.home.com>; from guido@python.org on Wed, Oct 11, 2000 at 10:03:00AM -0500
References: <Pine.GSO.4.10.10010111555020.7162-100000@sundial> <200010111503.KAA03123@cj20424-a.reston1.va.home.com>
Message-ID: <20001011200431.V12812@xs4all.nl>

On Wed, Oct 11, 2000 at 10:03:00AM -0500, Guido van Rossum wrote:

> > > > Can't user Python code, fiddling around with bytecode, produce garbled
> > > > bytecode? In that case, it seems  even better to raise an exception.

> > > Yes, they can produce garbled bytecode, and if that is detected, it's
> > > not safe to proceed.  So a fatal error is the right thing.

> > The problem with letting Python code cause fatal errors is that it makes
> > restricted execution much more difficult. Well, something to think about
> > for 2.1...

> Huh?  In restricted execution you shouldn't be allowed to mess with
> bytecode!

Well, I can see what Moshe means. You get a code object passed in, say, an
untrusted pickle or some such. You want to execute it, but you don't want it
to ruin your life. Causing the entire program to quit could be considered
'ruining'. On the other hand, if you can hand-tweak bytecode streams in that
degree, you can f** up a lot more. On the one foot, though, most of the
calls to Py_FatalError (as far as I can see) deal with initialization
failures, or structures to which tweaked bytecode would not have access. On
the other foot, it's probably possible to tweak bytecode to *get* access to
those structures, or at least structures that don't like being dereferenced
or DECREF'd. And there's probably more to consider, but I haven't got any
public appendages left, and there might be children listening ;)

All in all, Guido's probably right... If something like this happens, you
don't want to continue. If the argument to DUP_TOPX is something other than
what compile.c generates (between 1 and 5, inclusive, that is) something
strange is going on internally. Better to quit now than delete
c:\command.com by 'accident'. If people can do this to code being run in
restricted environments, they can probably do worse things, too!

Now I just need an OK from Jeremy, as the maitre d', and I'll check it in.

-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!



From guido at python.org  Wed Oct 11 23:19:28 2000
From: guido at python.org (Guido van Rossum)
Date: Wed, 11 Oct 2000 16:19:28 -0500
Subject: [Python-Dev] Re: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison)
In-Reply-To: Your message of "Wed, 11 Oct 2000 16:32:45 +0200."
             <20001011163244.U12812@xs4all.nl> 
References: <slrn8u73ug.8jj.hzhu@rock.localdomain> <LNBBLJKPBEHFEDALKOLCKELGHKAA.tim_one@email.msn.com> <20001011102614.R12812@xs4all.nl> <20001011095650.A17931@kronos.cnri.reston.va.us> <200010111525.KAA03324@cj20424-a.reston1.va.home.com>  
            <20001011163244.U12812@xs4all.nl> 
Message-ID: <200010112119.QAA03651@cj20424-a.reston1.va.home.com>

Thanks for digging deeper into this.

> Pesonally, I think the patch should just be reversed... The comment above
> the check certainly could be read as 'Linux requires -lieee for correct f.p.
> operations', and perhaps that's how it was meant.

No, the configure patch is right.  Tim will check in a change that
treats ERANGE with a return value of 0.0 as underflow (returning 0.0,
not raising OverflowError).

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



From tim_one at email.msn.com  Wed Oct 11 23:02:16 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Wed, 11 Oct 2000 17:02:16 -0400
Subject: [Python-Dev] -Wall output for the Python 2.0c1
In-Reply-To: <14820.38388.827883.710489@beluga.mojam.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCAENEHKAA.tim_one@email.msn.com>

[Tim]
> I'll take this one [wngs putatively due to DUP_TOPX].  It looks easy
> to fix ...

[Skip Montanaro]
> Seems to me like a patch that ought to wait until after 2.0final.  It's
> definitely not a show-stopping bug...

Would have been a more interesting argument had you posted this before the
patch was checked in <wink>.

But wngs are non-negotiable with me anyway.  This example turned out to be a
good one for showing why:  the bogus wngs covered up a legitimate
"uninitialized vrbl" complaint (see Fred's later discovery and following
checkin).  I've simply got zero tolerance for wngs or for failures in the
std test suite.  My view is warped by prior experience, though:  the last 6
years, I worked on projects where the compilers were fiddled to treat
warnings as fatal errors.  So while this may have looked like a harmless
batch of wngs to you, as far as I was concerned Python couldn't even be
compiled anymore <0.7 wink>.

extremism-in-defense-of-simple-best-practice-may-or-may-not-be-
    vice-but-it's-sure-effective-over-the-long-term-ly y'rs  - tim





From skip at mojam.com  Wed Oct 11 23:07:42 2000
From: skip at mojam.com (Skip Montanaro)
Date: Wed, 11 Oct 2000 16:07:42 -0500 (CDT)
Subject: [Python-Dev] -Wall output for the Python 2.0c1
In-Reply-To: <LNBBLJKPBEHFEDALKOLCAENEHKAA.tim_one@email.msn.com>
References: <14820.38388.827883.710489@beluga.mojam.com>
	<LNBBLJKPBEHFEDALKOLCAENEHKAA.tim_one@email.msn.com>
Message-ID: <14820.54942.114086.773609@beluga.mojam.com>

    Tim> [Tim]
    >> I'll take this one [wngs putatively due to DUP_TOPX].  It looks easy
    >> to fix ...

    Tim> [Skip Montanaro]
    >> Seems to me like a patch that ought to wait until after 2.0final.
    >> It's definitely not a show-stopping bug...

    Tim> Would have been a more interesting argument had you posted this
    Tim> before the patch was checked in <wink>.

Agreed, but I posted as soon as I saw it.  Can't help it if I can't keep up
with all the flurry of activity.

    Tim> So while this may have looked like a harmless batch of wngs to you,
    Tim> as far as I was concerned Python couldn't even be compiled anymore
    Tim> <0.7 wink>.

I accept your explanation. ;-)

S



From jack at oratrix.nl  Wed Oct 11 23:10:36 2000
From: jack at oratrix.nl (Jack Jansen)
Date: Wed, 11 Oct 2000 23:10:36 +0200
Subject: [Python-Dev] test_StringIO failing on the Mac
Message-ID: <20001011211041.96D2BE266F@oratrix.oratrix.nl>

I have one remaining problem (at least, as far as I'm aware:-) with
2.0c1 on the Mac: test_StringIO fails.

The reason is that the test_StringIO output file was generated on
Unix, and hence it uses the unix form of string.letters (a-zA-Z),
whereas the Mac version of string.letters has far more values.

As this isn't what the test is about in the first place, shall I fix
the test?
--
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/ ++++



From tim_one at email.msn.com  Wed Oct 11 23:14:17 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Wed, 11 Oct 2000 17:14:17 -0400
Subject: [Python-Dev] test_StringIO failing on the Mac
In-Reply-To: <20001011211041.96D2BE266F@oratrix.oratrix.nl>
Message-ID: <LNBBLJKPBEHFEDALKOLCIENFHKAA.tim_one@email.msn.com>

[Jack Jansen]
> I have one remaining problem (at least, as far as I'm aware:-) with
> 2.0c1 on the Mac: test_StringIO fails.
> 
> The reason is that the test_StringIO output file was generated on
> Unix, and hence it uses the unix form of string.letters (a-zA-Z),
> whereas the Mac version of string.letters has far more values.
> 
> As this isn't what the test is about in the first place, shall I fix
> the test?

+1 from me on making the test portable.





From jeremy at beopen.com  Thu Oct 12 01:06:56 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Wed, 11 Oct 2000 19:06:56 -0400 (EDT)
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Python ceval.c,2.207,2.208
In-Reply-To: <20001011200431.V12812@xs4all.nl>
References: <Pine.GSO.4.10.10010111555020.7162-100000@sundial>
	<200010111503.KAA03123@cj20424-a.reston1.va.home.com>
	<20001011200431.V12812@xs4all.nl>
Message-ID: <14820.62096.15085.749912@bitdiddle.concentric.net>

>>>>> "TW" == Thomas Wouters <thomas at xs4all.net> writes:

  [Moshe:]
  >> > The problem with letting Python code cause fatal errors is that
  >> > it makes restricted execution much more difficult. Well,
  >> > something to think about for 2.1...

  [Guido:]
  >> Huh?  In restricted execution you shouldn't be allowed to mess
  >> with bytecode!

  TW> Well, I can see what Moshe means. You get a code object passed
  TW> in, say, an untrusted pickle or some such. You want to execute
  TW> it, but you don't want it to ruin your life. Causing the entire
  TW> program to quit could be considered 'ruining'. On the other
  TW> hand, if you can hand-tweak bytecode streams in that degree, you
  TW> can f** up a lot more.

Damn straight!  If you're using restricted execution mode and
accepting bytecode objects that weren't produced by a trusted Python
compiler, you're nuts.  I am not aware of any effort made to protect
the Python VM from attack via malicious bytecode.

  TW> Now I just need an OK from Jeremy, as the maitre d', and I'll
  TW> check it in.

Your table is ready.  A checkin message will be accepted as gratuity. 

Jeremy



From jeremy at beopen.com  Thu Oct 12 01:12:15 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Wed, 11 Oct 2000 19:12:15 -0400 (EDT)
Subject: [Python-Dev] Re: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison)
In-Reply-To: <200010112119.QAA03651@cj20424-a.reston1.va.home.com>
References: <slrn8u73ug.8jj.hzhu@rock.localdomain>
	<LNBBLJKPBEHFEDALKOLCKELGHKAA.tim_one@email.msn.com>
	<20001011102614.R12812@xs4all.nl>
	<20001011095650.A17931@kronos.cnri.reston.va.us>
	<200010111525.KAA03324@cj20424-a.reston1.va.home.com>
	<20001011163244.U12812@xs4all.nl>
	<200010112119.QAA03651@cj20424-a.reston1.va.home.com>
Message-ID: <14820.62415.873159.533077@bitdiddle.concentric.net>

I checked in the patch that removed the -lieee link in some cases.  I
don't remember the details off the top of my head, but I can go
digging in the SF patch logs if it's important.  As I recall, someone
reported problems on a platform (HPUX?) where link with ieee caused
problems.  I didn't have access to the platform in question.  So I
applied the patch on a Linux box and ran the regression test; it
reported no errors, so I assumed the patch fixed some other platform
and did mine no harm.

At the moment, I would assume that the patch still helps some other
platform but might not be right on Linux.  On the other hand, it
sounds like Tim has a patch that will cause Linux to do the right
thing.

It's hard to say much about what should or should not happen since
neither the language reference nor the regression tests specifies much
about what should happen with fp.

Jeremy




From thomas at xs4all.net  Thu Oct 12 01:15:21 2000
From: thomas at xs4all.net (Thomas Wouters)
Date: Thu, 12 Oct 2000 01:15:21 +0200
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules dlmodule.c,2.14,2.15
In-Reply-To: <200010112144.OAA20776@slayer.i.sourceforge.net>; from fdrake@users.sourceforge.net on Wed, Oct 11, 2000 at 02:44:05PM -0700
References: <200010112144.OAA20776@slayer.i.sourceforge.net>
Message-ID: <20001012011521.X12812@xs4all.nl>

On Wed, Oct 11, 2000 at 02:44:05PM -0700, Fred L. Drake wrote:
> Update of /cvsroot/python/python/dist/src/Modules
> In directory slayer.i.sourceforge.net:/tmp/cvs-serv20717
> 
> Modified Files:
> 	dlmodule.c 
> Log Message:
> 
> Remove one more gcc -Wall warning.

To note, if gcc didn't inherit at least *some* of C's original philosophy of
'the programmer always knows what [s]he is doing', gcc would yell bloody
murder at this code. The 'func' function pointer is used to point to symbols
loaded from arbitrary shared objects, and the dlmodule has no way of knowing
howmany arguments the function expects, or even if it isn't more than 10
(which would result in the function grabbing garbage off the stack, on most
architectures, I think.) While on the ANSIfication spree, I ran screaming
and hid under my bed after reading this code ;)

Is anyone using the dlmodule anymore ? Is it really useful ? Is this
*really* how loading and calling arbitrary shared objects should be done ? :P

>   {
>   	PyObject *name;
> ! 	long (*func)(long, long, long, long, long,
> !                      long, long, long, long, long);
>   	long alist[10];
>   	long res;

Idle-and-post-2.0-talk-ly y'rs,
-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!



From huaiyu_zhu at yahoo.com  Thu Oct 12 01:33:08 2000
From: huaiyu_zhu at yahoo.com (Huaiyu Zhu)
Date: Wed, 11 Oct 2000 16:33:08 -0700 (PDT)
Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich
 comparison)
In-Reply-To: <LNBBLJKPBEHFEDALKOLCOELMHKAA.tim_one@email.msn.com>
Message-ID: <Pine.LNX.4.10.10010111510270.3131-100000@rocket.knowledgetrack.com>

On the issue of whether Python should ignore over/underflow on IEEE-enabled
platforms: 

[Tim Peters]
> That would stop the exception on exp() underflow, which is what you're
> concerned about.  It would also stop exceptions on exp() overflow, and on
> underflow and overflow for all other math functions too.  I doubt Guido will
> ever let Python ignore overflow by default, #ifdef'ed or not.  A semantic
> change that jarring certainly won't happen for 2.0 (which is just a week
> away).

It can be argued that on IEEE enabled systems the proper thing to do for
overflow is simply return Inf.  Raising exception is WRONG.  See below.

[Guido van Rossum]
> Incidentally, math.exp(800) returns inf in 1.5, and raises
> OverflowError in 2.0.  So at least it's consistent.

That is not consistent at all.  Suppose I'm plotting the curve f(x) where
x include some singular points of f.  In the first case the plot works with
some portion of the curve clipped.  In the second case it bombs.  

[Tim Peters] 
> Nothing like that will happen without a PEP first.  I would like to see
> *serious* 754 support myself, but that depends too on many platform experts
> contributing real work (if everyone ran WinTel, I could do it myself
> <wink>).

[Guido van Rossum]
> Bingo!
> 
> 1.5.2 links with -lieee while 2.0 doesn't.  Removing -lieee from the
> 1.5.2 link line makes is raise OverflowError too.  Adding it to the
> 2.0 link line makes it return 0.0 for exp(-1000) and inf for
> exp(1000).

If using ieee is as simple as setting such a flag, there is no reason at all
not to use it.  Here are some more examples:

Suppose you have done hours of computation on a problem.  Just as you are
about to get the result, you get an exception.  Why?  Because the residual
error is too close to zero.

Suppose you want to plot the curve of Gausian distribution.  Oops, it fails.
Because beyond a certain region the value is near zero.

With these kinds of problems, vectorized numerical calculation becomes
nearly impossible.  How do you work in such an environment?  You have to
wrap every calculation in a try/except structure, and whenever there is an
exception, you have to revert to elementwise operations.  In practice this
simply means Python would not be suitable for numerical work at all.

What about the other way round?  No problem.  It is easy to write functions
like isNaN, isInf, etc.  With these one can raise exceptions in any place
one want.  It is even possible to raise exceptions if a matrix is singular
to a certain precision, etc.

The key point to observe here is that most numerical work involve more than
one element.  Some of them may be out of mahcine bounds but the whole thing
could still be quite meaningful.  Vice versa it is also quite possible that
all elements are within bounds while the whole thing is meaningless.  The
language should never take over or subvert decisions based on numerical
analysis.

[Tim Peters] 
> Ignoring ERANGE entirely is not at all the same behavior as 1.5.2, and
> current code certainly relies on detecting overflows in math functions. 

As Guido observed ERANGE is not generated with ieee, even for overflow.  So
it is the same behavior as 1.5.2.  Besides, no correct numerical code should
depend on exceptions like this unless the machine is incapable of handling
Inf and NaN.

Even in the cases where you do want to detect overflow, it is still wrong to
use exceptions.  Here's an example: x*log(x) approaches 0 as x approaches 0.
If x==0 then log(x)==-Inf but 0*-Inf==NaN, not what one would want.  But
exception is the wrong tool to hangle this, because if x is an array, some
of its element may be zero but other's may not.  The right way to do it is
something like

def entropy(probability):
  p = max(probability, 1e-323)
  return p*log(p)

[Tim Peters]
> In no case can you expect to see overflow ignored in 2.0.

You are proposing a dramatic change from the behavior of 1.5.2.  This looks
like to me to need a PEP and a big debate.  It would break a LOT of
numerical computations.

[Thomas Wouters]
> I remember the patch that did this, on SF. It was titled "don't link with
> -lieee if it isn't necessary" or something. Not sure what it would break,
> but mayhaps declaring -lieee necessary on glibc systems is the right fix ?
>
> (For the non-autoconf readers among us: the first snippet writes a test
> program to see if the function '__fpu_control' exists when linking with
> -lieee in addition to $LIBS, and if so, adds -lieee to $LIBS. The second
> snippet writes a test program to see if the function '__fpu_control'
> exists with the current collection of $LIBS. If it doesn't, it tries it
> again with -lieee,
>
> Pesonally, I think the patch should just be reversed... The comment above
> the check certainly could be read as 'Linux requires -lieee for correct
> f.p. operations', and perhaps that's how it was meant.

The patch as described seems to be based on flawed thinking.  The numbers
Inf and NaN are always necessary.  The -lieee could only be unnecessary if
the behavior is the same as IEEE.  Obviously it isn't.  So I second Thomas's
suggestion. 

[Tim Peters]
> If no progress is made on determining the true cause over the next few days,
> I'll hack mathmodule.c to ignore ERANGE in the specific case the result
> returned is a zero (which would "fix" your exp underflow problem without
> stopping overflow detection).  Since this will break code on any platform
> where errno was set to ERANGE on underflow in 1.5.2, I'll need to have a
> long discussion w/ Guido first.  I *believe* that much is actually sellable
> for 2.0, because it moves Python in a direction I know he likes regardless
> of whether he ever becomes a 754 True Believer.

[Guido van Rossum]
> No, the configure patch is right.  Tim will check in a change that
> treats ERANGE with a return value of 0.0 as underflow (returning 0.0,
> not raising OverflowError).

What is the reason to do this?  It looks like intetionally subverting ieee
even when it is available.  I thought Tim meant that only logistical
problems prevent using ieee.

If you do choose this route, please please please ignore ERANGE entirely,
whether return value is zero or not.

The only possible way that ERANGE could be useful at all is if it could be
set independently for each element of an array, and if it behave as a
warning instead of an exception, ie.  the calculation would continue if it
is not caught.  Well, then, Inf and NaN serve this purpose perfectly.

It is very reasonable to set errno in glibc for this; it is completely
unreasonable to raise an exception in Python, because exceptions cannot be
set to individual elements and they cannot be ignored.


Huaiyu
-- 
Huaiyu Zhu                       hzhu at users.sourceforge.net
Matrix for Python Project        http://MatPy.sourceforge.net 





From pauldubois at home.com  Thu Oct 12 02:04:51 2000
From: pauldubois at home.com (Paul F. Dubois)
Date: Wed, 11 Oct 2000 17:04:51 -0700
Subject: [Python-Dev] RE: [Numpy-discussion] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison)
In-Reply-To: <Pine.LNX.4.10.10010111510270.3131-100000@rocket.knowledgetrack.com>
Message-ID: <ADEOIFHFONCLEEPKCACCGEFHCBAA.pauldubois@home.com>

I don't have time to follow in detail this thread about changed behavior
between versions. These observations are based on working with hundreds of
code authors. I offer them as is.

a. Nobody runs a serious numeric calculation without setting
underflow-to-zero, in the hardware. You can't even afford the cost of
software checks. Unfortunately there is no portable way to do that that I
know of.

b. Some people use Inf but most people want the code to STOP so they can
find out where the INFS started. Otherwise, two hours later you have big
arrays of Infs and no idea how it happened. Likewise sqrt(-1.) needs to
stop, not put a zero and keep going.









From guido at python.org  Thu Oct 12 03:45:30 2000
From: guido at python.org (Guido van Rossum)
Date: Wed, 11 Oct 2000 20:45:30 -0500
Subject: [Python-Dev] RE: [Numpy-discussion] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison)
In-Reply-To: Your message of "Wed, 11 Oct 2000 17:04:51 MST."
             <ADEOIFHFONCLEEPKCACCGEFHCBAA.pauldubois@home.com> 
References: <ADEOIFHFONCLEEPKCACCGEFHCBAA.pauldubois@home.com> 
Message-ID: <200010120145.UAA02030@cj20424-a.reston1.va.home.com>

> I don't have time to follow in detail this thread about changed behavior
> between versions. These observations are based on working with hundreds of
> code authors. I offer them as is.
> 
> a. Nobody runs a serious numeric calculation without setting
> underflow-to-zero, in the hardware. You can't even afford the cost of
> software checks. Unfortunately there is no portable way to do that that I
> know of.
> 
> b. Some people use Inf but most people want the code to STOP so they can
> find out where the INFS started. Otherwise, two hours later you have big
> arrays of Infs and no idea how it happened. Likewise sqrt(-1.) needs to
> stop, not put a zero and keep going.

Thanks, Paul!  This behavior has always been what I wanted Python to
do (even though it's not always what Python did, depending on the
platform) and also what Tim's proposed patch will implement for the
specific case of math.exp() (and other math functions that may
underflow or overflow), on most reasonable platforms.

There are still lots of places where the platform gives Python no
choice of creating NaN and Inf, and because there's no
platform-independent way to test for these, they are hard to avoid in
some cases; but eventually, Tim will find a way to root them out.  And
for people like Huaiyu, who want to see Inf, there will (eventually)
be a way to select this as a run-time option; and ditto for whoever
might want underflow to raise an exception.

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



From huaiyu_zhu at yahoo.com  Thu Oct 12 04:22:54 2000
From: huaiyu_zhu at yahoo.com (Huaiyu Zhu)
Date: Wed, 11 Oct 2000 19:22:54 -0700 (PDT)
Subject: [Python-Dev] RE: [Numpy-discussion] RE: Possible bug (was Re:
 numpy, overflow, inf, ieee, and rich comparison)
In-Reply-To: <200010120145.UAA02030@cj20424-a.reston1.va.home.com>
Message-ID: <Pine.LNX.4.10.10010111833510.3385-100000@rocket.knowledgetrack.com>

[Paul Dubois]
> > 
> > a. Nobody runs a serious numeric calculation without setting
> > underflow-to-zero, in the hardware. You can't even afford the cost of
> > software checks. Unfortunately there is no portable way to do that that I
> > know of.

Amen.

> > 
> > b. Some people use Inf but most people want the code to STOP so they can
> > find out where the INFS started. Otherwise, two hours later you have big
> > arrays of Infs and no idea how it happened. Likewise sqrt(-1.) needs to
> > stop, not put a zero and keep going.

$ /usr/bin/python
Python 1.5.2 (#1, Sep 17 1999, 20:15:36)  [GCC egcs-2.91.66 19990314/Linux
(egcs- on linux-i386
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> from math import *
>>> exp(777)
inf
>>> exp(-777)
0.0
>>> sqrt(-1)
Traceback (innermost last):
  File "<stdin>", line 1, in ?
OverflowError: math range error

This was sane behavior.  Are we saying that Python 2.0 has invented
something better than IEEE 754?

[Guido van Rossum]

> Thanks, Paul!  This behavior has always been what I wanted Python to
> do (even though it's not always what Python did, depending on the
> platform) and also what Tim's proposed patch will implement for the
> specific case of math.exp() (and other math functions that may
> underflow or overflow), on most reasonable platforms.

Guido, with due respect to your decisions on Python issues, I simply have to
fight this one.  It is one thing to accomodate for naive users, but it is
another to dumb down every one else.

Case 1.  Someone writes a flawed numerical routine.  Two hours later he
finds his array filled with Inf and NaN.

Case 2.  Someone writes a perfect numerical routine.  Two hours later he
gets an exception, because the error is near zero.

Solution for case 1.  Use better algorithm.  Use better error control.
Raise exceptions when error is too large.  These are proper solutions.  
They are easy and efficient to implement.  They are needed anyway - If
something's wrong, you want to raise exceptions far earlier than Inf,
certainly before you get arrays filled with elements like 1e300.

Solution for case 2.  Almost impossible.  The division between under- and
over-flow is artificial.  What about 1/x or similar functions?  The only way
to work on such a platform is to abandon vectorized computation.

> There are still lots of places where the platform gives Python no
> choice of creating NaN and Inf, and because there's no
> platform-independent way to test for these, they are hard to avoid in
> some cases; but eventually, Tim will find a way to root them out.  And
> for people like Huaiyu, who want to see Inf, there will (eventually)
> be a way to select this as a run-time option; and ditto for whoever
> might want underflow to raise an exception.

I can understand that exceptions are the only available choices if IEEE is
not available.  But is there a compelling reason that Python should behave
"better" than IEEE when it's in fact available?

If the reason is to protect naive users, I can think of several responses:

1. For people doing one-off interactive work, returning Inf is in fact more
   informative. 

2. For users iterative numerical computations, they need to be educated
   about error control.  Otherwise they won't get corrent results anyway.

3. For really serious work, we could provide good numerical modules so that
   they don't need to write themselves.  To make this happen fast the fewer
   debacles like this one the better.

Case in point: Someone asked for regession modules two weeks ago.  I was
trying to convert my old matlab programs, which only took a few hours.  But
I wasted a week of (spare) time fighting for some mysterious "overflow".
Turns out that a Guassian is near zero when it's far from center, and Python
does not like it.

In practice, Inf may be generated more often as a proper value than by
mistake.

This is not an issue about whether someone "prefers" Inf or exception.  It
is about whether there is a choice to do proper computation.  Returning Inf
does not prevent someone to raise exception.  Raising exception
automatically prevents perfect algorithms to work properly.

As Kevin has volunteered to help with IEEE implementation and made a plan,
is there a strong reason to drop IEEE for Linux in 2.0?  If there is
insufficient time to carry out his plan, wouldn't it be prudent to keep
things as they were in 1.5.2?

Huaiyu




From tim_one at email.msn.com  Thu Oct 12 04:44:20 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Wed, 11 Oct 2000 22:44:20 -0400
Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison)
In-Reply-To: <Pine.LNX.4.10.10010111510270.3131-100000@rocket.knowledgetrack.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCKENNHKAA.tim_one@email.msn.com>

[Huaiyu Zhu]
> On the issue of whether Python should ignore over/underflow on
> IEEE-enabled platforms:
>
> It can be argued that on IEEE enabled systems the proper thing to do for
> overflow is simply return Inf.  Raising exception is WRONG.  See below.

Python was not designed with IEEE-754 in mind, and *anything* that happens
wrt Infs, NaNs, and all other 754 features in Python is purely an accident
that can and does vary wildly across platforms.  And, as you've discovered
in this case, can vary wildly also across even a single library, depending
on config options.  We cannot consider this to be a bug since Python has had
no *intended* behavior whatsoever wrt 754 gimmicks.  We can and do consider
gripes about these accidents to be feature requests.

[Guido]
> Incidentally, math.exp(800) returns inf in 1.5, and raises
> OverflowError in 2.0.  So at least it's consistent.

[Huaiyu]
> That is not consistent at all.

Please read with an assumption of good faith.  Guido was pointing out that--
all in the specific case of gcc+glibc on Linux (these don't hold on other
platforms) --exp(800) returning Inf in 1.5 and OverflowError in 2.0 is
consistent *with* that exp(-800) returns 0 in 1.5 and raises an exception in
2.0.  He's right; indeed, he is in part agreeing with you.

[Guido
> 1.5.2 links with -lieee while 2.0 doesn't.  Removing -lieee from the
> 1.5.2 link line makes is raise OverflowError too.  Adding it to the
> 2.0 link line makes it return 0.0 for exp(-1000) and inf for
> exp(1000).

[Huaiyu]
> If using ieee is as simple as setting such a flag, there is no
> reason at all not to use it.

The patch to stop setting -lieee was contributed by a Python user who
claimed it fixed bugs on *their* platform.  That's "the reason".  We don't
want to screw them either.

> Here are some more examples:
> ...

I understand that 754 semantics can be invaluable.  So does Guido.  There's
no argument about that.  But Python doesn't yet support them, and wishing it
did doesn't make it so.  If linking with -lieee happens to give you the
semantics you want on your platform today, you're welcome to build with that
switch.  It appears to be a bad choice for *most* Python users, though (more
below), so we don't want to do it in the std 2.0 distro.

> ...
> In practice this simply means Python would not be suitable for numerical
> work at all.

Your biggest obstacle in getting Python support for 754 will in fact be
opposition from number-crunchers.  I've been slinging fp for 21 years, 15 of
those writing compilers and math libraries for "supercomputer" vendors.  754
is a Very Good Thing, but is Evil in subset form (see Kahan's (justified!)
vilification of Java on this point); ironically, 754 is hardest to sell to
those who could benefit from it the most.

> What about the other way round?  No problem.  It is easy to write
> functions like isNaN, isInf, etc.

It's easy for a platform expert to write such functions for their specific
platform of expertise, but it's impossible to write them in a portable way
before C99 is implemented (C99 requires that library suppliers provide them,
rendering the question moot).

> ...
> The language should never take over or subvert decisions based on
> numerical analysis.

Which is why a subset of 754 is evil.  754 requires that the user be able to
*choose* whether or not, e.g., overflow signals an exception.  Your crusade
to insist that it never raise an exception is as least as bad (I think it's
much worse) as Python's most common accidental behavior (where overflow from
libm usually raises an exception).  One size does not fit all.

[Tim]
> Ignoring ERANGE entirely is not at all the same behavior as 1.5.2, and
> current code certainly relies on detecting overflows in math functions.

[Huaiyu]
> As Guido observed ERANGE is not generated with ieee, even for
> overflow.  So it is the same behavior as 1.5.2.

You've got a bit of a case of tunnel vision here, Huaiyu.  Yes, in the
specific case of gcc+glibc+Linux, ignoring ERANGE returned from exp() is
what 1.5.2 acted like.  But you have not proposed to ignore it merely from
ERANGE returned from exp() in the specific case of gcc+glibc+Linux.  This
code runs on many dozens of platforms, and, e.g., as I suggested before, it
looks like HPUX has always set errno on both overflow and underflow.  MS
Windows sets it on overflow but not underflow.  Etc.  We have to worry about
the effects on all platforms.

> Besides, no correct numerical code should depend on exceptions like
> this unless the machine is incapable of handling Inf and NaN.

Nonsense.  754 provides the option to raise an exception on overflow, or
not, at the user's discretion, precisely because exceptions are sometimes
more appropriate than Infs of NaNs.  Kahan himself isn't happy with Infs and
NaNs because they're too often too gross a clue (see his writings on
"presubstitution" for a more useful approach).

[Tim]
> In no case can you expect to see overflow ignored in 2.0.

[Huaiyu]
> You are proposing a dramatic change from the behavior of 1.5.2.
> This looks like to me to need a PEP and a big debate.  It would break
> a LOT of numerical computations.

I personally doubt that, but realize it may be true.  That's why he have
beta releases.  So far yours is the only feedback we've heard (thanks!), and
as a result we're going to change 2.0 to stop griping about underflow, and
do so in a way that will actually work across all platforms.  We're probably
going to break some HPUX programs as a result; but they were relying on
accidents too.

[Guido]
> No, the configure patch is right.  Tim will check in a change that
> treats ERANGE with a return value of 0.0 as underflow (returning 0.0,
> not raising OverflowError).

[Huaiyu]
> What is the reason to do this?  It looks like intetionally subverting
> ieee even when it is available.  I thought Tim meant that only logistical
> problems prevent using ieee.

Python does not support 754 today.  Period.  I would like it to, but not in
any half-assed, still platform-dependent, still random crap-shoot, still
random subset of 754 features, still rigidly inflexible, way.  When it does
support it, Guido & I will argue that it should enable (what 754 calls) the
overflow, divide-by-0 and invalid operation exceptions by default, and
disable the underflow and inexact exceptions by default.  This ensures that,
under the default, an infinity or NaN can never be created from
non-exceptional inputs without triggering an exception. Not only is that
best for newbies, you'll find it's the *only* scheme for a default that can
be sold to working number-crunchers (been there, done that, at Kendall
Square Research).  It also matches Guido's original, pre-754, *intent* for
how Python numerics should work by default (it is, e.g., no accident that
Python has always had an OverflowError exception but never an UnderflowError
one).

And that corresponds to the change Guido says <wink> I'm going to make in
mathmodule.c:  suppress complaints about underflow, but let complaints about
overflow go through.  This is not a solution, it's a step on a path towards
a solution.  The next step (which will not happen for 2.0!) is to provide an
explicit way to, from Python, disable overflow checking, and that's simply
part of providing the control and inquiry functions mandated by 754.  Then
code that would rather deal with Infs than exceptions can, at its explicit
discretion.

> If you do choose this route, please please please ignore ERANGE entirely,
> whether return value is zero or not.

It should be clear that isn't going to happen.  I realize that triggering
overflow is going to piss you off, but you have to realize that not
triggering overflow is going to piss more people off, and *especially* your
fellow number-crunchers.  Short of serious 754 support, picking "a winner"
is the best we can do for now.  You have the -lieee flag on your platform du
jour if you can't bear it.

[Paul Dubois]
> I don't have time to follow in detail this thread about changed behavior
> between versions.

What makes you think we do <0.5 wink>?

> These observations are based on working with hundreds of code authors. I
> offer them as is.

FWIW, they exactly match my observations from 15 years on the HW vendor
side.

> a. Nobody runs a serious numeric calculation without setting underflow-to-
> zero, in the hardware. You can't even afford the cost of software checks.
> Unfortunately there is no portable way to do that that I know of.

C allows libm implementations a lot of discretion in whether to set errno to
ERANGE in case of underflow.  The change we're going to make is to ignore
ERANGE in case of underflow, ensuring that math.* functions will *stop*
raising underflow exceptions on all platforms (they'll return a zero
instead; whether +0 or -0 will remain a platform-dependent crap shoot for
now).  Nothing here addresses underflow exceptions that may be raised by fp
hardware, though; this has solely to do with the platform libm's treatment
of errno.

So in this respect, we're removing Python's current unpredictability, and in
the way you favor.

> b. Some people use Inf but most people want the code to STOP so they can
> find out where the INFS started. Otherwise, two hours later you have big
> arrays of Infs and no idea how it happened.

Apparently Python on libc+glibc+Linux never raised OverflowError from math.*
functions in 1.5.2 (although it did on most other platforms I know about).
A patch checked in to fix some other complaint on some other Unixish
platform had the side-effect of making Python on libc+glibc+Linux start
raising OverflowError from math.* functions in 2.0, but in both overflow and
underflow cases.  We intend to (as above) suppress the underflow exceptions,
but let the overflow cases continue to raise OverflowError.  Huaiyu's
original complaint was about the underflow cases, but (as such things often
do) expanded beyond that when it became clear he would get what he asked for
<wink>.

Again we're removing Python's current unpredictability, and again in the way
you favor -- although this one is still at the mercy of whether the platform
libm sets errno correctly on overflow (but it seems that most do these
days).

> Likewise sqrt(-1.) needs to stop, not put a zero and keep going.

Nobody has proposed changing anything about libm domain (as opposed to
range) errors (although Huaiyu probably should if he's serious about his
flavor of 754 subsetism -- I have no idea what gcc+glibc+Linux did here on
1.5.2, but it *should* have silently returned a NaN (not a zero) without
setting errno if it was *self*-consistent -- anyone care to check that
under -lieee?:

    import math
    math.sqrt(-1)

NaN or ValueError?  2.0 should raise ValueError regardless of what 1.5.2 did
here.).

just-another-day-of-universal-python-harmony-ly y'rs  - tim





From sdm7g at virginia.edu  Thu Oct 12 05:23:32 2000
From: sdm7g at virginia.edu (Steven D. Majewski)
Date: Wed, 11 Oct 2000 23:23:32 -0400 (EDT)
Subject: [Python-Dev] RE: [Numpy-discussion] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison)
In-Reply-To: <Pine.LNX.4.10.10010111833510.3385-100000@rocket.knowledgetrack.com>
Message-ID: <Pine.A32.3.90.1001011225636.4671B-100000@elvis.med.Virginia.EDU>


First: I haven't followed this thread from the beginning -- only the
last ten or so posts. 

Second: One reason I didn't follow it from the start is that I'm not
doing any heavy numerical stuff in Python. I've been using Lisp for
that, and use Python more for string/symbolic or GUI hacking. 

But, if I was going to do the sort of numerical stuff I now do in 
Lisp in Python, I would agree with Huaiya Zhu. I do a lot of 
vectorized operations on what are often independent samples. 
If some of the numbers overflow or underflow, that just represents
an outlier or bad sample. I don't want it to blow off the whole
pipeline of operations on the other data points in the vector -- 
they are independent of the bad points. 

 In my case, it's not that these are lengthy calculations. It's
that they are interactive and tied to immediate graphical 
representations. If there are strange zero's or infinities in
the result, there is (or should be) a way to backtrack and 
investigate. ( That's why people want interactive and graphical
regression analysis and modeling tools! ) 

 The idea that your calculation should blow up and you should 
check it and resubmit your job sounds just so ancient-20th-century-
Fortran-JCL-and-punched-cards-technology! 
 

---|  Steven D. Majewski   (804-982-0831)  <sdm7g at Virginia.EDU>  |---
---|  Department of Molecular Physiology and Biological Physics  |---
---|  University of Virginia             Health Sciences Center  |---
---|  P.O. Box 10011            Charlottesville, VA  22906-0011  |---
		"All operating systems want to be unix, 
		 All programming languages want to be lisp." 




From tim_one at email.msn.com  Thu Oct 12 06:18:19 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Thu, 12 Oct 2000 00:18:19 -0400
Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison)
In-Reply-To: <20001011234038.A2322@better.net>
Message-ID: <LNBBLJKPBEHFEDALKOLCKEOFHKAA.tim_one@email.msn.com>

[William Park]
> On Wed, Oct 11, 2000 at 10:44:20PM -0400, Tim Peters wrote:
> > > Likewise sqrt(-1.) needs to stop, not put a zero and keep going.

I didn't write that.  Paul Dubois did.

> Hmm... I don't like this.  It should stop or return complex.

Paul said it should stop.  You said it should stop (or return complex).  So
what is it that you don't like <wink/frown>?  754 mandates that sqrt(x) for
x<0 return a NaN and keep going (by default) -- which even Huaiyu apparently
doesn't like.

[actually Tim]
> I have no idea what gcc+glibc+Linux  did here on 1.5.2, but it *should*
> have silently returned a NaN (not a zero) without setting errno if it
> was *self*-consistent -- anyone care to check that under -lieee?:
>
>      import math
>      math.sqrt(-1)
>
> NaN or ValueError?  2.0 should raise ValueError regardless of
> what 1.5.2 did here.).

[back to William]
> It returns 'OverflowError: math range error' in 1.5.2,

Ah, that's hilarious <wink>!  It's tempting to believe that glibc is
violating the IEEE std despite the -lieee flag in this case, but I don't
believe that's true:  it's almost certainly the case that glibc is actually
returning a NaN, *not* setting errno at all, and this other check in
Python's mathmodule.c:

#define CHECK(x) if (errno != 0) ; \
	else if (-HUGE_VAL <= (x) && (x) <= HUGE_VAL) ; \
	else errno = ERANGE

is setting errno to ERANGE purely due to an accident of the way gcc happens
to compile code for comparing NaN to Inf and -Inf.

> and 'ValueError: math domain error' in 2.0.

Which is the correct exception, so is another reason for Python to
avoid -lieee in 2.0.

will-be-easier-to-make-it-work-right-by-design-than-to-keep-doping-out-
    what-happens-by-accident-now-ly y'rs  - tim





From tim_one at email.msn.com  Thu Oct 12 08:16:23 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Thu, 12 Oct 2000 02:16:23 -0400
Subject: [Python-Dev] RE: [Numpy-discussion] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison)
In-Reply-To: <Pine.LNX.4.10.10010111833510.3385-100000@rocket.knowledgetrack.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCEEOHHKAA.tim_one@email.msn.com>

[Huaiyu Zhu]
> ...
> $ /usr/bin/python
> Python 1.5.2 (#1, Sep 17 1999, 20:15:36)  [GCC egcs-2.91.66 19990314/Linux
> (egcs- on linux-i386
> Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
> >>> from math import *
> >>> exp(777)
> inf
> >>> exp(-777)
> 0.0
> >>> sqrt(-1)
> Traceback (innermost last):
>   File "<stdin>", line 1, in ?
> OverflowError: math range error
>
> This was sane behavior.  Are we saying that Python 2.0 has invented
> something better than IEEE 754?

754 allows users to choose the behaviors they want.  Any *fixed* policy is
not 754.  So long as we have to fix a single policy, yes, I believe Guido (&
know I) would say that raising OverflowError on exp(777), and silently
returning 0 on exp(-777), and raising ValueError on sqrt(-1) (*not*
OverflowError, as shown above), is indeed better than the 754 default
behaviors.  And 2.0 will do all three of those (& I just checked in the code
to make that happen).

About the sqrt example above, that's neither 754 behavior nor sane behavior:
default 754 behavior on sqrt(-1) is to return a NaN and keep on going.  I'm
pretty sure that's what glibc linked w/ -lieee actually does, too (if it
doesn't, glibc -lieee is violating 754).  That 1.5.2 raised an OverflowError
instead is insane, and appears purely due to an accident of how gcc compiles
code to compare Infs to NaNs (Python's mathmodule.c's CHECK() macro was
fooled by this into setting errno to ERANGE itself).  Python should raise a
ValueError there instead (corresponding to libm setting errno to EDOM --
this is a domain error, not a range error) -- which it does now under CVS
Python.

754-doesn't-work-unless-you've-got-all-of-it-ly y'rs  - tim





From thomas at xs4all.net  Thu Oct 12 10:11:57 2000
From: thomas at xs4all.net (Thomas Wouters)
Date: Thu, 12 Oct 2000 10:11:57 +0200
Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison)
In-Reply-To: <LNBBLJKPBEHFEDALKOLCKENNHKAA.tim_one@email.msn.com>; from tim_one@email.msn.com on Wed, Oct 11, 2000 at 10:44:20PM -0400
References: <Pine.LNX.4.10.10010111510270.3131-100000@rocket.knowledgetrack.com> <LNBBLJKPBEHFEDALKOLCKENNHKAA.tim_one@email.msn.com>
Message-ID: <20001012101157.Y12812@xs4all.nl>

On Wed, Oct 11, 2000 at 10:44:20PM -0400, Tim Peters wrote:

> > Likewise sqrt(-1.) needs to stop, not put a zero and keep going.

> Nobody has proposed changing anything about libm domain (as opposed to
> range) errors (although Huaiyu probably should if he's serious about his
> flavor of 754 subsetism -- I have no idea what gcc+glibc+Linux did here on
> 1.5.2, but it *should* have silently returned a NaN (not a zero) without
> setting errno if it was *self*-consistent -- anyone care to check that
> under -lieee?:

>     import math
>     math.sqrt(-1)

>>> import math
>>> math.sqrt(-1)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
OverflowError: math range error

The same under both 1.5.2 and 2.0c1 with -lieee. Without -lieee, both do:

>>> import math
>>> math.sqrt(-1)
Traceback (innermost last):
  File "<stdin>", line 1, in ?
ValueError: math domain error

Consistency-conschmistency-ly y'rs,

-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!



From jeremy at beopen.com  Thu Oct 12 17:58:10 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Thu, 12 Oct 2000 11:58:10 -0400 (EDT)
Subject: [Python-Dev] (no subject)
Message-ID: <14821.57234.444047.511672@bitdiddle.concentric.net>

Cc xml-sig at python.org
Subject: test_minidom non-failure failure?
X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid
Reply-To: jeremy at beopen.com
Comments: Hyperbole mail buttons accepted, v04.18.

SSBqdXN0IHJhbiAnbWFrZSB0ZXN0JyBhZ2FpbnN0IGEgY2xlYW4gY29weSBvZiB0aGUgQ1ZT
IHRyZWUgYW5kIGdvdCBhbg0KZW5vcm1vdXMgYW1vdW50IG9mIGdhcmJhZ2Ugb3V0cHV0IGZy
b20gdGVzdF9taW5pZG9tLCBhbHRob3VnaCBpdCB3YXMNCm5vdCByZXBvcnRlZCBhcyBhIHRl
c3QgdGhlIGZhaWxlZCBvciB3YXMgc2tpcHBlZC4NCg0KVGhlIG91dHB1dCBmcm9tIHRlc3Rf
bWluaWRvbSBzdGFydGVkIHRoaXMgd2F5Og0KDQp0ZXN0X21pbmlkb20NCmdhcmJhZ2U6IFt7
J25vZGVWYWx1ZSc6IHUnT2Jzb2xldGUgYnV0IGltcGxlbWVudGVkLi4uJywgJ25leHRTaWJs
aW5nJzogPERPTSBUZXh0IG5vZGUgIlwwMTIiPiwgJ2NoaWxkTm9kZXMnOiBOb25lLCAnYXR0
cmlidXRlcyc6IE5vbmUsICdwYXJlbnROb2RlJzogTm9uZSwgJ2RhdGEnOiB1J09ic29sZXRl
IGJ1dCBpbXBsZW1lbnRlZC4uLicsICdwcmV2aW91c1NpYmxpbmcnOiBOb25lfSwgPERPTSBU
ZXh0IG5vZGUgIk9ic29sZXRlIGIuLi4iPiwgeydub2RlVmFsdWUnOiB1J1wwMTInLCAnbmV4
dFNpYmxpbmcnOiBOb25lLCAnY2hpbGROb2Rlcyc6IE5vbmUsICdhdHRyaWJ1dGVzJzogTm9u
ZSwgJ3BhcmVudE5vZGUnOiBOb25lLCAnZGF0YSc6IHUnXDAxMicsICdwcmV2aW91c1NpYmxp
bmcnOiA8RE9NIFRleHQgbm9kZSAiT2Jzb2xldGUgYi4uLiI+fSwgPERPTSBUZXh0IG5vZGUg
IlwwMTIiPiwgeydub2RlVmFsdWUnOiB1J09ic29sZXRlIGJ1dCBpbXBsZW1lbnRlZC4uLics
ICduZXh0U2libGluZyc6IDxET00gVGV4dCBub2RlICJcMDEyIj4sICdjaGlsZE5vZGVzJzog
Tm9uZSwgJ2F0dHJpYnV0ZXMnOiBOb25lLCAncGFyZW50Tm9kZSc6IE5vbmUsICdkYXRhJzog
dSdPYnNvbGV0ZSBidXQgaW1wbGVtZW50ZWQuLi4nLCAncHJldmlvdXNTaWJsaW5nJzogTm9u
ZX0sIDxET00gVGV4dCBub2RlICJPYnNvbGV0ZSBiLi4uIj4sIHsnbm9kZVZhbHVlJzogdSdc
MDEyJywgJ25leHRTaWJsaW5nJzogTm9uZSwgJ2NoaWxkTm9kZXMnOiBOb25lLCAnYXR0cmli
dXRlcyc6IE5vbmUsICdwYXJlbnROb2RlJzogTm9uZSwgJ2RhdGEnOiB1J1wwMTInLCAncHJl
dmlvdXNTaWJsaW5nJzogPERPTSBUZXh0IG5vZGUgIk9ic29sZXRlIGIuLi4iPn0sIDxET00g
VGV4dCBub2RlICJcMDEyIj4sIHsnbm9kZVZhbHVlJzogdSdPYnNvbGV0ZSBidXQgaW1wbGVt
ZW50ZWQuLi4nLCAnbmV4dFNpYmxpbmcnOiA8RE9NIFRleHQgbm9kZSAiXDAxMiI+LCAnY2hp
bGROb2Rlcyc6IE5vbmUsICdhdHRyaWJ1dGVzJzogTm9uZSwgJ3BhcmVudE5vZGUnOiBOb25l
LCAnZGF0YSc6IHUnT2Jzb2xldGUgYnV0IGltcGxlbWVudGVkLi4uJywgJ3ByZXZpb3VzU2li
bGluZyc6IE5vbmV9LCA8RE9NIFRleHQgbm9kZSAiT2Jzb2xldGUgYi4uLiI+LCB7J25vZGVW
YWx1ZSc6IHUnXDAxMicsICduZXh0U2libGluZyc6IE5vbmUsICdjaGlsZE5vZGVzJzogTm9u
ZSwgJ2F0dHJpYnV0ZXMnOiBOb25lLCAncGFyZW50Tm9kZSc6IE5vbmUsICdkYXRhJzogdSdc
MDEyJywgJ3ByZXZpb3VzU2libGluZyc6IDxET00gVGV4dCBub2RlICJPYnNvbGV0ZSBiLi4u
Ij59LCA8RE9NIFRleHQgbm9kZSAiXDAxMiI+LCB7J25vZGVWYWx1ZSc6ICd0ZXh0JywgJ25l
eHRTaWJsaW5nJzogPERPTSBFbGVtZW50OiBzdWJlbG0gYXQgMTM3ODYzMzg4PiwgJ2NoaWxk
Tm9kZXMnOiBOb25lLCAnYXR0cmlidXRlcyc6IE5vbmUsICdwYXJlbnROb2RlJzogTm9uZSwg
J2RhdGEnOiAndGV4dCcsICdwcmV2aW91c1NpYmxpbmcnOiBOb25lfSwgPERPTSBUZXh0IG5v
ZGUgInRleHQiPiwgeydfYXR0cnMnOiB7fSwgJ3ByZXZpb3VzU2libGluZyc6IDxET00gVGV4
dCBub2RlICJ0ZXh0Ij4sICdjaGlsZE5vZGVzJzogTm9uZSwgJ2xvY2FsTmFtZSc6ICdzdWJl
bG0nLCAndGFnTmFtZSc6ICdzdWJlbG0nLCAnX2F0dHJzTlMnOiB7fSwgJ3ByZWZpeCc6ICcn
LCAnbmFtZXNwYWNlVVJJJzogJycsICdub2RlVmFsdWUnOiBOb25lLCAnbmV4dFNpYmxpbmcn
OiA8RE9NIFRleHQgbm9kZSAidGV4dCI+LCAncGFyZW50Tm9kZSc6IE5vbmUsICdub2RlTmFt
ZSc6ICdzdWJlbG0nfSwgPERPTSBFbGVtZW50OiBzdWJlbG0gYXQgMTM3ODYzMzg4Piwge30s
IHt9LCB7J25vZGVWYWx1ZSc6ICd0ZXh0JywgJ25leHRTaWJsaW5nJzogTm9uZSwgJ2NoaWxk
Tm9kZXMnOiBOb25lLCAnYXR0cmlidXRlcyc6IE5vbmUsICdwYXJlbnROb2RlJzogTm9uZSwg
J2RhdGEnOiAndGV4dCcsICdwcmV2aW91c1NpYmxpbmcnOiA8RE9NIEVsZW1lbnQ6IHN1YmVs
bSBhdCAxMzc4NjMzODg+fSwgPERPTSBUZXh0IG5vZGUgInRleHQiPiwgeydub2RlVmFsdWUn
OiB1J09ic29sZXRlIGJ1dCANCg0KSXQgY29udGludWVkIG9uIGluIHRoZSBzYW1lIGZhc2hp
b24gZm9yIGFib3V0IGEgdGhvdXNhbmQgbGluZXMuICBBZnRlcg0KcHJpbnRpbmcgYWxsIHRo
aXMgZ2FyYmFnZSwgaXQgY29udGludWVkIG9uIHRvIHRlc3RfbW1hcC4NCg0KVGhlIGZpbmFs
IHRlc3QgcmVwb3J0IHdhczoNCg0KOTUgdGVzdHMgT0suDQoxMyB0ZXN0cyBza2lwcGVkOiB0
ZXN0X2FsIHRlc3RfY2QgdGVzdF9jbCB0ZXN0X2RibSB0ZXN0X2RsIHRlc3RfZ2wNCnRlc3Rf
aW1nZmlsZSB0ZXN0X2xhcmdlZmlsZSB0ZXN0X25pcyB0ZXN0X3N1bmF1ZGlvZGV2IHRlc3Rf
dGltaW5nDQp0ZXN0X3dpbnJlZyB0ZXN0X3dpbnNvdW5kDQoNCkFueSBpZGVhcyBhYm91dCB3
aGF0IHdlbnQgd3Jvbmc/DQoNCkplcmVteQ==



From jeremy at beopen.com  Thu Oct 12 18:11:53 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Thu, 12 Oct 2000 12:11:53 -0400 (EDT)
Subject: [Python-Dev] test_minidom non-failure failure? (take 2)
Message-ID: <14821.58057.358947.271778@bitdiddle.concentric.net>

Sorry about the previous message; a mail munger somewhere between my
display and python.org choked on a very long line...

I am getting an occasional, hard-to-reproduce error in test_minidom.
When I run the test, it displays about a thousand lines of garbage,
but the test suite does not report test_minidom as failed or skipped.

The output I see during the test run is this:

test_minidom
garbage: [{'nodeValue': u'Obsolete but implemented...', 'nextSibling':
<DOM Text node "\012">, 'childNodes': None, 'attributes': None,
'parentNode': None, 'data': u'Obsolete but implemented...',
'previousSibling': None}, <DOM Text node "Obsolete b...">,
{'nodeValue': u'\012', 'nextSibling': None, 'childNodes': None, 'a 
[... many hundreds of lines omitted]

At the end of the test, I get a pretty normal result:
95 tests OK.
13 tests skipped: test_al test_cd test_cl test_dbm test_dl test_gl
test_imgfile test_largefile test_nis test_sunaudiodev test_timing
test_winreg test_winsound 

So two questions:

Why is test_minidom producing all this output?  And why is it only
happening intermittently?

Why does regrtest.py think that test_minidom is working correctly when
it produces all this output?

Jeremy




From nas at arctrix.com  Thu Oct 12 11:31:34 2000
From: nas at arctrix.com (Neil Schemenauer)
Date: Thu, 12 Oct 2000 02:31:34 -0700
Subject: [Python-Dev] test_minidom non-failure failure? (take 2)
In-Reply-To: <14821.58057.358947.271778@bitdiddle.concentric.net>; from jeremy@beopen.com on Thu, Oct 12, 2000 at 12:11:53PM -0400
References: <14821.58057.358947.271778@bitdiddle.concentric.net>
Message-ID: <20001012023134.A18254@glacier.fnational.com>

On Thu, Oct 12, 2000 at 12:11:53PM -0400, Jeremy Hylton wrote:
> I am getting an occasional, hard-to-reproduce error in test_minidom.
> When I run the test, it displays about a thousand lines of garbage,
> but the test suite does not report test_minidom as failed or skipped.
> 
> The output I see during the test run is this:
> 
> test_minidom
> garbage: [{'nodeValue': u'Obsolete but implemented...', 'nextSibling':

This is most likely the garbage collector.  regrtest.py contains
the following code:

        if findleaks:
            gc.collect()
            if gc.garbage:
                print "garbage:", repr(gc.garbage)
                found_garbage.extend(gc.garbage)
                del gc.garbage[:]

findleaks is true if the -l option is specified (TESTOPS in the
makefile includes it).  Something is producing cyclic garbage.

  Neil



From guido at python.org  Thu Oct 12 19:39:40 2000
From: guido at python.org (Guido van Rossum)
Date: Thu, 12 Oct 2000 12:39:40 -0500
Subject: [Python-Dev] test_minidom non-failure failure? (take 2)
In-Reply-To: Your message of "Thu, 12 Oct 2000 02:31:34 MST."
             <20001012023134.A18254@glacier.fnational.com> 
References: <14821.58057.358947.271778@bitdiddle.concentric.net>  
            <20001012023134.A18254@glacier.fnational.com> 
Message-ID: <200010121739.MAA07968@cj20424-a.reston1.va.home.com>

> On Thu, Oct 12, 2000 at 12:11:53PM -0400, Jeremy Hylton wrote:
> > I am getting an occasional, hard-to-reproduce error in test_minidom.
> > When I run the test, it displays about a thousand lines of garbage,
> > but the test suite does not report test_minidom as failed or skipped.
> > 
> > The output I see during the test run is this:
> > 
> > test_minidom
> > garbage: [{'nodeValue': u'Obsolete but implemented...', 'nextSibling':

[Neil]
> This is most likely the garbage collector.  regrtest.py contains
> the following code:
> 
>         if findleaks:
>             gc.collect()
>             if gc.garbage:
>                 print "garbage:", repr(gc.garbage)
>                 found_garbage.extend(gc.garbage)
>                 del gc.garbage[:]
> 
> findleaks is true if the -l option is specified (TESTOPS in the
> makefile includes it).  Something is producing cyclic garbage.

Of course something is producing cyclic garbage!

The DOM tree is full of parent and child links.

Does this output mean that the GC works correctly?  Or does it mean
that there is a reason why this garbage cannot be disposed of?

In the latter case, could that be because there are __del__ methods?

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



From fdrake at beopen.com  Thu Oct 12 18:55:19 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Thu, 12 Oct 2000 12:55:19 -0400 (EDT)
Subject: [Python-Dev] test_minidom non-failure failure? (take 2)
In-Reply-To: <20001012023134.A18254@glacier.fnational.com>
References: <14821.58057.358947.271778@bitdiddle.concentric.net>
	<20001012023134.A18254@glacier.fnational.com>
Message-ID: <14821.60663.213246.179325@cj42289-a.reston1.va.home.com>

Neil Schemenauer writes:
 > This is most likely the garbage collector.  regrtest.py contains
 > the following code:
...
 > findleaks is true if the -l option is specified (TESTOPS in the
 > makefile includes it).  Something is producing cyclic garbage.

  This is definately the problem.
  Lars, Paul:  This looks like a problem in the unlink() method of the
DOM.  Could you please check that the unlink() method is updated to
handle the latest version of the other changes?
  Thanks!


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From fdrake at beopen.com  Thu Oct 12 18:59:33 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Thu, 12 Oct 2000 12:59:33 -0400 (EDT)
Subject: [Python-Dev] test_minidom non-failure failure? (take 2)
In-Reply-To: <14821.58057.358947.271778@bitdiddle.concentric.net>
References: <14821.58057.358947.271778@bitdiddle.concentric.net>
Message-ID: <14821.60917.429141.652655@cj42289-a.reston1.va.home.com>

Jeremy Hylton writes:
 > Why is test_minidom producing all this output?  And why is it only
 > happening intermittently?

  It isn't.  See Neil's excellent explanation.

 > Why does regrtest.py think that test_minidom is working correctly when
 > it produces all this output?

  The test is passing just fine, and is complete before the test for
garbage is performed.  The unlink() method on DOM objects is the
culprit; it is updating the Node.allnodes dictionary correctly, but
not the Node instances.  I've already asked Paul & Lars to fix this;
it should work just fine with or without GC once they've seen the
report.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From nas at arctrix.com  Thu Oct 12 12:24:48 2000
From: nas at arctrix.com (Neil Schemenauer)
Date: Thu, 12 Oct 2000 03:24:48 -0700
Subject: [Python-Dev] test_minidom non-failure failure? (take 2)
In-Reply-To: <200010121739.MAA07968@cj20424-a.reston1.va.home.com>; from guido@python.org on Thu, Oct 12, 2000 at 12:39:40PM -0500
References: <14821.58057.358947.271778@bitdiddle.concentric.net> <20001012023134.A18254@glacier.fnational.com> <200010121739.MAA07968@cj20424-a.reston1.va.home.com>
Message-ID: <20001012032448.A18407@glacier.fnational.com>

On Thu, Oct 12, 2000 at 12:39:40PM -0500, Guido van Rossum wrote:
> Of course something is producing cyclic garbage!
> 
> The DOM tree is full of parent and child links.
> 
> Does this output mean that the GC works correctly?  Or does it
> mean that there is a reason why this garbage cannot be disposed
> of?  In the latter case, could that be because there are
> __del__ methods?

The -l option tries to find any cyclic garbage produced by the
tests.  I don't think that that option should be enabled default.
The output means that the GC is working and is finding stuff that
would not be freed by reference counting alone.  

I can't tell if the GC would free this garbage.  The -l option
sets the DEBUG_SAVEALL option which causes all garbage found to
end up in gc.garbage, not just garbage the can't be cleaned up.

I don't have pyexpat installed here so I can't test it.  If you
want to find out if test_minidom is creating garbage the
collector can't free you should comment out the:

    gc.set_debug(gc.DEBUG_SAVEALL)

line in regrtest.py and run:

    regrtest.py -l test_minidom

If that does what I think it does and you still get the "garbage: "
line then the test is creating evil things.  :)

  Neil



From hinsen at dirac.cnrs-orleans.fr  Thu Oct 12 19:24:18 2000
From: hinsen at dirac.cnrs-orleans.fr (hinsen at dirac.cnrs-orleans.fr)
Date: Thu, 12 Oct 2000 19:24:18 +0200
Subject: [Python-Dev] RE: [Numpy-discussion] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison)
In-Reply-To: <Pine.A32.3.90.1001011225636.4671B-100000@elvis.med.Virginia.EDU>
	(sdm7g@virginia.edu)
References: <Pine.A32.3.90.1001011225636.4671B-100000@elvis.med.Virginia.EDU>
Message-ID: <200010121724.TAA15487@chinon.cnrs-orleans.fr>

>  The idea that your calculation should blow up and you should 
> check it and resubmit your job sounds just so ancient-20th-century-
> Fortran-JCL-and-punched-cards-technology! 

Long-running jobs are still with us, even there's neither Fortran nor
JCL in them. And for these applications, stopping is better than going
on with nonsense values. On the other hand, as you point out, exceptions
for math errors are a bit of a pain for interactive work.

So how about making this a run-time option? I'd choose exceptions by
default and Infs and Nans by specifying a command-line option, but
there are certainly others who would prefer it the other way round.
What matters most to me is that the choice is possible somehow.

Konrad.
-- 
-------------------------------------------------------------------------------
Konrad Hinsen                            | E-Mail: hinsen at cnrs-orleans.fr
Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24
Rue Charles Sadron                       | Fax:  +33-2.38.63.15.17
45071 Orleans Cedex 2                    | Deutsch/Esperanto/English/
France                                   | Nederlands/Francais
-------------------------------------------------------------------------------



From sdm7g at virginia.edu  Thu Oct 12 20:25:44 2000
From: sdm7g at virginia.edu (Steven D. Majewski)
Date: Thu, 12 Oct 2000 14:25:44 -0400 (EDT)
Subject: [Python-Dev] RE: [Numpy-discussion] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison)
In-Reply-To: <200010121724.TAA15487@chinon.cnrs-orleans.fr>
Message-ID: <Pine.A32.3.90.1001012140201.14856A-100000@elvis.med.Virginia.EDU>


On Thu, 12 Oct 2000 hinsen at dirac.cnrs-orleans.fr wrote:

> >  The idea that your calculation should blow up and you should 
> > check it and resubmit your job sounds just so ancient-20th-century-
> > Fortran-JCL-and-punched-cards-technology! 
> 
> Long-running jobs are still with us, even there's neither Fortran nor
> JCL in them. And for these applications, stopping is better than going
> on with nonsense values. On the other hand, as you point out, exceptions
> for math errors are a bit of a pain for interactive work.
> 
> So how about making this a run-time option? I'd choose exceptions by
> default and Infs and Nans by specifying a command-line option, but
> there are certainly others who would prefer it the other way round.
> What matters most to me is that the choice is possible somehow.
> 

I agree entirely! 
Maybe I was being a bit too glib, but I didn't mean to imply that
wanting it to halt or throw an exception on errors is wrongheaded.

I just wanted to make sure the counter-case to what Paul was saying
also got heard: Yes-- underflows  or infinities  where they aren't 
expected are usually a sign that something is very wrong somewhere.
But in the case where the vector holds independent observations or
data points, then usually what it means is that there's something
wrong with *that* data point -- miscallibrated or mislabeled -- but
no reason not to complete the calculations for all of the other
points. 

Scaling or doing projections for interactive graphics is another
case where bad points are often better than throwing an exception.
( And it's a pain to have to remember to lambda wrap all the function
calls with some sort of guard when you'ld be happy to get NaNs. ) 

I also mostly agree with Tim, except that I'm not sure that bad or
incomplete ieee support is always better than none at all.

---|  Steven D. Majewski   (804-982-0831)  <sdm7g at Virginia.EDU>  |---
---|  Department of Molecular Physiology and Biological Physics  |---
---|  University of Virginia             Health Sciences Center  |---
---|  P.O. Box 10011            Charlottesville, VA  22906-0011  |---
		"All operating systems want to be unix, 
		 All programming languages want to be lisp." 




From thomas at xs4all.net  Thu Oct 12 21:14:37 2000
From: thomas at xs4all.net (Thomas Wouters)
Date: Thu, 12 Oct 2000 21:14:37 +0200
Subject: [Python-Dev] Re: getopt() prototype [was: checkin-message of something or other]
In-Reply-To: <200010121711.KAA00584@slayer.i.sourceforge.net>; from fdrake@users.sourceforge.net on Thu, Oct 12, 2000 at 10:11:41AM -0700
References: <200010121711.KAA00584@slayer.i.sourceforge.net>
Message-ID: <20001012211436.Z12812@xs4all.nl>

On Thu, Oct 12, 2000 at 10:11:41AM -0700, Fred L. Drake wrote:

[ use -Wall and -Wstrict-prototypes by default, if the compiler is gcc ]

> There is one known warning at this time, caught by the -Wstrict-prototypes
> option.  In Modules/main.c, the declaration of getopt() without parameters
> gets a complaint (rightly) that it is not a proper prototype.  The lack of
> a complete prototype information should be corrected when the right
> portability conditions have been identified.

I already looked at this before, and the problem is that the prototype for
getopt is not portable (because of quirks in the ANSI C standard regarding
'compatible' pointer types.) Some systems define it as 'const char **' (or
'char const **'), some perhaps as 'char **', and some as 'char * const *'.
'const char **' and 'char const **' are the same, but 'char * const *' is
something else, and so is 'char **'. 'char * const *' and 'char **' are
equivalent types, meaning that conforming compilers should be able to
intermix them without problems, but 'const char **' is a different type, and
ANSI C either demands or strongly suggests a warning.

(Why exactly it's a different type is mostly a choice of language, though
I'm sure there are people who would defend the choice. What it means it that
you can't mix two layers of indirection with qualifiers like 'const' or
'volatile', without paying close attention to assignment and prototypes :P)

As a result, no matter what prototype we think up, we're always screwing
either the one type of platform or the other. And not with a warning; the
conflicting prototype would generate an error, nto a warning. The only
solution I can think of is adding the proper prototype to the pyport.h
header file, inside a proper #ifdef. For generated code it doesn't really
matter which of the prototypes is used, but if the system headers do
provide a prototype, and it doesn't match in indirect-constness, compilation
will fail. 

(In other words, even on the platforms that are missing it, close attention
should be paid to the manual pages, trying to guess what the prototype is
going to look like if that particular system would ever grow a prototype in
a system header. From what I read in the getopt(3) manpage on my linux box
the prototype mixup comes from a POSIX.2 flaw, but I'm not sure.)

Does anyone have a system where the prototype to getopt() is not defined in
header files ? My Solaris 2.x testbox has that problem, but the box in
question is one huge mess, and I doubt it has anything to do with Solaris in
particular. I only use it to reproduce reported bugs, not report any myself
;P

-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!



From jeremy at beopen.com  Thu Oct 12 22:10:50 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Thu, 12 Oct 2000 16:10:50 -0400 (EDT)
Subject: [Python-Dev] test_minidom non-failure failure? (take 2)
In-Reply-To: <20001012032448.A18407@glacier.fnational.com>
References: <14821.58057.358947.271778@bitdiddle.concentric.net>
	<20001012023134.A18254@glacier.fnational.com>
	<200010121739.MAA07968@cj20424-a.reston1.va.home.com>
	<20001012032448.A18407@glacier.fnational.com>
Message-ID: <14822.6858.920988.167252@bitdiddle.concentric.net>

>>>>> "NS" == Neil Schemenauer <nas at arctrix.com> writes:

  NS> The -l option tries to find any cyclic garbage produced by the
  NS> tests.  I don't think that that option should be enabled
  NS> default.  The output means that the GC is working and is finding
  NS> stuff that would not be freed by reference counting alone.

  NS> I can't tell if the GC would free this garbage.  The -l option
  NS> sets the DEBUG_SAVEALL option which causes all garbage found to
  NS> end up in gc.garbage, not just garbage the can't be cleaned up.

  NS> I don't have pyexpat installed here so I can't test it.  If you
  NS> want to find out if test_minidom is creating garbage the
  NS> collector can't free you should comment out the:

  NS>     gc.set_debug(gc.DEBUG_SAVEALL)

  NS> line in regrtest.py and run:

  NS>     regrtest.py -l test_minidom

  NS> If that does what I think it does and you still get the
  NS> "garbage: " line then the test is creating evil things.  :)

The test is not creating evil things.  I commented out the
DEBUG_SAVEALL line and got no error report.

The question, then, is what to do about the -l option.  I assume we
should remove the -l option from the Makefile, so that "make test"
doesn't turn on DEBUG_SAVEALL.  Or do we need to change regrtest in
some way so that it still reports on tests that create evil things?

Jeremy



From nas at arctrix.com  Thu Oct 12 15:20:10 2000
From: nas at arctrix.com (Neil Schemenauer)
Date: Thu, 12 Oct 2000 06:20:10 -0700
Subject: [Python-Dev] test_minidom non-failure failure? (take 2)
In-Reply-To: <14822.6858.920988.167252@bitdiddle.concentric.net>; from jeremy@beopen.com on Thu, Oct 12, 2000 at 04:10:50PM -0400
References: <14821.58057.358947.271778@bitdiddle.concentric.net> <20001012023134.A18254@glacier.fnational.com> <200010121739.MAA07968@cj20424-a.reston1.va.home.com> <20001012032448.A18407@glacier.fnational.com> <14822.6858.920988.167252@bitdiddle.concentric.net>
Message-ID: <20001012062010.A19026@glacier.fnational.com>

On Thu, Oct 12, 2000 at 04:10:50PM -0400, Jeremy Hylton wrote:
> The question, then, is what to do about the -l option.  I assume we
> should remove the -l option from the Makefile, so that "make test"
> doesn't turn on DEBUG_SAVEALL.  Or do we need to change regrtest in
> some way so that it still reports on tests that create evil things?

This is a policy decision.  Is it okay for the test suite to
create garbage that is not collectable by reference counting?  If
yes, what about garbage that is not collectable by the (current)
GC?  

  Neil



From guido at python.org  Thu Oct 12 23:21:39 2000
From: guido at python.org (Guido van Rossum)
Date: Thu, 12 Oct 2000 16:21:39 -0500
Subject: [Python-Dev] test_minidom non-failure failure? (take 2)
In-Reply-To: Your message of "Thu, 12 Oct 2000 16:10:50 -0400."
             <14822.6858.920988.167252@bitdiddle.concentric.net> 
References: <14821.58057.358947.271778@bitdiddle.concentric.net> <20001012023134.A18254@glacier.fnational.com> <200010121739.MAA07968@cj20424-a.reston1.va.home.com> <20001012032448.A18407@glacier.fnational.com>  
            <14822.6858.920988.167252@bitdiddle.concentric.net> 
Message-ID: <200010122121.QAA09024@cj20424-a.reston1.va.home.com>

> The question, then, is what to do about the -l option.  I assume we
> should remove the -l option from the Makefile, so that "make test"
> doesn't turn on DEBUG_SAVEALL.

This seems to make sense, yes.  Since the "leaked" objects that are
found will be released by the GC code, I see no point in reporting
these during the regression test.  This can only confuse people (like
it did Jeremy :-).

> Or do we need to change regrtest in
> some way so that it still reports on tests that create evil things?

Any form of evilness that can be detected without *too* much effort is
worth it...  I have no idea what kind of evil we're looking for here
or how to detect is, so I can't answer yes or no.

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



From fdrake at beopen.com  Thu Oct 12 22:18:15 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Thu, 12 Oct 2000 16:18:15 -0400 (EDT)
Subject: [Python-Dev] New development documentation up...
Message-ID: <14822.7303.953870.727070@cj42289-a.reston1.va.home.com>

  I don't normally post when I've updated the development copy of the
documentation, but there are a couple of big additions there now.
  Martin von L?wis contributed substantial SAX2 documentation, which
I've now integrated.  Thanks, Martin!
  Chris Barker is working on new documentation for the Macintosh
manual; I've only just started to look at it, but there's definately a
*lot* of new material.  That's not checked into CVS yet, but will be
once I've had more time to go over it.  Thanks, Chris!

	ftp://python.beopen.com/pub/docco/devel/index.html


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From nas at arctrix.com  Thu Oct 12 15:28:04 2000
From: nas at arctrix.com (Neil Schemenauer)
Date: Thu, 12 Oct 2000 06:28:04 -0700
Subject: [Python-Dev] test_minidom non-failure failure? (take 2)
In-Reply-To: <200010122121.QAA09024@cj20424-a.reston1.va.home.com>; from guido@python.org on Thu, Oct 12, 2000 at 04:21:39PM -0500
References: <14821.58057.358947.271778@bitdiddle.concentric.net> <20001012023134.A18254@glacier.fnational.com> <200010121739.MAA07968@cj20424-a.reston1.va.home.com> <20001012032448.A18407@glacier.fnational.com> <14822.6858.920988.167252@bitdiddle.concentric.net> <200010122121.QAA09024@cj20424-a.reston1.va.home.com>
Message-ID: <20001012062804.B19026@glacier.fnational.com>

On Thu, Oct 12, 2000 at 04:21:39PM -0500, Guido van Rossum wrote:
> Any form of evilness that can be detected without *too* much effort is
> worth it...  I have no idea what kind of evil we're looking for here
> or how to detect is, so I can't answer yes or no.

That would be reference cycles with finalizers (ie. instances
with __del__ methods).  The current garbage collector does not
free such structures but instead appends them to gc.garbage.
Sorry for not being clear.

In any case, regrtest should probably print a more clueful
message when objects are found in gc.garbage.  That would go a
long way in clearing up the confusion.  I'll see about a patch.

  Neil



From guido at python.org  Thu Oct 12 23:26:49 2000
From: guido at python.org (Guido van Rossum)
Date: Thu, 12 Oct 2000 16:26:49 -0500
Subject: [Python-Dev] test_minidom non-failure failure? (take 2)
In-Reply-To: Your message of "Thu, 12 Oct 2000 06:20:10 MST."
             <20001012062010.A19026@glacier.fnational.com> 
References: <14821.58057.358947.271778@bitdiddle.concentric.net> <20001012023134.A18254@glacier.fnational.com> <200010121739.MAA07968@cj20424-a.reston1.va.home.com> <20001012032448.A18407@glacier.fnational.com> <14822.6858.920988.167252@bitdiddle.concentric.net>  
            <20001012062010.A19026@glacier.fnational.com> 
Message-ID: <200010122126.QAA09072@cj20424-a.reston1.va.home.com>

> This is a policy decision.  Is it okay for the test suite to
> create garbage that is not collectable by reference counting?

I don't see why that should be forbidden.  After all some of the code
we test has such leaks -- we haven't declared those absolute bugs.

> If yes, what about garbage that is not collectable by the (current)
> GC?

Can you give an example of how such garbage can be created?

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



From jeremy at beopen.com  Thu Oct 12 22:38:29 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Thu, 12 Oct 2000 16:38:29 -0400 (EDT)
Subject: [Python-Dev] test_minidom non-failure failure? (take 2)
In-Reply-To: <20001012062804.B19026@glacier.fnational.com>
References: <14821.58057.358947.271778@bitdiddle.concentric.net>
	<20001012023134.A18254@glacier.fnational.com>
	<200010121739.MAA07968@cj20424-a.reston1.va.home.com>
	<20001012032448.A18407@glacier.fnational.com>
	<14822.6858.920988.167252@bitdiddle.concentric.net>
	<200010122121.QAA09024@cj20424-a.reston1.va.home.com>
	<20001012062804.B19026@glacier.fnational.com>
Message-ID: <14822.8517.675600.578272@bitdiddle.concentric.net>

>>>>> "NS" == Neil Schemenauer <nas at arctrix.com> writes:

  NS> In any case, regrtest should probably print a more clueful
  NS> message when objects are found in gc.garbage.  That would go a
  NS> long way in clearing up the confusion.  I'll see about a patch.

I think there is some value to issueing reports when a test creates
trash that can't be cleaned up by the GC, but it doesn't make sense to
report this by default.  If "make test" reports an error, it should
mean that something has gone wrong with the user's build and the
interpreter is broken.  That's not the case here.  The build was fine;
it's just the test that is iffy.

I think we should turn of the -l option by default *and* patch it so
that the output is more useful.  I would suggest printing a count of
the objects, perhaps organized by type/class name.  Something like
this: 

    Test created 6 uncollectable objects
    4 foo.Bar instances
    2 foo.Baz instances

Jeremy



From tim_one at email.msn.com  Thu Oct 12 22:33:41 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Thu, 12 Oct 2000 16:33:41 -0400
Subject: [Python-Dev] RE: [Numpy-discussion] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison)
In-Reply-To: <Pine.A32.3.90.1001012140201.14856A-100000@elvis.med.Virginia.EDU>
Message-ID: <LNBBLJKPBEHFEDALKOLCEEACHLAA.tim_one@email.msn.com>

[Steven D. Majewski]
> ...
> I also mostly agree with Tim, except that I'm not sure that bad or
> incomplete ieee support is always better than none at all.

This is true, because having Python is better than not having Python, and in
having Python you indeed have bad *and* incomplete 754 support on every 754
platform it runs on.  Even better, it's a subset of damaged 754 support
unique to each platform whose details can't be guessed or documented in
advance of trying it exhaustively to see what happens(*), and a subset that
can change delightfully across releases, compiler upgrades, library upgrades
and seemingly irrelevant minor config changes.  So if bad or incomplete IEEE
support is good, Python is-- here as elsewhere --the King of Languages
<wink>.

Every step of this dance is thoroughly predictable.  In this case, I'm doing
my darnedest to nudge Python its very first step towards *real* 754 support,
and getting dumped on for it by a 754 fan.  Simultaneously, the "old guard"
defends their lifestyle against new-fangled ideas <wink>, asking for
protections unaware that 754 *requires* they get a better form of the
protections they seek than they've dreamed of so far.  It appears that
nobody on either side has actually read the std, and I've become the very
754 Storm Trooper I used to despise.  Computer life is great <wink>.

all-it's-missing-is-variety-ly y'rs  - tim


(*) Quiz:  *if* you can manage to trick Python into creating a NaN on your
particular 754 platform, does the Python expression NaN == 1.0 return true,
false, or raise an exception?  Answer before you try it.  Then try it on
enough 754 platforms until you give up trying to guess in advance.  NaN ==
NaN is predictable in Python, and is the one 754 feature Python guarantees
won't work correctly on any 754 platform (although I've heard that it loses
this predictability when run using NumPy's flavor of comparisons instead of
core Python's).





From nas at arctrix.com  Thu Oct 12 15:43:09 2000
From: nas at arctrix.com (Neil Schemenauer)
Date: Thu, 12 Oct 2000 06:43:09 -0700
Subject: [Python-Dev] test_minidom non-failure failure? (take 2)
In-Reply-To: <200010122126.QAA09072@cj20424-a.reston1.va.home.com>; from guido@python.org on Thu, Oct 12, 2000 at 04:26:49PM -0500
References: <14821.58057.358947.271778@bitdiddle.concentric.net> <20001012023134.A18254@glacier.fnational.com> <200010121739.MAA07968@cj20424-a.reston1.va.home.com> <20001012032448.A18407@glacier.fnational.com> <14822.6858.920988.167252@bitdiddle.concentric.net> <20001012062010.A19026@glacier.fnational.com> <200010122126.QAA09072@cj20424-a.reston1.va.home.com>
Message-ID: <20001012064309.C19026@glacier.fnational.com>

On Thu, Oct 12, 2000 at 04:26:49PM -0500, Guido van Rossum wrote:
> > This is a policy decision.  Is it okay for the test suite to
> > create garbage that is not collectable by reference counting?
> 
> I don't see why that should be forbidden.  After all some of the code
> we test has such leaks -- we haven't declared those absolute bugs.

Again, "-l" should probably not be a default.  I don't know who
added it to TESTOPTS but it wasn't me.

> Can you give an example of how such garbage can be created?

Look at test_gc.  Here is an example:

    class Foo:
        def __del__(self):
            pass
    foo = Foo()
    foo.foo = foo
    del foo

Theoretically this structure could be collected without problem
but the GC is too simple minded to realize that there is only one
finalizer involved.  Here's a better example:

    foo = Foo()
    bar = Foo()
    foo.bar = bar
    bar.foo = foo
    del foo, bar

The GC cannot safely break this cycle so it punts and adds the
instance objects involved to gc.garbage and forgets about it.

  Neil



From tim_one at email.msn.com  Thu Oct 12 23:38:13 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Thu, 12 Oct 2000 17:38:13 -0400
Subject: [Python-Dev] Re: getopt() prototype [was: checkin-message of something or other]
In-Reply-To: <20001012211436.Z12812@xs4all.nl>
Message-ID: <LNBBLJKPBEHFEDALKOLCIEAGHLAA.tim_one@email.msn.com>

[Thomas Wouters, on getopt]
> ...
> From what I read in the getopt(3) manpage on my linux box the
> prototype mixup comes from a POSIX.2 flaw, but I'm not sure.)

I bet it's actually talking about Interpretation 150 to POSIX.2, here (while
you can't read the std online, you can read the complaints online!):

http://standards.ieee.org/reading/ieee/interp/1003-2-92_int/pasc-1003.2-150.
html

Doesn't have anything to do with the prototype, alas.

> Does anyone have a system where the prototype to getopt() is not
> defined in header files ? My Solaris 2.x testbox has that problem, but
> the box in question is one huge mess, and I doubt it has anything to do
> with Solaris in particular. ...

Sure:  Windows doesn't have a getopt; getopt isn't std C (not even in C99).
Assorted derived stds demand that a getopt protoptype appear in stdlib.h,
and others that it appear in unistd.h.

I have a different suggestion:  screw it.  getopt keeps creating problems on
GNUish systems too, because without the POSIXLY_CORRECT envar set, the GNU
getopt shuffles all the "option strings" to the front, making a mess of,
e.g.,

python myprog.py -v

The Python source tree already has its own getopt implementation
(Python/getopt.c) -- let's rename its contained function to PyOS_Getopt, get
rid of the irritating __BEOS__ #ifdef'ery therein, prototype it the way we
like, and have Python use that instead on all systems.  Every second we've
spent tracking down problems with platform-supplied getopts has been a waste
of time.

they've-had-21-years-to-straighten-out-"the-std"-getopt-and-they-blew-it-
    ly y'rs  - tim





From jack at oratrix.nl  Fri Oct 13 00:03:57 2000
From: jack at oratrix.nl (Jack Jansen)
Date: Fri, 13 Oct 2000 00:03:57 +0200
Subject: [Python-Dev] MacPython 2.0c1 available
Message-ID: <20001012220402.ABE8D104729@oratrix.oratrix.nl>

MacPython 2.0c1 is available, both as binary installer and in source
form. You can find it through
http://www.cwi.nl/~jac/macpython.html. If people give it a testdrive
please let me know whether it works, and, in the unlikely event it
doesn't:-) what the problems are.

Thanks,
--
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/ ++++



From guido at python.org  Fri Oct 13 01:07:28 2000
From: guido at python.org (Guido van Rossum)
Date: Thu, 12 Oct 2000 18:07:28 -0500
Subject: [Python-Dev] Re: getopt() prototype [was: checkin-message of something or other]
In-Reply-To: Your message of "Thu, 12 Oct 2000 17:38:13 -0400."
             <LNBBLJKPBEHFEDALKOLCIEAGHLAA.tim_one@email.msn.com> 
References: <LNBBLJKPBEHFEDALKOLCIEAGHLAA.tim_one@email.msn.com> 
Message-ID: <200010122307.SAA09493@cj20424-a.reston1.va.home.com>

> I have a different suggestion:  screw it.  getopt keeps creating problems on
> GNUish systems too, because without the POSIXLY_CORRECT envar set, the GNU
> getopt shuffles all the "option strings" to the front, making a mess of,
> e.g.,
> 
> python myprog.py -v
> 
> The Python source tree already has its own getopt implementation
> (Python/getopt.c) -- let's rename its contained function to PyOS_Getopt, get
> rid of the irritating __BEOS__ #ifdef'ery therein, prototype it the way we
> like, and have Python use that instead on all systems.  Every second we've
> spent tracking down problems with platform-supplied getopts has been a waste
> of time.

Excellent.  After 2.0.

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



From thomas at xs4all.net  Fri Oct 13 00:18:01 2000
From: thomas at xs4all.net (Thomas Wouters)
Date: Fri, 13 Oct 2000 00:18:01 +0200
Subject: [Python-Dev] Re: getopt() prototype [was: checkin-message of something or other]
In-Reply-To: <LNBBLJKPBEHFEDALKOLCIEAGHLAA.tim_one@email.msn.com>; from tim_one@email.msn.com on Thu, Oct 12, 2000 at 05:38:13PM -0400
References: <20001012211436.Z12812@xs4all.nl> <LNBBLJKPBEHFEDALKOLCIEAGHLAA.tim_one@email.msn.com>
Message-ID: <20001013001801.A12812@xs4all.nl>

On Thu, Oct 12, 2000 at 05:38:13PM -0400, Tim Peters wrote:
> [Thomas Wouters, on getopt]
> > ...
> > From what I read in the getopt(3) manpage on my linux box the
> > prototype mixup comes from a POSIX.2 flaw, but I'm not sure.)
> 
> I bet it's actually talking about Interpretation 150 to POSIX.2, here (while
> you can't read the std online, you can read the complaints online!):

> http://standards.ieee.org/reading/ieee/interp/1003-2-92_int/pasc-1003.2-150.
> html

> Doesn't have anything to do with the prototype, alas.

Ah, that sounds about right. Nifty link, too. I thought it had something to
do with the prototype because of this comment:

CONFORMING TO
       getopt():
              POSIX.2,    provided   the   environment   variable
              POSIXLY_CORRECT is set.  Otherwise, the elements of
              argv  aren't really const, because we permute them.
              We pretend they're const in  the  prototype  to  be
              compatible with other systems.


> I have a different suggestion:  screw it.  getopt keeps creating problems on
> GNUish systems too, because without the POSIXLY_CORRECT envar set, the GNU
> getopt shuffles all the "option strings" to the front, making a mess of
  [ a lot of things ]

Ahh, yes, I see Python/getopt.c and the autoconf check that enables it when
necessary. Funny, I've seen that file a number of times, and read it, and
read the getopt autoconf test as well, but somehow I never connected it with
the loose prototype in main.c. I'm +1 on doing what you suggested, then.

Wonder why it hasn't been done yet, though... we have no use for a
system-wide getopt, except for a slightly smaller binary on systems that do
have a 'good' system getopt. We can't use enhancements made to system getopt
or anything, anyway.

> they've-had-21-years-to-straighten-out-"the-std"-getopt-and-they-blew-it-
>     ly y'rs  - tim

what-do-you-want-to-bet-it's-going-to-take-longer-for-Python-getopt-modules-
	ly y'rs,

-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!



From m.favas at per.dem.csiro.au  Fri Oct 13 02:47:25 2000
From: m.favas at per.dem.csiro.au (Mark Favas)
Date: Fri, 13 Oct 2000 08:47:25 +0800
Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich
 comparison)
Message-ID: <39E65B9D.B9F6BA70@per.dem.csiro.au>

Just a little unreality check - the whole world is not (yet) Linux - or
even MS. The behaviour of math.exp(-746) on my flavours of 1.5.2 on
Solaris boxes and DEC Alphas (Tru64 Unix) is the same as the behaviour
of 2.0 - OverflowError: math range error. Thus, on these platform, the
proposed fixes _will_ change behaviour. But that's cool - I like Tim's
proposed, um, steps to "rationalizing" fp behaviour, and will do what I
can to help in the future.
-- 
Email - m.favas at per.dem.csiro.au
        CSIRO Exploration & Mining



From tim_one at email.msn.com  Fri Oct 13 07:15:13 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Fri, 13 Oct 2000 01:15:13 -0400
Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich  comparison)
In-Reply-To: <39E65B9D.B9F6BA70@per.dem.csiro.au>
Message-ID: <LNBBLJKPBEHFEDALKOLCCEBBHLAA.tim_one@email.msn.com>

[Mark Favas]
> Just a little unreality check - the whole world is not (yet) Linux - or
> even MS. The behaviour of math.exp(-746) on my flavours of 1.5.2 on
> Solaris boxes and DEC Alphas (Tru64 Unix) is the same as the behaviour
> of 2.0 - OverflowError: math range error.

This is unfortunate.  Guido never intended for Python to raise exceptions on
underflow (and especially not *Over*flowError(!)), but he apparently didn't
run on any platforms where this happened (I never have!), and AFAIK nobody
ever mentioned this before.

> Thus, on these platform, the proposed fixes _will_ change behaviour.

See "unfortunate" above <0.5 wink>.

> But that's cool - I like Tim's proposed, um, steps to "rationalizing"
> fp behaviour, and will do what I can to help in the future.

Want to fund a crack group of 754 experts for a year?  Didn't think so.
Constructive complaints will help a lot.  So will beta testing.  For
example, I'm very keen to know whether the current CVS version of Python
(2.0c1) still raises OverflowError for math.exp(-746) on your Solaris and/or
Tru64 Unix boxes.  Running the (current CVS) std test suite will tell you:
test_libm will pass or fail accordingly.  If it's still busted on one of
your systems, we've only got about a day to fix it (2.0 final is shipping
early next week, and we have to let the codebase settle down for a couple
days before building the final release).

but-since-it's-been-a-random-mess-for-a-decade-already-i'm-not-
    losing-much-sleep-over-it-ly y'rs  - tim





From tim_one at email.msn.com  Fri Oct 13 07:18:52 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Fri, 13 Oct 2000 01:18:52 -0400
Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich  comparison)
In-Reply-To: <LNBBLJKPBEHFEDALKOLCCEBBHLAA.tim_one@email.msn.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCKEBBHLAA.tim_one@email.msn.com>

[Tim hallucinated ...]
> ... I'm very keen to know whether the current CVS version of Python
> (2.0c1) still raises OverflowError for math.exp(-746) on your
> Solaris and/or Tru64 Unix boxes.

Sorry for contradicting myself within a single sentence:  I couldn't care
less what happens in 2.0c1 anymore.  Like I clearly said at the start,
"current CVS version" is the question.





From bwarsaw at beopen.com  Fri Oct 13 07:33:57 2000
From: bwarsaw at beopen.com (Barry A. Warsaw)
Date: Fri, 13 Oct 2000 01:33:57 -0400 (EDT)
Subject: [Python-Dev] test_minidom non-failure failure? (take 2)
References: <14821.58057.358947.271778@bitdiddle.concentric.net>
	<20001012023134.A18254@glacier.fnational.com>
	<200010121739.MAA07968@cj20424-a.reston1.va.home.com>
	<20001012032448.A18407@glacier.fnational.com>
	<14822.6858.920988.167252@bitdiddle.concentric.net>
	<20001012062010.A19026@glacier.fnational.com>
	<200010122126.QAA09072@cj20424-a.reston1.va.home.com>
	<20001012064309.C19026@glacier.fnational.com>
Message-ID: <14822.40645.656159.493390@anthem.concentric.net>

>>>>> "NS" == Neil Schemenauer <nas at arctrix.com> writes:

    NS> Again, "-l" should probably not be a default.  I don't know
    NS> who added it to TESTOPTS but it wasn't me.

I did, but at the time -l set LEAK_DEBUG not DEBUG_SAVEALL, and I
think (but don't really remember) that LEAK_DEBUG had different
semantics than it does now.

No matter.  This was useful when gc was spankin' new and only
semi-tested.  It's probably fine to turn off -l in "make test" by
default for the 2.0 release.

-Barry



From tim_one at email.msn.com  Fri Oct 13 10:01:16 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Fri, 13 Oct 2000 04:01:16 -0400
Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison)
In-Reply-To: <slrn8ucd0a.4id.hzhu@localhost.localdomain>
Message-ID: <LNBBLJKPBEHFEDALKOLCIEBCHLAA.tim_one@email.msn.com>

[Tim]
> ...
> We cannot consider this to be a bug since Python has had no *intended*
> behavior whatsoever wrt 754 gimmicks.  We can and do consider gripes
> about these accidents to be feature requests.

[Huaiyu Zhu]
> Yes it varies widely in Python.  But isn't that precisely because Python
> does not support IEEE?

Yes, but that's darned near tautological <0.5 wink>.

> If Python does not actively undermine IEEE on platforms that have it,
> would it still vary widely across these platforms?

Yes.  Your own -lieee example showed that math.sqrt(-1) computes not only a
non-754 result, but a senseless result, on your platform under 1.5.2.  If I
show you a platform, how are you going to decide whether it "has" IEEE?  754
is a very involved std, and it's still rare to find a platform C that
supports it correctly.  On platform C's that do support it correctly, I know
of none that do so without requiring platform-specific tricks.  Python has
*nothing* portable it can rely on, and its mass of utterly non-754-aware
code building on haphazard C implementations adds up to the random
x-platform crap we have today.

...
[T]
> The patch to stop setting -lieee was contributed by a Python user who
> claimed it fixed bugs on *their* platform.  That's "the reason".
> We don't want to screw them either.

[H]
> Q: What bug?  Which platform?  Maybe there is another way that has less
>    impact on others?  How to find out?

I didn't check it in, and you can search the CVS archives as easily as I can
(I'm not inclined to, since I don't think it can affect the outcome of
this).  Jeremy Hylton may, or may not, remember more about it (IIRC, he said
he checked it in).

> ...
> If there is a way to fix the bug on that other platform while still keep
> -lieee on Linux, would that be acceptable?

No:  Guido *wants* overflow to raise OverflowError by default, and *wants*
sqrt(-1.0) to raise ValueError by default.  Python's x-platform fp numerics
today are an utter mess, and the best we can do for 2.0 is to make them as
consistent as we have time to make them, despite that we know it will break
some of your code (but you can still link with -lieee if you feel you must),
and that Mark Favas has confirmed it will break code under both his Solaris
and Tru64 Unix systems (but for a reason opposite of yours:  he's been
getting OverflowError on underflow since 1.5.2, and we're taking that away
from him, and he'll have *no* way to go back).  At this point we favor
forcing consistency over maintaining platform accidents, no matter how
attached people have gotten to them; else we'll be stuck with them forever.

[oh some of Kahan's papers, at http://http.cs.berkeley.edu/~wkahan/]
> Interesting! I've glanced through some of Prof Kahan's writings.

He is an entertaining writer, although his rhetoric is often more extreme
than either of ours <wink>.

> It appears that he favors raising flags that can be checked optionally,
and
> he is against mandatary raising exceptions.

Have you read the 754 std?  He's in favor of the 754 std.

[quotes snipped, except for my favorite, which I've paraphrased many times
 over the years on c.l.py]
> ...
>   They are called "Exceptions" because to any policy for handling them,
>   imposed in advance upon all programmers by the computer system, some
>   programmers will have good reason to take exception.

> ...
> From these quotes and others I understand that he wants f.p. exceptions to
> be merely messanges, not errors that force programmers to take extra
> actions, unless the programmer choose to.  So what aspect of Java did he
> think is deficient?  It is the "Trap" style exception that mandate a users
> action.

His paper "How JAVA's Floating-Point Hurts Everyone Everywhere" lists his 5
main gripes about Java in bullet points at the top of page 3.  The paper
runs on to 80 pages.  You somehow managed to miss 79.89 of them <0.4 wink>,
reducing it to a bogus claim about Java that Kahan didn't make (Java has
neither "Trap" nor "Flag" style fp exception signaling).

> He told "A cautionary Tale of the Ariane 5",

Which has nothing to do with Java -- the software in question was written in
Ada, which (unlike Java) has "Trap" style.  Why he put it in a paper about
Java is a bit of a mystery; I write it off to rhetorical excess.

> the European rocket that mulfunctioned after lift off.  It turned out
> that a piece of software produced an unimportant exception that is
> not caught by a handler and caused debugging data to be dumped to a
> critical memory location.  This would have been avoided if the exception
> merely raised a flag and returned a NaN, and the program continued.

Actually, that was impossible to do, and he didn't suggest that.  What he
wrote is

    Had overflow merely obeyed the IEEE 754 default policy, the
    recalibration software would have raised a flag and delivered an
    invalid result both to be ignored by the motor guidance programs,
    and the Ariane 5 would have pursued its intended trajectory.

Note that he didn't say NaN.  He couldn't, because this was overflow in a
conversion from Float to Integer.  Despite his cheery optimism here, 754 is
approximately useless in this case, since there is no generally accepted
"invalid result" in integer formats (and 754 doesn't define one either --
the result of overflow in converting floats to ints is ill-defined in 754;
754 doesn't even require that it set the overflow flag).

> So do we want every Python program to bomb whenever there is a floating
> point value outside bound and is not trapped by try/except?

By default, yes, Guido does, but for overflow, not underflow.  If you read
the following section of Kahan's paper, you should have noticed that he is
*just* as critical of just returning Infs and NaNs (which is all Java does,
and which is the accidental Python behavior you're arguing we keep in glibc)
as he is of just trapping!  His conclusion:  "Without Traps nor Flags, Java?
s floating-point is Dangerous":

    Without flags, detecting rare creations of Inf and NaN before they
    disappear requires programmed tests and branches that, besides
    duplicating tests already performed by the hardware, slow down the
    program and impel a programmer to make decisions prematurely in many
    cases. Worse, a plethora of tests and branches undermines a program?s
    modularity, clarity and concurrency.

I agree with him there wholeheartedly:  without the 754-mandated flags,
*and* without raising exceptions, the subset of 754 remaining sucks.

>> ironically, 754 is hardest to sell to those who could benefit from
>> it the most.

> So far the only concern from number-crunchers voiced here is that it might
> allow sqrt(-1)==0, which is not the case.

Gimme a break!  In the very msg Paul Dubois said that, he also said "Some
people use Inf but most people want the code to STOP so they can find out
where the INFS started.  Otherwise, two hours later you have big arrays of
Infs and no idea how it happened.".  I'm starting to drop my assumption of
good faith on your part:  what you remember and how you paraphrase (whether
it's Paul or Kahan) is extremely selective, beyond normal bounds of
zeal-inspired distortion.

> I was a fortran programmer before.  I switched to using IEEE ten years
> ago as soon as it was available on the machine I was using.  So there
> are different opinions.

Certainly, and good 754 support will cater to most of them.  I don't believe
your opinion (or mine, for that matter) reflects anything even close to the
majority view here, though.  As I said in my reply to Paul, my observations
(based on 15 years on the vendor side of the fp biz) matched his exactly
(based on his experience with hundreds of numeric code authors):  a vast
majority still want divide-by-0, invalid operation, and overflow to raise an
exception the vast majority of the time.

> ...
> Obviously we agree on the benefit of having a choice.  But we
> have different perspective on what choice means.  Your want a choice
> to force user to take explicit action, I want a choice to ignore these
> events.

No.  I want exactly the choices 754 lays out:  user-settable sticky flags
and user-maskable exceptions.  We're not getting that for 2.0.  And we're
*never* getting it if 2.0 doesn't do *something* to start disabusing people
of the notion that their historical numeric platform accidents in Python
will be faithfully preserved forever more.

> The ideal solution might be to have a sys.fp_exception class.  Each
> exception would set a flag like fp_exception.overflow so that user can
> check them.  There could also be a variable like fp_exception.force_trap,
> which when set, could make each f.p. exception to produce a Python
> exception.  This would confirm to IEEE 754 and give both of us a choice
> we want.

Kinda, except that each of the 5 754-defined traps must be individually
maskable.  754 spells out what's needed.  A PEP will be required to spell
out the Python- and C-level APIs.  I've corresponded (just -- no time now) a
little with Kevin Jacobs about that offline.

> Now that we are in feature freeze for 2.0, we can't get both choices.
> Can we adopt the one that does not break behaviors on previous official
> release, even if that's only by accident?

Not as far as Guido or I are concerned, no.  You can link with -lieee
yourself if you must, although I can't recommend perpetuating the x-platform
confusion here.  We want to say that, e.g., math.exp works substantially the
same way on *all* platforms under 2.0, not repeat the same decade-old "umm,
don't know, and no way to guess -- try it on your platform and see what it
does" yet again.  I don't expect 2.0 will actually achieve that on all
platforms, but it should on the primary ones.

> ...
> So now I know why people reported that NaN and Inf were broken on HPUX
> and Windows and some others.  If Python had simply ignored the flags ...

Then we would have broken 754 subsets in slightly subtler ways, and still
wildly varying across platforms.

> ...
> Could you please point a URL to "presubstitution"?  In the paragraphs I
> quoted the only mention of presubstitute is with NaNs and Inf, etc.

Sorry, I don't save URLs, and don't recall whether this was in a paper or on
David Hough's "Numeric Interest" mailing list in the early 90's.  A Google
search on "presubstitution Kahan" turns up 4 promising-looking hits I'll
leave you to pursue.  The basic idea is that the programmer gets to specify,
via library calls (whatever), which particular fp value each 754 exceptional
case returns.  So, e.g., if it made sense for some part of the app, the
programmer could say they wanted +- pi returned instead +- Inf, if and
whenever overflow happened.  Then set it back to +- Inf (or anything else
they needed) later.  This would be best if supported in HW directly, of
course.

> ...
> You are not confirming to 754 until you allow all the exceptions to go
> through with well defined values as default.

I know that, but don't care.  As I said, enabling overflow + invalid + div0
by default is the only scheme that can be *sold*.  If you can find two NumPy
users in favor of disabling them all by default, I'll be mildly astonished.
754 did itself enormous harm by insisting on that trivial point (it's
trivial because, with proper support, anyone can change the defaults to
anything they like with one line of code):  I worked in the supercomputer
biz at the time 754 was adopted, and for a decade after, and the "non stop"
defaults were *universally* opposed by customers.  Scared the hell out of
language stds committees too, which goes a lot farther than the 754 folks
would like to admit toward explaining why language committees stayed away
from 754 bindings in droves.  C99 is 15 years(!) after the fact.

> Raising Python exceptions on some of them does not confirm to 754, as
> the default IEEE 754 behavior on f.p. exception is not a Python exception,
> but just a raised flag.

See above.

> Before that happens, what is the motive to make IEEE less usable for those
> who have it (pretty much every one nowadays), even if just by accident?

I think I've repeated the reasons to death already, and you've repeated to
death that you'll never agree.  So no more from me on that.

> ...
> But just to clarify some wordings you quoted in another post: I meant that
> sqrt(-1)==0 is insane, whether silent or not.

I agree.

> Raising an exception is sane,

Not according to 754's default rules, which you wanted me to take as sacred
just a few paragraphs ago <wink>.

> although OverflowError is not so reasonable.

I'd say it's insane.

> Raising a ValueError is reasonable.

I expect we'll have to make InvalidOperationError a subclass of ValueError
for that reason, when 754 support materializes.

> But just returning NaN without a fuss is even better.

You're going to find that's a very lonely position.

> My favorite is returning 1j, as MatPy does.

Then you should use cmath.sqrt instead of math.sqrt.  Even $3 business
calculators have a sqrt key these days, and you do not want to be on the
other end of email when trying to explain to a businessperson why their
crappy std deviation program returned a complex number <0.1 wink>.

> if-it-ain't-broke-don't-fix-it-ly y'rs

it-it-weren't-broke-we-wouldn't-ly y'rs  - tim





From fgranger at altern.org  Fri Oct 13 12:08:23 2000
From: fgranger at altern.org (Francois Granger)
Date: Fri, 13 Oct 2000 12:08:23 +0200
Subject: [Python-Dev] Re: [Pythonmac-SIG] MacPython 2.0c1 available
In-Reply-To: <20001012220402.ABE8D104729@oratrix.oratrix.nl>
Message-ID: <B60CABB6.14362%fgranger@altern.org>

on 13/10/00 0:03, Jack Jansen at jack at oratrix.nl wrote:

> MacPython 2.0c1 is available, both as binary installer and in source
> form. You can find it through
> http://www.cwi.nl/~jac/macpython.html.

This one works better.

http://www.cwi.nl/~jack/macpython.html


-- 
Fran?ois Granger
fgranger at altern.org




From nas at arctrix.com  Fri Oct 13 08:37:17 2000
From: nas at arctrix.com (Neil Schemenauer)
Date: Thu, 12 Oct 2000 23:37:17 -0700
Subject: [Python-Dev] test_minidom non-failure failure? (take 2)
In-Reply-To: <14822.40645.656159.493390@anthem.concentric.net>; from bwarsaw@beopen.com on Fri, Oct 13, 2000 at 01:33:57AM -0400
References: <14821.58057.358947.271778@bitdiddle.concentric.net> <20001012023134.A18254@glacier.fnational.com> <200010121739.MAA07968@cj20424-a.reston1.va.home.com> <20001012032448.A18407@glacier.fnational.com> <14822.6858.920988.167252@bitdiddle.concentric.net> <20001012062010.A19026@glacier.fnational.com> <200010122126.QAA09072@cj20424-a.reston1.va.home.com> <20001012064309.C19026@glacier.fnational.com> <14822.40645.656159.493390@anthem.concentric.net>
Message-ID: <20001012233717.A20054@glacier.fnational.com>

On Fri, Oct 13, 2000 at 01:33:57AM -0400, Barry A. Warsaw wrote:
> I think (but don't really remember) that LEAK_DEBUG had
> different semantics than it does now.

Nope.  LEAK_DEBUG prints to stderr information about all garbage
the GC finds, even stuff the GC can free.  The thinking was that
GC would be an option and people would want to find applications
that leak when only using reference counting.

> No matter.  This was useful when gc was spankin' new and only
> semi-tested.  It's probably fine to turn off -l in "make test" by
> default for the 2.0 release.

I've left -l enabled for now.  Detecting tests that create
uncollectable garbage is probably a good thing.  It doesn't cost
much and the message should be fairly clear now.

  Neil



From fdrake at beopen.com  Fri Oct 13 15:34:03 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Fri, 13 Oct 2000 09:34:03 -0400 (EDT)
Subject: [Python-Dev] test_minidom non-failure failure? (take 2)
In-Reply-To: <20001012233717.A20054@glacier.fnational.com>
References: <14821.58057.358947.271778@bitdiddle.concentric.net>
	<20001012023134.A18254@glacier.fnational.com>
	<200010121739.MAA07968@cj20424-a.reston1.va.home.com>
	<20001012032448.A18407@glacier.fnational.com>
	<14822.6858.920988.167252@bitdiddle.concentric.net>
	<20001012062010.A19026@glacier.fnational.com>
	<200010122126.QAA09072@cj20424-a.reston1.va.home.com>
	<20001012064309.C19026@glacier.fnational.com>
	<14822.40645.656159.493390@anthem.concentric.net>
	<20001012233717.A20054@glacier.fnational.com>
Message-ID: <14823.3915.245246.310674@cj42289-a.reston1.va.home.com>

Neil Schemenauer writes:
 > I've left -l enabled for now.  Detecting tests that create
 > uncollectable garbage is probably a good thing.  It doesn't cost
 > much and the message should be fairly clear now.

  Perhaps one thing that could be done is to reduce the volume of the
output; perhaps just list the first 1K or 2K of the repr?


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From nas at arctrix.com  Fri Oct 13 09:09:48 2000
From: nas at arctrix.com (Neil Schemenauer)
Date: Fri, 13 Oct 2000 00:09:48 -0700
Subject: [Python-Dev] test_minidom non-failure failure? (take 2)
In-Reply-To: <14823.3915.245246.310674@cj42289-a.reston1.va.home.com>; from fdrake@beopen.com on Fri, Oct 13, 2000 at 09:34:03AM -0400
References: <20001012023134.A18254@glacier.fnational.com> <200010121739.MAA07968@cj20424-a.reston1.va.home.com> <20001012032448.A18407@glacier.fnational.com> <14822.6858.920988.167252@bitdiddle.concentric.net> <20001012062010.A19026@glacier.fnational.com> <200010122126.QAA09072@cj20424-a.reston1.va.home.com> <20001012064309.C19026@glacier.fnational.com> <14822.40645.656159.493390@anthem.concentric.net> <20001012233717.A20054@glacier.fnational.com> <14823.3915.245246.310674@cj42289-a.reston1.va.home.com>
Message-ID: <20001013000948.C20054@glacier.fnational.com>

On Fri, Oct 13, 2000 at 09:34:03AM -0400, Fred L. Drake, Jr. wrote:
> Perhaps one thing that could be done is to reduce the volume of the
> output; perhaps just list the first 1K or 2K of the repr?

It just prints the number of object found now.

  Neil



From fdrake at beopen.com  Fri Oct 13 16:06:22 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Fri, 13 Oct 2000 10:06:22 -0400 (EDT)
Subject: [Python-Dev] test_minidom non-failure failure? (take 2)
In-Reply-To: <20001013000948.C20054@glacier.fnational.com>
References: <20001012023134.A18254@glacier.fnational.com>
	<200010121739.MAA07968@cj20424-a.reston1.va.home.com>
	<20001012032448.A18407@glacier.fnational.com>
	<14822.6858.920988.167252@bitdiddle.concentric.net>
	<20001012062010.A19026@glacier.fnational.com>
	<200010122126.QAA09072@cj20424-a.reston1.va.home.com>
	<20001012064309.C19026@glacier.fnational.com>
	<14822.40645.656159.493390@anthem.concentric.net>
	<20001012233717.A20054@glacier.fnational.com>
	<14823.3915.245246.310674@cj42289-a.reston1.va.home.com>
	<20001013000948.C20054@glacier.fnational.com>
Message-ID: <14823.5854.638859.950835@cj42289-a.reston1.va.home.com>

Neil Schemenauer writes:
 > It just prints the number of object found now.

  Ok, I must have missed the checkin that changed that.  This is fine
in my book as well.
  Thanks for staying on top of this work!  I think you've really done
a great job with the GC effort.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From cgw at fnal.gov  Fri Oct 13 17:18:23 2000
From: cgw at fnal.gov (Charles G Waldman)
Date: Fri, 13 Oct 2000 10:18:23 -0500 (CDT)
Subject: [Python-Dev] can't build with threads on OSF/1
Message-ID: <14823.10175.741638.857531@buffalo.fnal.gov>

Sorry, I don't have time to investigate this fully right now.  Maybe
this weekend.  For now this is just a heads-up.  Hopefully, something
is just misconfigured on this system.

The machine in question is running OSF1 V4.0 878 alpha

I can only build Python from current CVS sources on OSF/1 if I specify
--without-thread.   If I don't specify this I get the following errors
at link time:

Unresolved:
__pthread_mutex_init
__pthread_mutex_destroy
__pthread_mutex_lock
__pthread_mutex_unlock
__pthread_cond_init
__pthread_cond_destroy
__pthread_cond_signal
__pthread_cond_wait
__pthread_create
__pthread_detach

I tried sending a message with the output of ./configure and make
attached, but it was over the 40K limit.  If anybody wants to see
these, email me.



From nas at arctrix.com  Fri Oct 13 10:28:49 2000
From: nas at arctrix.com (Neil Schemenauer)
Date: Fri, 13 Oct 2000 01:28:49 -0700
Subject: [Python-Dev] can't build with threads on OSF/1
In-Reply-To: <14823.10175.741638.857531@buffalo.fnal.gov>; from cgw@fnal.gov on Fri, Oct 13, 2000 at 10:18:23AM -0500
References: <14823.10175.741638.857531@buffalo.fnal.gov>
Message-ID: <20001013012849.C20168@glacier.fnational.com>

On Fri, Oct 13, 2000 at 10:18:23AM -0500, Charles G Waldman wrote:
> Unresolved:
> __pthread_mutex_init
[...]

What is the LIBS variable set to in Modules/Makefile?  It looks
your missing something like "-lpthread".

  Neil



From cgw at fnal.gov  Fri Oct 13 17:35:52 2000
From: cgw at fnal.gov (Charles G Waldman)
Date: Fri, 13 Oct 2000 10:35:52 -0500 (CDT)
Subject: [Python-Dev] can't build with threads on OSF/1
In-Reply-To: <20001013012849.C20168@glacier.fnational.com>
References: <14823.10175.741638.857531@buffalo.fnal.gov>
	<20001013012849.C20168@glacier.fnational.com>
Message-ID: <14823.11224.545609.761307@buffalo.fnal.gov>

Neil Schemenauer writes:
 > On Fri, Oct 13, 2000 at 10:18:23AM -0500, Charles G Waldman wrote:
 > > Unresolved:
 > > __pthread_mutex_init
 > [...]
 > 
 > What is the LIBS variable set to in Modules/Makefile?  It looks
 > your missing something like "-lpthread".

Hehehe.  I might be kinda thick sometimes, but I think I would have
caught that.  Here's a little more of the "make" output:

cd Modules;  make OPT="-O -Olimit 1500" VERSION="2.0"  prefix="/usr/local" exec_prefix="/usr/local"  LIBRARY=../libpython2.0.a link
 cc   python.o  ../libpython2.0.a -ldb                                 -lpthreads -lm  -o python 
ld:
Unresolved:
__pthread_mutex_init
__pthread_mutex_destroy
__pthread_mutex_lock
__pthread_mutex_unlock
__pthread_cond_init
__pthread_cond_destroy
__pthread_cond_signal
__pthread_cond_wait
__pthread_create
__pthread_detach
*** Exit 1
Stop.
*** Exit 1
Stop.




From thomas at xs4all.net  Fri Oct 13 18:34:36 2000
From: thomas at xs4all.net (Thomas Wouters)
Date: Fri, 13 Oct 2000 18:34:36 +0200
Subject: [Python-Dev] can't build with threads on OSF/1
In-Reply-To: <14823.10175.741638.857531@buffalo.fnal.gov>; from cgw@fnal.gov on Fri, Oct 13, 2000 at 10:18:23AM -0500
References: <14823.10175.741638.857531@buffalo.fnal.gov>
Message-ID: <20001013183436.B12812@xs4all.nl>

On Fri, Oct 13, 2000 at 10:18:23AM -0500, Charles G Waldman wrote:

> Sorry, I don't have time to investigate this fully right now.  Maybe
> this weekend.  For now this is just a heads-up.  Hopefully, something
> is just misconfigured on this system.

> The machine in question is running OSF1 V4.0 878 alpha

That's a former DEC alpha, right ? Perhaps running configure with
'--with-dec-threads' will solve the problem ? I'm not sure if that will work
alone, so you might need '--with-dec-threads --with-threads=no' to disable
'normal' thread-checking. 

You can also try this by hand; after running configure, edit
Modules/Makefile.pre, and change

LDLAST=

into

LDLAST= -threads

(not -lthreads, just -threads) That seems to be the only difference
--with-dec-threads uses.

I looked at this before, but don't have an alpha or anything else that needs
--with-dec-threads, so I couldn't detect this automatically. I do think it
should be done automatically, though. Perhaps I can figure it if you can
send me, for instance, config.log and the output of configure, and find the
time to run a few tests later. 

> I can only build Python from current CVS sources on OSF/1 if I specify
> --without-thread.   If I don't specify this I get the following errors
> at link time:

> Unresolved:
> __pthread_mutex_init

> I tried sending a message with the output of ./configure and make
> attached, but it was over the 40K limit.  If anybody wants to see
> these, email me.

If the above doesn't fix it, I can take a look at the output of configure
and config.log. No need to see the output of make just yet.

-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!



From cgw at fnal.gov  Fri Oct 13 20:31:34 2000
From: cgw at fnal.gov (Charles G Waldman)
Date: Fri, 13 Oct 2000 13:31:34 -0500 (CDT)
Subject: [Python-Dev] can't build with threads on OSF/1
In-Reply-To: <20001013183436.B12812@xs4all.nl>
References: <14823.10175.741638.857531@buffalo.fnal.gov>
	<20001013183436.B12812@xs4all.nl>
Message-ID: <14823.21766.733905.575290@buffalo.fnal.gov>

Thomas Wouters writes:
 > 
 > That's a former DEC alpha, right ? Perhaps running configure with
 > '--with-dec-threads' will solve the problem ? I'm not sure if that will work
 > alone, so you might need '--with-dec-threads --with-threads=no' to disable
 > 'normal' thread-checking. 

Thank you, that indeed solves the problem.  Sorry for the noise.

It would be nice if configure were smart enough to figure this out!




From cgw at fnal.gov  Fri Oct 13 20:38:26 2000
From: cgw at fnal.gov (Charles G Waldman)
Date: Fri, 13 Oct 2000 13:38:26 -0500 (CDT)
Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee,
 and rich  comparison)
In-Reply-To: <LNBBLJKPBEHFEDALKOLCIECGHLAA.tim_one@email.msn.com>
References: <200010131453.JAA23050@buffalo.fnal.gov>
	<LNBBLJKPBEHFEDALKOLCIECGHLAA.tim_one@email.msn.com>
Message-ID: <14823.22178.605732.455689@buffalo.fnal.gov>

Tim Peters wrote:
 > I'm very keen to know whether the current CVS version of Python
 > (2.0c1) still raises OverflowError for math.exp(-746) on your
 > Solaris and/or Tru64 Unix boxes.

I just repeated this test, on the following 4 platforms:

1)   SunOS fsui02 5.6 Generic_105181-21 sun4u sparc SUNW,Ultra-Enterprise
     cc: WorkShop Compilers 4.2 30 Oct 1996 C 4.2

2)   OSF1 V4.0 878 alpha
     DEC C V5.6-079 on Digital UNIX V4.0 (Rev. 878)

3)   IRIX64 6.5 07151432 IP27
     MIPSpro Compilers: Version 7.2.1

4)   Linux 2.2.16 #31 SMP Thu Jun 29 14:51:26 CDT 2000 i686
     gcc version 2.95.2 19991024 (release)

On all of the above systems, math.exp(-999) returns 0.0, math.sqrt(-1)
raises an exception, and test_math.py completes successfully.

Testing-ly (not to be confused with testily) yr's,
		cgw



From tim_one at email.msn.com  Fri Oct 13 20:56:43 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Fri, 13 Oct 2000 14:56:43 -0400
Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich  comparison)
In-Reply-To: <14823.22178.605732.455689@buffalo.fnal.gov>
Message-ID: <LNBBLJKPBEHFEDALKOLCIECKHLAA.tim_one@email.msn.com>

[Charles G Waldman]
> I just repeated this test, on the following 4 platforms:
>
> 1)   SunOS fsui02 5.6 Generic_105181-21 sun4u sparc SUNW,Ultra-Enterprise
>      cc: WorkShop Compilers 4.2 30 Oct 1996 C 4.2
>
> 2)   OSF1 V4.0 878 alpha
>      DEC C V5.6-079 on Digital UNIX V4.0 (Rev. 878)
>
> 3)   IRIX64 6.5 07151432 IP27
>      MIPSpro Compilers: Version 7.2.1
>
> 4)   Linux 2.2.16 #31 SMP Thu Jun 29 14:51:26 CDT 2000 i686
>      gcc version 2.95.2 19991024 (release)
>
> On all of the above systems, math.exp(-999) returns 0.0, math.sqrt(-1)
> raises an exception, and test_math.py completes successfully.

Excellent!  Note that test_math.py was augmented to verify that:

1. exp(-huge) returns 0 without exception.
2. exp(+huge) raises OverflowError.
3. sqrt(-1) raises ValueError.

None of those were reliable across platforms before, and I'm afraid there's
strong reason to suspect one or more still won't work right under Mandrake
Linux when Python is compiled with -O (this based on the output of a C
program someone posted to c.l.py yesterday).    But it's a world better than
it used to be.

> Testing-ly (not to be confused with testily) yr's,

You bet -- everyone leave testily to me on this one.  I'm bitter enough
about floating-point in stinking C for everyone combined <0.9 wink>.





From thomas at xs4all.net  Fri Oct 13 21:19:38 2000
From: thomas at xs4all.net (Thomas Wouters)
Date: Fri, 13 Oct 2000 21:19:38 +0200
Subject: [Python-Dev] can't build with threads on OSF/1
In-Reply-To: <14823.21766.733905.575290@buffalo.fnal.gov>; from cgw@fnal.gov on Fri, Oct 13, 2000 at 01:31:34PM -0500
References: <14823.10175.741638.857531@buffalo.fnal.gov> <20001013183436.B12812@xs4all.nl> <14823.21766.733905.575290@buffalo.fnal.gov>
Message-ID: <20001013211938.C12812@xs4all.nl>

On Fri, Oct 13, 2000 at 01:31:34PM -0500, Charles G Waldman wrote:
> Thomas Wouters writes:
>  > 
>  > That's a former DEC alpha, right ? Perhaps running configure with
>  > '--with-dec-threads' will solve the problem ? I'm not sure if that will work
>  > alone, so you might need '--with-dec-threads --with-threads=no' to disable
>  > 'normal' thread-checking. 

> Thank you, that indeed solves the problem.  Sorry for the noise.

No problem. When I went over the README file a few weeks back, and sent
Guido an update, this particular issue was one of the biggest problems for
me: the old README, which assumed threads were not default, was quite
adamant about using --with-dec-threads for OSF/1 and its incarnations.
Unfortunately, it doesn't say why :) And the configure script only says that
it's necessary to get threadsafe libraries.

> It would be nice if configure were smart enough to figure this out!

Configure is as smart as we make it. configure is made by autoconf, which is
moderately intelligent, and we just have to add the extra geniality to
configure.in. If the only check we need is 'does this system call itself
OSF1', we can easily add that. See the attached patch (configure.in version
only. Let me know if you need a patched configure as well, I don't know if
OSF systems come with autoconf. It's pretty large, though, and you don't
need to generate configure on the same system as you run it on. Just apply
the configure.in patch, type 'autoconf', and copy the resulting configure
script to your OSF1 machine.)

The question is, is this enough ? Will this detect all the OSF platforms
that need '-threads', and will it only add it to those platforms ? It
wouldn't be particularly nice of configure if it insisted on adding
'-threads' on platforms that don't need it, or worse, break because of it.
For instance, the patch uses 'OSF*', which might be too generic... but
'OSF1' might be too restrictive :-) A better fix would probably be to write
a test program that explicitly uses threads & the -threads arguments, but
that could fail for a large number of reasons, which doesn't mean -threads
isn't needed :P

(Configure is really amusing like that. For instance, if your compile system
is broken, like when you unpacked a new linux kernel source tree in
/usr/src/linux, but forgot to type 'make symlinks', configure will assume
the worst (every check is negative, after all.) If you're lucky, it will
complain because you miss an essential feature... If you're unlucky, it
finishes cleanly, writes the config.cache file, your compile fails, you
figure out the problem, and you keep compiling using the wrong autoconf
'settings'. And re-configuring doesn't fix it, because the config.cache file
is just fine ;)

-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
-------------- next part --------------
Index: configure.in
===================================================================
RCS file: /cvsroot/python/python/dist/src/configure.in,v
retrieving revision 1.172
diff -c -r1.172 configure.in
*** configure.in	2000/10/12 17:11:38	1.172
--- configure.in	2000/10/13 19:15:11
***************
*** 805,810 ****
--- 805,819 ----
      LIBS="$LIBS -lthread"
      LIBOBJS="$LIBOBJS thread.o"
      USE_THREAD_MODULE=""])
+ 
+     if test "$USE_THREAD_MODULE" != "#"
+     then
+         # If the above checks didn't disable threads, (at least) OSF1
+         # needs this '-threads' argument during linking.
+         case $ac_sys_system in
+         OSF*) LDLAST=-threads;;
+         esac
+     fi
  fi
  
  # Check for GC support

From skip at mojam.com  Fri Oct 13 21:39:42 2000
From: skip at mojam.com (Skip Montanaro)
Date: Fri, 13 Oct 2000 14:39:42 -0500 (CDT)
Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich  comparison)
In-Reply-To: <LNBBLJKPBEHFEDALKOLCIECKHLAA.tim_one@email.msn.com>
References: <14823.22178.605732.455689@buffalo.fnal.gov>
	<LNBBLJKPBEHFEDALKOLCIECKHLAA.tim_one@email.msn.com>
Message-ID: <14823.25854.786347.542654@beluga.mojam.com>

    Tim> None of those were reliable across platforms before, and I'm afraid
    Tim> there's strong reason to suspect one or more still won't work right
    Tim> under Mandrake Linux when Python is compiled with -O (this based on
    Tim> the output of a C program someone posted to c.l.py yesterday).  But
    Tim> it's a world better than it used to be.

After executing

    cvs update -d .
    ./configure
    make clean
    make OPT=-O3

I get the following output from regrtest.py regarding test_math:

    % ./python Lib/test/regrtest.py test_math
    test_math
    1 test OK.

This is on a Mandrake 7.1 system.  Here are the bits I think are relevant to
identify my environment:

    % cat /etc/issue.net
    Linux Mandrake release 7.1 (helium)
    Kernel 2.2.16-9mdk on an i686
    % gcc -v
    Reading specs from /usr/lib/gcc-lib/i586-mandrake-linux/2.95.3/specs
    gcc version 2.95.3 19991030 (prerelease)
    % rpm -q -a | egrep glibc
    glibc-devel-2.1.3-15mdk
    compat-glibc-5.3-2.0.7.6mdk
    glibc-2.1.3-15mdk

If you have a C test program you'd like me to try, shoot it over.  I'll be
glad to run it and shoot back the results.

Skip



From fdrake at beopen.com  Fri Oct 13 21:41:46 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Fri, 13 Oct 2000 15:41:46 -0400 (EDT)
Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich  comparison)
In-Reply-To: <14823.25854.786347.542654@beluga.mojam.com>
References: <14823.22178.605732.455689@buffalo.fnal.gov>
	<LNBBLJKPBEHFEDALKOLCIECKHLAA.tim_one@email.msn.com>
	<14823.25854.786347.542654@beluga.mojam.com>
Message-ID: <14823.25978.181614.85977@cj42289-a.reston1.va.home.com>

Skip Montanaro writes:
 > This is on a Mandrake 7.1 system.  Here are the bits I think are relevant to
 > identify my environment:

  The test passes for me as well on Mandrake 7.1.  Here's the
environment info:

% ./python -tt ../Lib/test/regrtest.py test_math
test_math
1 test OK.
% cat /etc/issue.net 
Welcome to %h
Linux Mandrake release 7.1 (helium)
Kernel 2.2.15-4mdk on an i686
% gcc -v
Reading specs from /usr/lib/gcc-lib/i586-mandrake-linux/2.95.3/specs
gcc version 2.95.3 19991030 (prerelease)
% rpm -qa | egrep glibc
nedit-5.1.1-1.glibc
glibc-profile-2.1.3-5mdk
glibc-2.1.3-5mdk
compat-glibc-5.3-2.0.7.6mdk
glibc-devel-2.1.3-5mdk

 > If you have a C test program you'd like me to try, shoot it over.  I'll be
 > glad to run it and shoot back the results.

  Same here...


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From cgw at fnal.gov  Fri Oct 13 21:52:44 2000
From: cgw at fnal.gov (Charles G Waldman)
Date: Fri, 13 Oct 2000 14:52:44 -0500 (CDT)
Subject: [Python-Dev] gcc versions (was:RE:  Possible bug (was Re: some other junk, ...))
In-Reply-To: <14823.25854.786347.542654@beluga.mojam.com>
References: <14823.22178.605732.455689@buffalo.fnal.gov>
	<LNBBLJKPBEHFEDALKOLCIECKHLAA.tim_one@email.msn.com>
	<14823.25854.786347.542654@beluga.mojam.com>
Message-ID: <14823.26636.59174.832572@buffalo.fnal.gov>

Skip Montanaro writes:

 > This is on a Mandrake 7.1 system.  Here are the bits I think are relevant to
 > identify my environment:

 >     % gcc -v
 >     Reading specs from /usr/lib/gcc-lib/i586-mandrake-linux/2.95.3/specs
 >     gcc version 2.95.3 19991030 (prerelease)

AFAIK, this version of GCC was never "blessed" by the GCC maintainers
and should not be being used for any production work.  I think
Mandrake did a bad thing by shipping this version.  Not quite as bad
as what RedHat did by shipping the completely not-for-general-use
gcc-2.96, but nonetheless still a bad thing.  When will distribution
builders learn that having a higher version number is not necessarily
a good thing?  Why do they keep second-guessing the good advice of the
GCC Steering Committee?  Sigh...

In any case, I don't think we should put effort into chasing down bugs
that are caused by bogus C compilers.  Any reports coming in from
RedHat 7.0 users or Mandrake 7.1 need to be evaluated in this light.




From fdrake at beopen.com  Fri Oct 13 21:58:53 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Fri, 13 Oct 2000 15:58:53 -0400 (EDT)
Subject: [Python-Dev] gcc versions (was:RE:  Possible bug (was Re: some other junk, ...))
In-Reply-To: <14823.26636.59174.832572@buffalo.fnal.gov>
References: <14823.22178.605732.455689@buffalo.fnal.gov>
	<LNBBLJKPBEHFEDALKOLCIECKHLAA.tim_one@email.msn.com>
	<14823.25854.786347.542654@beluga.mojam.com>
	<14823.26636.59174.832572@buffalo.fnal.gov>
Message-ID: <14823.27005.800291.217346@cj42289-a.reston1.va.home.com>

Charles G Waldman writes:
 > AFAIK, this version of GCC was never "blessed" by the GCC maintainers
 > and should not be being used for any production work.  I think
 > Mandrake did a bad thing by shipping this version.  Not quite as bad

  I agree.

 > In any case, I don't think we should put effort into chasing down bugs
 > that are caused by bogus C compilers.  Any reports coming in from
 > RedHat 7.0 users or Mandrake 7.1 need to be evaluated in this light.

  I think Skip & I were showing that there isn't a bug for Mandrake
7.1.  I don't know what version of GCC shipped with Mandrake 7.0,
which may have been the version Tim received the report for (I recall
he said "Mandrake 7", which isn't specific).


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From larsga at garshol.priv.no  Fri Oct 13 22:08:05 2000
From: larsga at garshol.priv.no (Lars Marius Garshol)
Date: 13 Oct 2000 22:08:05 +0200
Subject: [XML-SIG] Re: [Python-Dev] test_minidom non-failure failure? (take 2)
In-Reply-To: <14821.60663.213246.179325@cj42289-a.reston1.va.home.com>
References: <14821.58057.358947.271778@bitdiddle.concentric.net> 	<20001012023134.A18254@glacier.fnational.com> <14821.60663.213246.179325@cj42289-a.reston1.va.home.com>
Message-ID: <m37l7cpkre.fsf@lambda.garshol.priv.no>

* Fred L. Drake, Jr.
|
| This looks like a problem in the unlink() method of the DOM.  Could
| you please check that the unlink() method is updated to handle the
| latest version of the other changes?  

It seems that the current unlink() does not remove sibling cycles.
Patch #101897 adds a line to set sibling references to None, which
seems to make regrtest.py -l happy.

--Lars M.




From prescod at prescod.net  Fri Oct 13 22:12:38 2000
From: prescod at prescod.net (Paul)
Date: Fri, 13 Oct 2000 15:12:38 -0500 (CDT)
Subject: [XML-SIG] Re: [Python-Dev] test_minidom non-failure failure?
 (take 2)
In-Reply-To: <m37l7cpkre.fsf@lambda.garshol.priv.no>
Message-ID: <Pine.LNX.4.21.0010131512240.4759-100000@amati.techno.com>

Right, I just checked in the fix to that.

 Paul Prescod

On 13 Oct 2000, Lars Marius Garshol wrote:

> 
> * Fred L. Drake, Jr.
> |
> | This looks like a problem in the unlink() method of the DOM.  Could
> | you please check that the unlink() method is updated to handle the
> | latest version of the other changes?  
> 
> It seems that the current unlink() does not remove sibling cycles.
> Patch #101897 adds a line to set sibling references to None, which
> seems to make regrtest.py -l happy.
> 
> --Lars M.
> 
> 
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://www.python.org/mailman/listinfo/python-dev
> 




From tim_one at email.msn.com  Fri Oct 13 22:23:31 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Fri, 13 Oct 2000 16:23:31 -0400
Subject: Mandrake vs glibc (was RE: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich  comparison)
In-Reply-To: <14823.25854.786347.542654@beluga.mojam.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCMEDEHLAA.tim_one@email.msn.com>

The original source of my concern was this c.l.py post from David Cooke:

    http://www.deja.com/getdoc.xp?AN=680840594

He ran a little C program that Huaiyu Zhu had posted earlier in the thread.
According to David's results, under "Linux-Mandrake 7.1 (glibc 2.1.3) ...
without -lieee, but compiled with -O ... gcc 2.95.2.", platform exp and sqrt
*never* set errno, regardless of input.  In which case what Python does with
the platform NaN result from math.sqrt(-1.) is an accident (and probably
ends up setting errno to ERANGE itself by mistake), and an overflowing exp
would let the platform +Inf result pass thru silently.

So, if David's report is correct, and best I understand it you were all
using 7.1 too with at least some level of optimization, it's A Mystery why
CVS test_math.py succeeds on that system (its new math.sqrt(-1) test would
probably fail; its new math.exp(+huge) test would almost certainly fail).
I'm anal enough about this stuff that I'd try to figure out why if I had a
Mandrake system, but in the cosmic scheme of things I doubt it's important
enough for anyone else to burn time on.





From jeremy at beopen.com  Sat Oct 14 01:05:02 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Fri, 13 Oct 2000 19:05:02 -0400 (EDT)
Subject: [Python-Dev] build problems large and small on FreeBSD
Message-ID: <14823.38174.143372.125749@bitdiddle.concentric.net>

I just built the latest CVS sources on a FreeBSD machine (4.1-RELEASE
FreeBSD).  There are a number of compiler warnings, all having to do
with redefinitions, plus some linker warnings and a test failure.

I don't have time to investigate further, but thought I'd let people
know in case someone else has time to take a look.

test_math failed -- overflowing exp() didn't trigger OverflowError

Python 2.0c1 (#2, Oct 13 2000, 15:50:26) 
[GCC 2.95.2 19991024 (release)] on freebsd4
Type "copyright", "credits" or "license" for more information.
>>> import math
>>> math.exp(1200)
Inf

The warnings from the linker seem harmless enough.  I don't know why
it is complaining about setkey and des_setkey.  

/usr/lib/libc.so: WARNING!  setkey(3) not present in the system!
/usr/lib/libc.so: warning: this program uses gets(), which is unsafe.
/usr/lib/libc.so: warning: mktemp() possibly used unsafely; consider using mkstemp()
/usr/lib/libc.so: WARNING!  des_setkey(3) not present in the system!
/usr/lib/libc.so: WARNING!  encrypt(3) not present in the system!
/usr/lib/libc.so: warning: tmpnam() possibly used unsafely; consider using mkstemp()
/usr/lib/libc.so: warning: this program uses f_prealloc(), which is stupid.
/usr/lib/libc.so: WARNING!  des_cipher(3) not present in the system!
/usr/lib/libc.so: warning: tempnam() possibly used unsafely; consider using mkstemp()

The compiler-time warnings look like they are caused by a configure
problem.  If so, I don't know how to fix it :-).

gcc -O3 -I../../Python/../Include -I.. -DHAVE_CONFIG_H -c ../../Python/thread.c
In file included from /usr/include/unistd.h:42,
                 from ../../Python/thread.c:28:
/usr/include/sys/unistd.h:71: warning: `_POSIX_THREADS' redefined
../config.h:136: warning: this is the location of the previous definition
In file included from ../../Python/thread.c:118:
../../Python/thread_pthread.h:59: warning: `pthread_attr_default' redefined
/usr/include/pthread.h:158: warning: this is the location of the previous definition
../../Python/thread_pthread.h:60: warning: `pthread_mutexattr_default' redefined
/usr/include/pthread.h:157: warning: this is the location of the previous definition
../../Python/thread_pthread.h:61: warning: `pthread_condattr_default' redefined
/usr/include/pthread.h:156: warning: this is the location of the previous definition

Jeremy



From jeremy at beopen.com  Sat Oct 14 01:11:10 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Fri, 13 Oct 2000 19:11:10 -0400 (EDT)
Subject: [Python-Dev] warnings --with-pydebug
Message-ID: <14823.38542.908547.275077@bitdiddle.concentric.net>

If you configure using '--with-pydebug' you get a lot of compile-time
warnings. 

../../Python/ceval.c: In function `eval_code2':
../../Python/ceval.c:672: warning: value computed is not used
../../Python/ceval.c:675: warning: value computed is not used
../../Python/ceval.c:678: warning: value computed is not used
../../Python/ceval.c:680: warning: value computed is not used
../../Python/ceval.c:681: warning: value computed is not used
[etc.]

I assume these are caused by the definition of Py_INCREF
#define Py_INCREF(op) (_Py_RefTotal++, (op)->ob_refcnt++)

Is there some way to change this macro so that the warnings are
silenced? 

Jeremy



From thomas at xs4all.net  Sat Oct 14 01:28:19 2000
From: thomas at xs4all.net (Thomas Wouters)
Date: Sat, 14 Oct 2000 01:28:19 +0200
Subject: [Python-Dev] build problems large and small on FreeBSD
In-Reply-To: <14823.38174.143372.125749@bitdiddle.concentric.net>; from jeremy@beopen.com on Fri, Oct 13, 2000 at 07:05:02PM -0400
References: <14823.38174.143372.125749@bitdiddle.concentric.net>
Message-ID: <20001014012819.D12812@xs4all.nl>

On Fri, Oct 13, 2000 at 07:05:02PM -0400, Jeremy Hylton wrote:

> The warnings from the linker seem harmless enough.  I don't know why
> it is complaining about setkey and des_setkey.  

That's probably due to 'crypt()' being used, or some other library call that
Python uses indirectly. If you want crypt(), you need to install a seperate
DES encryption package under FreeBSD, IIRC. (It uses md5-hashes for all
crypt purposes by default, because of the US Counter-Espionage Protection
Plan or something :) If you don't want to install those, don't enable the
crypt module. There are a couple of pure python crypt() implementations
around, by the way, which always use pure DES crypt().

> /usr/lib/libc.so: warning: this program uses gets(), which is unsafe.

This one is weirdish. I don't see any gets() call in Python, so I have to
assume it's in some library or header file Python includes. A good candidate
would be readline, which has appalled me before :) but who knows :P I'm
inclined to think it isn't a library that comes with FreeBSD by default,
since they are usually pretty picky about such things. (especially if it
generates a linker warning each time it's used!)

> /usr/lib/libc.so: warning: mktemp() possibly used unsafely; consider using mkstemp()
> /usr/lib/libc.so: warning: tmpnam() possibly used unsafely; consider using mkstemp()
> /usr/lib/libc.so: warning: tempnam() possibly used unsafely; consider using mkstemp()

Yes, I've seen this before. Debian-unstable (I think ?) complains about
tmpnam() and tempnam() as well. The manpages just say 'don't use
this function, use mkstemp(3)'. It doesn't mention a reason, but it's
probably because the files/directories created by these functions are
predictable, which means you shouldn't use them for security-by-obscurity.

The mktemp() warning doesn't come from Python, looks like. Probably another
library that is included. If you really care about which it is, you'll have
to comment them out one by one (I'd suggest starting with the oldest and
least FreeBSDish one, i.e. readline :) but I don't think it's going to
really matter. Python does use 'tempnam' and 'tmpnam', but only in the
posixmodule, to provide Python versions. I'm not sure if we can just change
these functions to use mkstemp (or tempfile, see below) internally, without
breaking code, though I expect it'll be alright. What's more, these
functions are new since 1.5.2. And also, I just noticed a bug/typo in the
tempnam docstring.

The one funny bit, though, is that these three functions point to mkstemp(),
and the mkstemp() manpage reads this:

       Don't use this  function,  use  tmpfile(3)  instead.  It's
       better defined and more portable.

"When does the hurting stop ?"

> /usr/lib/libc.so: warning: this program uses f_prealloc(), which is stupid.

And this falls in the 'it wasn't us' category again.

> The compiler-time warnings look like they are caused by a configure
> problem.  If so, I don't know how to fix it :-).

> gcc -O3 -I../../Python/../Include -I.. -DHAVE_CONFIG_H -c ../../Python/thread.c
> In file included from /usr/include/unistd.h:42,
>                  from ../../Python/thread.c:28:
> /usr/include/sys/unistd.h:71: warning: `_POSIX_THREADS' redefined
> ../config.h:136: warning: this is the location of the previous definition

Hm, yes. This looks like an unfortunate clash between a Python internal
#define and a FreeBSD libc internal #define. I'm not sure if this is really
the case, maybe the Python one serves exactly the same purpose as the
FreeBSD one, but in that case, configure shouldn't redefine it. We can
either rename the #define in Python, as it's only used to determine which
thread functionality is available, or adjust the configure tests to see if
it is #defined and not redefine it if so.

(Or rather, to be sure that it defines the right thing, configure would have
to test for posix threads, check the #define (if any), and if they don't
match up, scream its head off. So perhaps renaming is the smarter thing.) On
the other hand, the fact that you only got a warning, and not an error,
means that Python isn't defining it to a different value than FreeBSD did, so
it's not really a problem. It might be a problem if Python #defines it, but
FreeBSD does not, but FreeBSD does have code that checks that #define, and
starts doing weird things...

> In file included from ../../Python/thread.c:118:
> ../../Python/thread_pthread.h:59: warning: `pthread_attr_default' redefined
> /usr/include/pthread.h:158: warning: this is the location of the previous definition
> ../../Python/thread_pthread.h:60: warning: `pthread_mutexattr_default' redefined
> /usr/include/pthread.h:157: warning: this is the location of the previous definition
> ../../Python/thread_pthread.h:61: warning: `pthread_condattr_default' redefined
> /usr/include/pthread.h:156: warning: this is the location of the previous definition

Not sure about these, because I don't know enough about the various types of
posix thread standards, and almost-posix thread almost-standards. I'm not
sure if those names are reserved in any way, but they are apparently
clashing with FreeBSD names. Or perhaps it's FreeBSD 'compatibility' code
that does the defines like Python does, too. A simple '#undef' or '#ifndef'
would suffice, here, I think, but I'm not sure.


-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!



From thomas at xs4all.net  Sat Oct 14 01:33:59 2000
From: thomas at xs4all.net (Thomas Wouters)
Date: Sat, 14 Oct 2000 01:33:59 +0200
Subject: [Python-Dev] warnings --with-pydebug
In-Reply-To: <14823.38542.908547.275077@bitdiddle.concentric.net>; from jeremy@beopen.com on Fri, Oct 13, 2000 at 07:11:10PM -0400
References: <14823.38542.908547.275077@bitdiddle.concentric.net>
Message-ID: <20001014013359.E12812@xs4all.nl>

On Fri, Oct 13, 2000 at 07:11:10PM -0400, Jeremy Hylton wrote:
> If you configure using '--with-pydebug' you get a lot of compile-time
> warnings. 

> ../../Python/ceval.c: In function `eval_code2':
> ../../Python/ceval.c:672: warning: value computed is not used
> ../../Python/ceval.c:675: warning: value computed is not used
> ../../Python/ceval.c:678: warning: value computed is not used
> ../../Python/ceval.c:680: warning: value computed is not used
> ../../Python/ceval.c:681: warning: value computed is not used
> [etc.]

> I assume these are caused by the definition of Py_INCREF
> #define Py_INCREF(op) (_Py_RefTotal++, (op)->ob_refcnt++)

> Is there some way to change this macro so that the warnings are
> silenced? 

Yes, prefix it with '(void)':

#define Py_INCREF(op) (void)(_Py_RefTotal++, (op)->ob_refcnt++)

However, that means that the 'return value' of Py_INCREF() must never be
used anywhere. (If it does, it'll generate an error.) The return value of
Py_INCREF() is not terribly useful, though. Both in debug and in normal
mode, it expands to the refcount of the object *before* it was INCREF'd.

I still consider this kind of warning (I've seen it before, always with
macros that do several things by using the otherwise fairly useless
tuple-creator in C ;) a bit of a bug in gcc: it knows both those statements
have sideeffects, and it's obvious we want to throw away the first result,
so why worry about the second ? But at least it isn't screwing up
floating-point operations, and nobody's perfect :-)

-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!



From huaiyu_zhu at yahoo.com  Sat Oct 14 02:25:49 2000
From: huaiyu_zhu at yahoo.com (Huaiyu Zhu)
Date: Fri, 13 Oct 2000 17:25:49 -0700 (PDT)
Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich
 comparison)
In-Reply-To: <LNBBLJKPBEHFEDALKOLCIEBCHLAA.tim_one@email.msn.com>
Message-ID: <Pine.LNX.4.10.10010131015350.3117-100000@rocket.knowledgetrack.com>

Tim,

Thank you for the explanations.  We actually agree more than it appears:

- Full IEEE 754 support in Python is good, which should allow the user to
  decide when to use raised flags and when to use Python exceptions.

- If the user default can be changed with one line of code, it does not
  matter if Python default use exceptions, even if that's not strict
  compliance in words.  The "factory default" might as well set for the
  benefit of newbies.

- Without IEEE 754 support, or with just partial support, f.p. computation
  is a mess.

Following are some contentious issues:

I am not so sure that even with 754, there would still be a great variety.
I see you giving one example: sqrt(-1) in 1.5.2.  But wasn't that caused by
extra Python checking?  I say this because errno==0 in C.  Maybe I'm missing
something.  Or, do you mean that glibc itself is deficient, because it
should have set the flag?

My worry concerns the decision to unify 2.0 f.p. behavior in a specific way
before full IEEE 754 support.  I understand that you say this does not count
as a changed behavior because the previous one is accidental.  But I don't
see the particular fixed subset chosen as any better than any other. I agree
that I do have a choice of using -lieee, though.

It is interesting to know that someone actually relies on OverflowError to
detect underflow.  But why not let them continue that as well, given that
all of these would be available in the future anyway?

> At this point we favor forcing consistency over maintaining platform
> accidents, no matter how attached people have gotten to them; else we'll
> be stuck with them forever.

I do not understand.  Once there is full IEEE 754, everyone would have a
choice, which pretty much includes all the things people are doing now.
Before that happens, why consistency accross platform is deemed more
important than consistency accross releases?  My naive thinking is that
people port more from 1.5.2 to 2.0 than from one platform to another, isn't
it?  :-)

Following does not have much new to say, just some clarification.

You are right to emphasise that Kahan does not favor any subset of IEEE 754:

> >   They are called "Exceptions" because to any policy for handling them,
> >   imposed in advance upon all programmers by the computer system, some
> >   programmers will have good reason to take exception.

Yes.  And that's what's happening. :-)

> His paper "How JAVA's Floating-Point Hurts Everyone Everywhere" lists his 5
> main gripes about Java in bullet points at the top of page 3.  The paper
> runs on to 80 pages.  You somehow managed to miss 79.89 of them <0.4 wink>,
> reducing it to a bogus claim about Java that Kahan didn't make (Java has
> neither "Trap" nor "Flag" style fp exception signaling).

Thank you for correcting me on this one.  I did "glance over" all the pages.
I was somewhat puzzled by his decriptions, so I made a quick test: 1/0, and
got Exception in thread "main" java.lang.ArithmeticException: / by zero

But now I see that 1/0.0 is Infinity.  So is Math.exp(777).  And so on.
So that teaches me to test, test, test, ...

> > He told "A cautionary Tale of the Ariane 5",
> 
> Which has nothing to do with Java -- the software in question was written in
> Ada, which (unlike Java) has "Trap" style.  Why he put it in a paper about
> Java is a bit of a mystery; I write it off to rhetorical excess.

You are right it does not apply to Java.  I guess he meant that as a warning
that changing to the other side might be equally bad.

> > So do we want every Python program to bomb whenever there is a floating
> > point value outside bound and is not trapped by try/except?
> 
> By default, yes, Guido does, but for overflow, not underflow.

That's the harsh reality I have to live with, I suppose. <0.9wink>

>  If you read
> the following section of Kahan's paper, you should have noticed that he is
> *just* as critical of just returning Infs and NaNs (which is all Java does,
> and which is the accidental Python behavior you're arguing we keep in glibc)
> as he is of just trapping!  His conclusion:  "Without Traps nor Flags, Java?
> s floating-point is Dangerous":
> 
>     Without flags, detecting rare creations of Inf and NaN before they
>     disappear requires programmed tests and branches that, besides
>     duplicating tests already performed by the hardware, slow down the
>     program and impel a programmer to make decisions prematurely in many
>     cases. Worse, a plethora of tests and branches undermines a program?s
>     modularity, clarity and concurrency.
> 
> I agree with him there wholeheartedly:  without the 754-mandated flags,
> *and* without raising exceptions, the subset of 754 remaining sucks.

That is true, but all these problems apply to "without raising flags",
whether with or without "raising exceptions".  Silent overflow forces
programmers to do extra checking if they need to find them.  Mandatory
exception forces programmer to do extra checking if they don't want them to
stop the program.  Which is more common?  It depends on programming style.
In my programs, intentional NaN is far more than NaN by mistake.

As to whether it is dangerous, I would say that if an overflow is really an
error, good programming style requires that it be detected much earlier than
the actual overflow.  I agree this cannot be expected of everyone, though.

> >> ironically, 754 is hardest to sell to those who could benefit from
> >> it the most.
> 
> > So far the only concern from number-crunchers voiced here is that it might
> > allow sqrt(-1)==0, which is not the case.
> 
> Gimme a break!  In the very msg Paul Dubois said that, he also said "Some
> people use Inf but most people want the code to STOP so they can find out
> where the INFS started.  Otherwise, two hours later you have big arrays of
> Infs and no idea how it happened.".  I'm starting to drop my assumption of
> good faith on your part:  what you remember and how you paraphrase (whether
> it's Paul or Kahan) is extremely selective, beyond normal bounds of
> zeal-inspired distortion.

Well, I was talking about whether anyone has shown a concern to oppose 754.
I was not talking about whether exception is prefered to flags.  See the
line I was replying to?  Actually, thinking about it, Paul was not talking
about concerns over 754, either.  So there appears zero resistence to 754
from number crunchers here.

> > Obviously we agree on the benefit of having a choice.  But we
> > have different perspective on what choice means.  Your want a choice
> > to force user to take explicit action, I want a choice to ignore these
> > events.
> 
> No.  I want exactly the choices 754 lays out:  user-settable sticky flags
> and user-maskable exceptions.  We're not getting that for 2.0.  And we're
> *never* getting it if 2.0 doesn't do *something* to start disabusing people
> of the notion that their historical numeric platform accidents in Python
> will be faithfully preserved forever more.

Let me make it clear that we agree on all essential points about full 754
support.  The difference only exists in the period before that.  Since both
the 1.5.2 accidental behaviors and the one you want to unify to are just
subsets of the full support, it does not appear to me that disabling several
of them is a prerequisite for the full support.

> Kinda, except that each of the 5 754-defined traps must be individually
> maskable.  754 spells out what's needed.  A PEP will be required to spell
> out the Python- and C-level APIs.  I've corresponded (just -- no time now) a
> little with Kevin Jacobs about that offline.

Great!  If the true IEEE 754 support could come soon, all my gripe is moot.
So I'll stop disturbing you on the good work.  :-)

OK, I see that you want consistency above anything else before that good day
comes.  Well, consistency is good.  Whether the price is too high is a
subjective judgement.  So I'll just use the -lieee hack for myself, then.

[On presubstitution] 

Ok, I found it.  It looks good.

[On whether 754 default uses flags or exceptions] 

I agree with you: the system default matters very little as long as users
can set their own defaults easily.
 
> I expect we'll have to make InvalidOperationError a subclass of ValueError
> for that reason, when 754 support materializes.

That'll be handy.

> > My favorite is returning 1j, as MatPy does.
> 
> Then you should use cmath.sqrt instead of math.sqrt. 

Thanks.

Huaiyu




From skip at mojam.com  Sat Oct 14 02:29:06 2000
From: skip at mojam.com (Skip Montanaro)
Date: Fri, 13 Oct 2000 19:29:06 -0500 (CDT)
Subject: [Python-Dev] Simple xml.sax example?
Message-ID: <14823.43218.337621.157021@beluga.mojam.com>

Is there a simple example available that demonstrates how to use elements of
the new xml.sax package?  I'd prefer something that doesn't require me to
install anything other than what comes with the Python 2.0 distribution?

Thanks,

Skip




From cbarker at jps.net  Sat Oct 14 03:22:28 2000
From: cbarker at jps.net (Chris Barker)
Date: Fri, 13 Oct 2000 18:22:28 -0700
Subject: [Python-Dev] RE: [Numpy-discussion] RE: Possible bug (was Re: numpy, 
 overflow, inf, ieee, and rich comparison)
References: <LNBBLJKPBEHFEDALKOLCEEACHLAA.tim_one@email.msn.com>
Message-ID: <39E7B554.29A168E3@jps.net>

Incomplete vs. non-at-all IEEE 754 support is a non argument. If you
have full IEEE support (which it seems everyone here thinks would be
good, but difficult), it is clear what you have. If not, you are not
consistent with a standard, and therefor making up your own. That being
the case, it's a matter of what we want the Python standard to be.

I, for one think that NaN and Inf are fantastic!!! I think the best
argument for them here is that it is almost impossible to do a lot of
array based calculations without them, and you can't do serious number
crunching in Python without array based calculations.

I've come to Python from MATLAB for numerics, and I really appreciated
MATLAB's way of handling all this. I don't think MATLAB has true 754
support, as I don't think you can change the behaviour, but you do get a
consistent result across platforms (including non-iee machines like the
Cray?---I have no idea). 

I have not yet heard a decent response to the question of what to do
when a single value in a large array is bad, and causes an exception.
This really does render Python essentially useless for Numerics for me.
I suspect all those number crunchers that want an exception rather than
an Inf are NOT using array-oriented languages. My goal is to dump MATLAB
for Python, but this may prevent me from doing that.

Does anyone know what other array-oriented languages use? I know what
MATLAB does:

>> exp(-777)
ans =
     0
>> exp(777)
ans =
   Inf
>> sqrt(-1)
ans =
        0 + 1.0000i

Hey! I like that! Python is dynamic, why can't we just get the actual
answer to sqrt(-1), without using cmath, that always returns a complex ?
sorry, other subjet, not meant to be raised at the moment.

>> 54/0
Warning: Divide by zero.
ans =
   Inf                   

Here we get a warning, but also a result that won't crash the
computation.

>> a = 0/0
Warning: Divide by zero.
a =
   NaN
>> b = a
b =
   NaN
>> a == b
ans =
     0            

So comparing two NaNs yields a false, as it should, and though Python
won't do it now, it could. One thing that a numerical routine should
NEVER do is give an incorrect answer. No answer is often bad, but an
incorrect one is much worse. NaN == NaN must return false.

Does anyone know what FORTRAN 90 specifies (if anything)? What other
array-oriented languages are there?

I think what MATLAB does is what Tim is calling "bad *and* incomplete
754 support" Incomplete is surely true, "bad" is clearly a matter of
opinion. It seems we have a variety of users of numerics in Python, that
I break into three broad catagories:

Casual users:
mostly doing non-numeric stuff, with the occasional calculation:
This group could use any non-cryptic handling of over/underflow, it just
doesn't matter.

Mid-level number crunchers:
This is the group I put myself in. We crunch a lot of numbers, really
like the array semantics (and speed) of NumPy, and are doing things like
graphing functions, statistical calculations, etc. We have probably only
taken one of two (at most) numerical analysis courses, and many don't
know what the heck IEE 754 is. (The one Numerical Analysis course I did
take, happened to be with Kahan, which is why I know what it is)

For this group, the incomplete IEEE support is probably the best way to
go. We're more likely to be annoyed by our whole computation stopping
because of one bad data point, than we are to be pissed off that it
didn't stop when it started to compute garbage.

Hard Core Number crunchers:
These are the folks that do things like write optimised routines for
particular architectures, adn teach numerical analysis courses. These
folks want either FULL IEEE, or plain old "classic" overflow and
underflow errors, that they can handle themselves. Do these folks really
use Python as other than a glue language? Are they really doing massive
number crunching in Python itself, rather than in C (or whatever)
extensions? If so, I'd be surprised is they didn't find Huaiyu's
argument compelling when doing array based calculations.

Tim pointed out that Python was not designed with 754 in mind, so for
2.0, what he is doing is probably our best bet, but it seems to not be
the best ultimate solution, I hope using NaN and Inf will be considered
for future versions, even if it is incomplete 754 compliance.

Note: if the ultimate goal is REAL IEEE 754 compliance, is it possible
without custom re-compiling your own interpreter? If so, is there any
chance that it will come any time soon (2.1 ?) , so we don't have to
have this discussion at all?

Thanks for all of your work on this, Python just keeps getting better!!

-Chris

-- 
Christopher Barker,
Ph.D.                                                           
cbarker at jps.net                      ---           ---           ---
http://www.jps.net/cbarker          -----@@       -----@@       -----@@
                                   ------@@@     ------@@@     ------@@@
Water Resources Engineering       ------   @    ------   @   ------   @
Coastal and Fluvial Hydrodynamics -------      ---------     --------    
------------------------------------------------------------------------
------------------------------------------------------------------------



From cgw at fnal.gov  Sat Oct 14 04:44:42 2000
From: cgw at fnal.gov (Charles G Waldman)
Date: Fri, 13 Oct 2000 21:44:42 -0500 (CDT)
Subject: [Python-Dev] RE: [Numpy-discussion] RE: Possible bug (was Re:
 numpy, overflow, inf, ieee, and rich comparison)
In-Reply-To: <39E7B554.29A168E3@jps.net>
References: <LNBBLJKPBEHFEDALKOLCEEACHLAA.tim_one@email.msn.com>
	<39E7B554.29A168E3@jps.net>
Message-ID: <14823.51354.977817.409017@buffalo.fnal.gov>

Chris Barker writes:

 > Hey! I like that! Python is dynamic, why can't we just get the actual
 > answer to sqrt(-1), without using cmath, that always returns a complex ?

You have to import the sqrt function from somewhere.  Either you
import it from math or from cmath, depending on which flavor you need.
Anybody sophisticated enough to know what complex numbers are, and
sophisticated enough to want to get complex values as a result of a
calculation, should be sophisticated enough to be able to type
"cmath".





From larsga at garshol.priv.no  Sat Oct 14 12:19:20 2000
From: larsga at garshol.priv.no (Lars Marius Garshol)
Date: 14 Oct 2000 12:19:20 +0200
Subject: [Python-Dev] Simple xml.sax example?
In-Reply-To: <14823.43218.337621.157021@beluga.mojam.com>
References: <14823.43218.337621.157021@beluga.mojam.com>
Message-ID: <m34s2fpvx3.fsf@lambda.garshol.priv.no>

* Skip Montanaro
|
| Is there a simple example available that demonstrates how to use
| elements of the new xml.sax package?

Here are a couple from an internal seminar I recently gave on this.  I
could make the slides available as well, if there is interest.

--Lars M.

--- elem_count.py

import sys

from xml.sax import make_parser, handler

class FancyCounter(handler.ContentHandler):

    def __init__(self):
        self._elems = 0
        self._attrs = 0
        self._elem_types = {}
        self._attr_types = {}

    def startElement(self, name, attrs):
        self._elems = self._elems + 1
        self._attrs = self._attrs + len(attrs)
        self._elem_types[name] = self._elem_types.get(name, 0) + 1

        for name in attrs.keys():
            self._attr_types[name] = self._attr_types.get(name, 0) + 1

    def endDocument(self):
        print "There were", self._elems, "elements."
        print "There were", self._attrs, "attributes."

        print "---ELEMENT TYPES"
        for pair in  self._elem_types.items():
            print "%20s %d" % pair

        print "---ATTRIBUTE TYPES"
        for pair in  self._attr_types.items():
            print "%20s %d" % pair

            
parser = make_parser()
parser.setContentHandler(FancyCounter())
parser.parse(sys.argv[1])

--- roundtrip.py

"""
A simple demo that reads in an XML document and spits out an equivalent,
but not necessarily identical, document.
"""

import sys, string

from xml.sax import saxutils, handler, make_parser

# --- The ContentHandler

class ContentGenerator(handler.ContentHandler):

    def __init__(self, out = sys.stdout):
        handler.ContentHandler.__init__(self)
        self._out = out

    # ContentHandler methods
        
    def startDocument(self):
        self._out.write('<?xml version="1.0" encoding="iso-8859-1"?>\n')

    def startElement(self, name, attrs):
        self._out.write('<' + name)
        for (name, value) in attrs.items():
            self._out.write(' %s="%s"' % (name, saxutils.escape(value)))
        self._out.write('>')

    def endElement(self, name):
        self._out.write('</%s>' % name)

    def characters(self, content):
        self._out.write(saxutils.escape(content))

    def ignorableWhitespace(self, content):
        self._out.write(content)
        
    def processingInstruction(self, target, data):
        self._out.write('<?%s %s?>' % (target, data))

# --- The main program

parser = make_parser()
parser.setContentHandler(ContentGenerator())
parser.parse(sys.argv[1])

--- rss2html.py

import sys

from xml.sax import make_parser, handler

# --- Templates

top = \
"""
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML>
<HEAD>
  <TITLE>%s</TITLE>
</HEAD>

<BODY>
<H1>%s</H1>
"""

bottom = \
"""
</ul>

<HR>
<ADDRESS>
Converted to HTML by sax_rss2html.py.
</ADDRESS>

</BODY>
</HTML>
"""

# --- The ContentHandler

class RSSHandler(handler.ContentHandler):

    def __init__(self, out = sys.stdout):
        handler.ContentHandler.__init__(self)
        self._out = out

        self._text = ""
        self._parent = None
        self._list_started = 0
        self._title = None
        self._link = None
        self._descr = ""

    # ContentHandler methods

    def startElement(self, name, attrs):
        if name == "channel" or name == "image" or name == "item":
            self._parent = name

        self._text = ""

    def endElement(self, name):
        if self._parent == "channel":
            if name == "title":
                self._out.write(top % (self._text, self._text))
            elif name == "description":
                self._out.write("<p>%s</p>\n" % self._text)

        elif self._parent == "item":
            if name == "title":
                self._title = self._text
            elif name == "link":
                self._link = self._text
            elif name == "description":
                self._descr = self._text
            elif name == "item":
                if not self._list_started:
                    self._out.write("<ul>\n")
                    self._list_started = 1

                self._out.write('  <li><a href="%s">%s</a> %s\n' %
                                (self._link, self._title, self._descr))

                self._title = None
                self._link = None
                self._descr = ""

        if name == "rss":
            self._out.write(bottom)
                
    def characters(self, content):
        self._text = self._text + content

# --- Main program

parser = make_parser()
parser.setContentHandler(RSSHandler())
parser.parse(sys.argv[1])




From thomas at xs4all.net  Sat Oct 14 13:05:41 2000
From: thomas at xs4all.net (Thomas Wouters)
Date: Sat, 14 Oct 2000 13:05:41 +0200
Subject: [Python-Dev] can't build with threads on OSF/1
In-Reply-To: <20001013211938.C12812@xs4all.nl>; from thomas@xs4all.net on Fri, Oct 13, 2000 at 09:19:38PM +0200
References: <14823.10175.741638.857531@buffalo.fnal.gov> <20001013183436.B12812@xs4all.nl> <14823.21766.733905.575290@buffalo.fnal.gov> <20001013211938.C12812@xs4all.nl>
Message-ID: <20001014130541.F12812@xs4all.nl>

On Fri, Oct 13, 2000 at 09:19:38PM +0200, Thomas Wouters wrote:

> On Fri, Oct 13, 2000 at 01:31:34PM -0500, Charles G Waldman wrote:

[ DEC threads (OSF1) are not automatically detected, causing a compilation
  failure on such systems ]

> > It would be nice if configure were smart enough to figure this out!

> ... we can easily add that. See the attached patch ...

Charles, if you get a chance to test this patch before monday, please do. I
think it's important to try and get the thread compiling right, now that
threads are on by default. This is going to create a lot of confusion with
OSF-users that don't read the README all the way through!

If you can't test it, perhaps we can apply it before 2.0 none the less. I
personally think there are more systems calling themselves OSF1 that do need
the -threads argument than there are that don't need it (if any) and the
patch only adds -threads if threads are really enabled. (Or perhaps change
the patch to read 'OSF1)' instead of 'OSF*)' in the case stmt, to be
conservative.)

-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!



From effbot at telia.com  Sat Oct 14 13:35:29 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Sat, 14 Oct 2000 13:35:29 +0200
Subject: [Python-Dev] can't build with threads on OSF/1
References: <14823.10175.741638.857531@buffalo.fnal.gov> <20001013183436.B12812@xs4all.nl> <14823.21766.733905.575290@buffalo.fnal.gov> <20001013211938.C12812@xs4all.nl> <20001014130541.F12812@xs4all.nl>
Message-ID: <009801c035d2$dc8ff4c0$3c6340d5@hagrid>

Thomas Wouters wrote:
> (Or perhaps change the patch to read 'OSF1)' instead of 'OSF*)'
> in the case stmt, to be conservative.)

are there really any others?

(that "1" is part of the original name, it's not a version number)

</F>





From thomas at xs4all.net  Sat Oct 14 13:28:20 2000
From: thomas at xs4all.net (Thomas Wouters)
Date: Sat, 14 Oct 2000 13:28:20 +0200
Subject: [Python-Dev] can't build with threads on OSF/1
In-Reply-To: <009801c035d2$dc8ff4c0$3c6340d5@hagrid>; from effbot@telia.com on Sat, Oct 14, 2000 at 01:35:29PM +0200
References: <14823.10175.741638.857531@buffalo.fnal.gov> <20001013183436.B12812@xs4all.nl> <14823.21766.733905.575290@buffalo.fnal.gov> <20001013211938.C12812@xs4all.nl> <20001014130541.F12812@xs4all.nl> <009801c035d2$dc8ff4c0$3c6340d5@hagrid>
Message-ID: <20001014132820.Y12776@xs4all.nl>

On Sat, Oct 14, 2000 at 01:35:29PM +0200, Fredrik Lundh wrote:

> Thomas Wouters wrote:
> > (Or perhaps change the patch to read 'OSF1)' instead of 'OSF*)'
> > in the case stmt, to be conservative.)

> are there really any others?

Don't know. That's why I asked it :)

> (that "1" is part of the original name, it's not a version number)

Ah, but that doesn't explain why configure.in OSF*) in some cases, and OSF1)
in others:

        case $ac_sys_system in
        OSF1)   CC=cc
                without_gcc=;;

versus

if test -z "$LDSHARED"
then
        case $ac_sys_system/$ac_sys_release in
[..]
        OSF*) LDSHARED="ld -shared -expect_unresolved \"*\"";;
[..]

I guess the OSF*) action is specific enough (most likely to lead to errors
on systems that call themselves, say, OSFORME) that we don't really have to
worry about it right now.

-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!



From fdrake at beopen.com  Sat Oct 14 14:32:33 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Sat, 14 Oct 2000 08:32:33 -0400 (EDT)
Subject: [Python-Dev] Simple xml.sax example?
In-Reply-To: <m34s2fpvx3.fsf@lambda.garshol.priv.no>
References: <14823.43218.337621.157021@beluga.mojam.com>
	<m34s2fpvx3.fsf@lambda.garshol.priv.no>
Message-ID: <14824.21089.373315.436615@cj42289-a.reston1.va.home.com>

Lars Marius Garshol writes:
 > Here are a couple from an internal seminar I recently gave on this.  I
 > could make the slides available as well, if there is interest.

  Could we include this in Demos/xml/ ?


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From cgw at fnal.gov  Sat Oct 14 15:08:30 2000
From: cgw at fnal.gov (Charles G Waldman)
Date: Sat, 14 Oct 2000 08:08:30 -0500 (CDT)
Subject: [Python-Dev] can't build with threads on OSF/1
In-Reply-To: <20001014130541.F12812@xs4all.nl>
References: <14823.10175.741638.857531@buffalo.fnal.gov>
	<20001013183436.B12812@xs4all.nl>
	<14823.21766.733905.575290@buffalo.fnal.gov>
	<20001013211938.C12812@xs4all.nl>
	<20001014130541.F12812@xs4all.nl>
Message-ID: <14824.23246.159738.283035@buffalo.fnal.gov>

Thomas Wouters writes:
 > 
 > Charles, if you get a chance to test this patch before monday, please do. I
 > think it's important to try and get the thread compiling right, now that
 > threads are on by default.

OK, I just tried it and it worked for me.  (I only tested it on one
OSF/1 system, but I suppose that's better than nothing).

Thanks for patching this, I think you are right that it will save a
lot of confusion (at least for that handful of people running this
OS!)



From m.favas at per.dem.csiro.au  Sat Oct 14 15:11:11 2000
From: m.favas at per.dem.csiro.au (Mark Favas)
Date: Sat, 14 Oct 2000 21:11:11 +0800
Subject: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich
 comparison)
Message-ID: <39E85B6F.E95AD41F@per.dem.csiro.au>

[Huaiyu Zhu, replying to Tim...]
>It is interesting to know that someone actually relies on >OverflowError to detect underflow.  But why not let them continue that >as well, given that all of these would be available in the future >anyway?

I think I'm the someone referred to - but I _don't_ rely on this at all.
I was reporting that, on my platforms, the behaviour of exp(-666) did
_not_ change between 1.5.2 and 2.0, both of which raised an
OverflowError (for underflow). I prefer Tim's change so that exp(-huge)
will produce 0, and that exp(huge) produces an OverflowError, even
though this changes the behaviour when moving from 1.5.2 to 2.x...

[Huaiyu Zhu again]
>Before that happens, why consistency accross platform is deemed more
>important than consistency accross releases?  My naive thinking is >that people port more from 1.5.2 to 2.0 than from one platform to >another, isn't it?  :-)

In spite of the smiley, I'd have to say (politely) "Rubbish!". One of
the many attractions of Python to me _is_ cross-platform consistency -
more so than up-version consistency. In my previous life as a
computational chemist I spent a lot of effort in writing code that was
portable - indeed, we developed a pre-processor language (which spat out
FORTRAN) to try to more easily handle
OS/compiler/word-size/FP-characteristic/phase-of-moon issues. I first
came up against IEEE stuff in the early 80's, and I agree with Tim - as
a user, I hated the non-stop defaults. Mollycoddled by CDC machines, I
was used to my code stopping when I divided by zero - it usually
indicated a coding or algorithmic error. When (if) Python supports
access to masking/unmasking 754 exceptions, that'll be good - in the
meantime, from my POV, the steps taken by Tim/Guido are in the right
direction.

-- 
Mark Favas  -   m.favas at per.dem.csiro.au
CSIRO, Private Bag No 5, Wembley, Western Australia 6913, AUSTRALIA



From thomas at xs4all.net  Sat Oct 14 19:12:34 2000
From: thomas at xs4all.net (Thomas Wouters)
Date: Sat, 14 Oct 2000 19:12:34 +0200
Subject: [Python-Dev] can't build with threads on OSF/1
In-Reply-To: <14824.23246.159738.283035@buffalo.fnal.gov>; from cgw@fnal.gov on Sat, Oct 14, 2000 at 08:08:30AM -0500
References: <14823.10175.741638.857531@buffalo.fnal.gov> <20001013183436.B12812@xs4all.nl> <14823.21766.733905.575290@buffalo.fnal.gov> <20001013211938.C12812@xs4all.nl> <20001014130541.F12812@xs4all.nl> <14824.23246.159738.283035@buffalo.fnal.gov>
Message-ID: <20001014191234.G12812@xs4all.nl>

On Sat, Oct 14, 2000 at 08:08:30AM -0500, Charles G Waldman wrote:
> Thomas Wouters writes:

>  > Charles, if you get a chance to test this patch before monday, please do. I
>  > think it's important to try and get the thread compiling right, now that
>  > threads are on by default.

> OK, I just tried it and it worked for me.  (I only tested it on one
> OSF/1 system, but I suppose that's better than nothing).

Yeah, I already tested it on the ther platforms I have. Not really
necessary, since the patch is really tiny and can only really be a problem
on platforms that have a 'system name' that matches 'OSF*' but don't need
'-threads'. Thanx for testing that it works, though.

Jeremy, are you OK on checking this autoconf change in ? Is it in time for
2.0-final ?

-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!



From jeremy at beopen.com  Sun Oct 15 00:11:30 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Sat, 14 Oct 2000 18:11:30 -0400
Subject: [Python-Dev] RE: [Python-checkins] CVS: distutils/distutils util.py,1.55,1.56
In-Reply-To: <200010140407.VAA08029@slayer.i.sourceforge.net>
Message-ID: <AJEAKILOCCJMDILAPGJNOEDKCCAA.jeremy@beopen.com>

Greg,

Do you intend these most recent changes to be included in 2.0 final on
Monday?  Just giving you a heads up in case you didn't realize what the
release schedule is.  The only changes we should be making are critical bugs
fixes for mainline code (non-demo, tools, etc.).

Also, there is some code in the top-level of the CVS repository that hasn't
been put in the previous source tarballs; at least the C code for the
Windows installer, but maybe other things as well.  Can you recommend how to
include this in the source distribution for the final release?  We'd like to
include *all* the source code for distutils.

Jeremy





From barry at scottb.demon.co.uk  Sun Oct 15 01:28:45 2000
From: barry at scottb.demon.co.uk (Barry Scott)
Date: Sun, 15 Oct 2000 00:28:45 +0100
Subject: [Python-Dev] Python 2.0b2 note for Windows developers
In-Reply-To: <LNBBLJKPBEHFEDALKOLCGEEEHKAA.tim_one@email.msn.com>
Message-ID: <000001c03636$7f5b5600$060210ac@private>


> -----Original Message-----
> From: Tim Peters [mailto:tim_one at email.msn.com]
> Sent: 08 October 2000 20:29
> To: Barry Scott; PythonDev; Python list
> Subject: RE: [Python-Dev] Python 2.0b2 note for Windows developers
> 
> 
> [Barry]
> > 	Two requests:
> >
> > 1. Can you ship the .PDB files for the debug images so devo's
> >    do not need to build the python sources to debug extensions.
> >    And Yes I know the .ZIP will be huge. If you want a
> >    compromise only include the .PDB for python20_d.dll.
> 
> Sure!  Most .pdb files are highly compressible, and the zip size hit isn't
> anything to worry about.

	Thanks

> 
> > 2. Place the files into libs, pyd etc dirs. I had to extract
> >    the groups into the right places which is a bit tedious
> >    and error prone.
> 
> No.  If you want a directory structure that doesn't match the actual build
> directory structure, I can't read your mind, and have no reason to believe
> that the specific artificial structure you have in mind is of use to anyone

	The structure I refer to is the one used by the Python Windows installer.

> but you.  Don't be so helpless <wink>:  write a tiny Python script to move

	I comment not because I'm lazy but because it seemed that every
	developer would need to reorganise the files.

> the files where you want them after unpacking.  What I upload will be an
> exact image of the build directory structure.  Most feedback I've gotten is
> that people want exactly that, because they *want* to compile Python

	I'd not thought of that. MY assumption was that I build the release
	windows code against the files installed by the python windows installer.
	And that the debug settings would logically point into the same
	structure.

> themselves and just want to avoid jumping thru all the snaky hoops needed to
> compile the 3rd-party subprojects (from _tkinter to zlib).
> 
> alphabetically y'rs  - tim

		Barry




From MarkH at ActiveState.com  Sun Oct 15 01:53:03 2000
From: MarkH at ActiveState.com (Mark Hammond)
Date: Sun, 15 Oct 2000 10:53:03 +1100
Subject: [Python-Dev] Python 2.0b2 note for Windows developers
In-Reply-To: <000001c03636$7f5b5600$060210ac@private>
Message-ID: <ECEPKNMJLHAPFFJHDOJBGEJADNAA.MarkH@ActiveState.com>

[Tim]
> the files where you want them after unpacking.  What I upload
> will be an exact image of the build directory structure.  Most
> feedback I've gotten is that people want exactly that,
> because they *want* to compile Python

[Barry]
> I'd not thought of that.

My either.  I must admit mild surprise at that.  If people want the debug
files in the same tree as the build tree, it seems all they are trying to
do is avoid the initial huge build.  If they intend compiling, why are they
asking for the binaries?

My experience with people wanting debug binaries is that they either don't
want to, or can not build.  When people need debug binaries, they go one of
2 routes - try and find pre-built debugs, or build them themselves.  I
can't see when people ever do both.

For the last year or so, I have been making Debug builds of win32all
available to registered users.  This has always been made available in the
"install" structure - quite a bit different than the source/build
structure.  I've never been asked for anything different.

Just-FWIW ly,

Mark.




From nick at nickbower.com  Sun Oct 15 07:09:26 2000
From: nick at nickbower.com (Nick Bower)
Date: Sun, 15 Oct 2000 05:09:26 GMT
Subject: [Python-Dev] RE: [Numpy-discussion] RE: Possible bug (was Re:
 numpy,  overflow, inf, ieee, and rich comparison)
In-Reply-To: <39E7B554.29A168E3@jps.net>
References: <LNBBLJKPBEHFEDALKOLCEEACHLAA.tim_one@email.msn.com> <39E7B554.29A168E3@jps.net>
Message-ID: <20001015.5092600@cricket.>

> Does anyone know what other array-oriented languages use? I know what
> MATLAB does:

I'm an Interactive Data Language or IDL user (the Univ of Wisconsin's 
Space Science Ceter is split down the middle between this and MatLab,  
but python/numpy is definitely on the increase).  As you can see from 
results below, like MatLab over/under-flows in IDL are reported but do 
not stop execution.  This is the best (only) possible scenario for an 
interactive arrays and visualization environment.

IDL> print, exp(-777)
      0.00000
% Program caused arithmetic error: Floating underflow
IDL> print, exp(777)
          Inf
% Program caused arithmetic error: Floating overflow
IDL> print, sqrt(-1)
         -NaN
% Program caused arithmetic error: Floating illegal operand
IDL> print, 54/0
      54
% Program caused arithmetic error: Integer divide by 0





From martin at loewis.home.cs.tu-berlin.de  Sun Oct 15 17:57:18 2000
From: martin at loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Sun, 15 Oct 2000 17:57:18 +0200
Subject: [Python-Dev] Mandrake vs glibc
Message-ID: <200010151557.RAA05091@loewis.home.cs.tu-berlin.de>

> So, if David's report is correct, and best I understand it you were
> all using 7.1 too with at least some level of optimization, it's A
> Mystery why CVS test_math.py succeeds on that system (its new
> math.sqrt(-1) test would probably fail; its new math.exp(+huge) test
> would almost certainly fail).  I'm anal enough about this stuff that
> I'd try to figure out why if I had a Mandrake system, but in the
> cosmic scheme of things I doubt it's important enough for anyone
> else to burn time on.

Well, I don't know about Mandrake, but I have glibc 2.1.94 here, and I
get

Python 2.0 (#104, Oct 15 2000, 15:47:19) 
[GCC 2.95.2 19991024 (release)] on linux2
Type "copyright", "credits" or "license" for more information.
>>> import math
>>> math.sqrt(-1)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
OverflowError: math range error
>>> math.exp(800)
inf
>>> math.exp(-800)
0.0

It turns that Tcl8.3 and Tk8.3, on my system, link with -lieee. That
is implemented as

_LIB_VERSION_TYPE _LIB_VERSION = _IEEE_;

in this version of glibc, which in turn changes the behaviour of 

double __exp(double x)		/* wrapper exp */
{
	double z;
	z = __ieee754_exp(x);
	if(_LIB_VERSION == _IEEE_) return z;
	if(__finite(x)) {
	    if(x>o_threshold)
	        return __kernel_standard(x,x,6); /* exp overflow */
	    else if(x<u_threshold)
	        return __kernel_standard(x,x,7); /* exp underflow */
	}
	return z;
}

As a rationale for linking with -lieee, the Tcl/Tk configure.in offers

#       Also, Linux requires the "ieee" library for math to
#       work right (and it must appear before "-lm").

Without testing, it seems that this would give some interesting
consequences on installations where Tkinter is a shared module: the
outcome of these functions could depend on whether Tkinter is imported
or not. I can't produce such a scenario with the BeOpen binaries on a
RedHat systems; the Tcl 8.0 RPMs of RedHat include the
tcltk-8.0-ieee.patch, which removes the line 

AC_CHECK_LIB(ieee, main, [MATH_LIBS="-lieee $MATH_LIBS"])

from both Tcl's and Tk's configure.in.

Of course, the problem is not restricted to Tcl: any extension module
that links with a shared library that includes libieee.a would change
the behaviour of Python's math functions.

Regards,
Martin




From martin at loewis.home.cs.tu-berlin.de  Sun Oct 15 18:43:23 2000
From: martin at loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Sun, 15 Oct 2000 18:43:23 +0200
Subject: [Python-Dev] distutils extra sources
Message-ID: <200010151643.SAA05423@loewis.home.cs.tu-berlin.de>

> Can you recommend how to include this in the source distribution for
> the final release?

Even though I was not asked, I still answer :-) I think having the
source code for the installer is essential, just so that people won't
get frightened by the potential for a Trojan Horse in front of the
gates (or, rather, the windows?-)

I'd put the installer (i.e. all of distutils/misc except for
get_metadata.py) into Tools/wininst.  (I'd actually preferred to see
the wininst sources in distutils in a different directory as well).

In case you need some descripting text as well, here's my proposal.
In Tools/README, maybe it would be

wininst    Sources for Windows installer of distutils.command.bdist_wininst.

For Tools/wininst/README, see the text below.

One complication is that invoking bdist_wininst as a program will
regenerate the module, but it expects the installer binary in
../../misc/wininst.exe; I'm not sure whether it is worth the effort to
change that for the Python distribution.

Regards,
Martin

THE WINDOWS INSTALLER
=====================

The distutils support the command bdist_wininst, which will produce a
windows auto-installing executable using the information in the setup
function. The executable consists of a user interface program,
concatenated with a zip archive of the distributed files. This
directory contains the sources of the user interface program. The
bdist_wininst command itself does not need the sources, instead, it
has an embedded copy of the installer binary file. If the installer
program is modified, bdist_wininst.py must be updated by invoking it
as a program (i.e. "python bdist_wininst.py")

Building the installer
----------------------

To build the installer, you need a copy of Microsoft Visual C++
version 6; the project file is wininst.dsp. You may also use the
executable compressor UPX, which is available from
http://upx.tsx.org. UPX must be installed into c:\util. Using UPX is
not strictly required - it just reduces the size of the installation
program itself.

Using the bdist_wininst command
-------------------------------
To create an binary distribution of your package for Windows, simply
invoke "python setup.py bdist_wininst" in your package directory. If
your package does not contain C modules, you may invoke this command
on any system; if it does contain C modules, bdist_wininst will need
the C compiler used to build Python (typically MSVC++). It will not
need MSVC++ or UPX to build the setup program.

To build the ZIP file contained in the installer, bdist_wininst will
first try an external zip program (zip.exe) that understands the -rq
option, such as Info-ZIP
(http://www.info-zip.org/pub/infozip/Zip.html). If no such program is
found, it will next try the zipfile module, which is available if
Python was build with zlib support.




From larsga at garshol.priv.no  Sun Oct 15 19:52:16 2000
From: larsga at garshol.priv.no (Lars Marius Garshol)
Date: 15 Oct 2000 19:52:16 +0200
Subject: [Python-Dev] Simple xml.sax example?
In-Reply-To: <14824.21089.373315.436615@cj42289-a.reston1.va.home.com>
References: <14823.43218.337621.157021@beluga.mojam.com> 	<m34s2fpvx3.fsf@lambda.garshol.priv.no> <14824.21089.373315.436615@cj42289-a.reston1.va.home.com>
Message-ID: <m3vguunga7.fsf@lambda.garshol.priv.no>

* Lars Marius Garshol
|
| Here are a couple from an internal seminar I recently gave on this.
| I could make the slides available as well, if there is interest.

* Fred L. Drake, Jr.
| 
| Could we include this in Demos/xml/ ?

Sure.  Do whatever you like with them.  

--Lars M.




From hinsen at cnrs-orleans.fr  Sun Oct 15 21:04:27 2000
From: hinsen at cnrs-orleans.fr (Konrad Hinsen)
Date: Sun, 15 Oct 2000 21:04:27 +0200
Subject: [Python-Dev] RE: [Numpy-discussion] RE: Possible bug (was Re: numpy, 
 overflow, inf, ieee, and rich comparison)
In-Reply-To: <39E7B554.29A168E3@jps.net> (message from Chris Barker on Fri, 13
	Oct 2000 18:22:28 -0700)
References: <LNBBLJKPBEHFEDALKOLCEEACHLAA.tim_one@email.msn.com> <39E7B554.29A168E3@jps.net>
Message-ID: <200010151904.VAA32561@chinon.cnrs-orleans.fr>

> I've come to Python from MATLAB for numerics, and I really appreciated
> MATLAB's way of handling all this. I don't think MATLAB has true 754

MATLAB is fine for simple interactive data processing, and its
behaviour is adapted to this task. I don't think anyone would use
MATLAB for developing complex algorithms, its programming language
isn't strong enough for that. Python is, so complex algorithms have to
be considered as well. And for that kind of application, continuing a
calculation with Infs and NaNs is a debugging nightmare.

> I have not yet heard a decent response to the question of what to do
> when a single value in a large array is bad, and causes an exception.

I'd like to have at least the option of raising an exception in that
case. Note that this is not what NumPy does today.

> >> sqrt(-1)
> ans =
>	   0 + 1.0000i
>
> Hey! I like that! Python is dynamic, why can't we just get the actual
> answer to sqrt(-1), without using cmath, that always returns a complex ?

For the same reason that makes 2/3 return zero instead of a float
division result. Like C or Fortran, Python treats integers, floats,
and complex numbers as different data types. And the return type of a
function should depend only on the types, but not the values, of its
parameters (for consistency, not because of any implementational
limitation). So sqrt(a) for a of type float can either always return a
float (math, Numeric) and crash for negative arguments, or always
return a complex (cmath).

The "right" solution, in my opinion, would be to have a single
"number" type of which integers, float, and complex numbers are simply
different internal representations. But such a change cannot be
introduced without breaking a lot of code.

Konrad.
--
-------------------------------------------------------------------------------
Konrad Hinsen                            | E-Mail: hinsen at cnrs-orleans.fr
Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24
Rue Charles Sadron                       | Fax:  +33-2.38.63.15.17
45071 Orleans Cedex 2                    | Deutsch/Esperanto/English/
France                                   | Nederlands/Francais
-------------------------------------------------------------------------------



From tim_one at email.msn.com  Sun Oct 15 21:22:09 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Sun, 15 Oct 2000 15:22:09 -0400
Subject: [Python-Dev] Python 2.0b2 note for Windows developers
In-Reply-To: <000001c03636$7f5b5600$060210ac@private>
Message-ID: <LNBBLJKPBEHFEDALKOLCCEFKHLAA.tim_one@email.msn.com>

[Tim]
> the files where you want them after unpacking.  What I upload
> will be an exact image of the build directory structure.  Most
> feedback I've gotten is that people want exactly that,
> because they *want* to compile Python

[Barry Scott]
> I'd not thought of that.

[Mark Hammond]
> My either.  I must admit mild surprise at that.

Not me, because this is the Python core:  extension writers often have
problems with their use of the Python C API, and the core is what supplies
that.  It's not surprising that they want to, e.g., drop some printfs into
Python itself to see what's going on.  Then they need to recompile Python.
Plus that all the examples and instructions for building extensions assume
you're working in a build-- not a release --tree.

> If people want the debug files in the same tree as the build tree,

Some people, not all; by my informal count so far, "most", but it's like 2
or 3 to 1 -- and that's not only a ratio but a grand-total count.

> it seems all they are trying to do is avoid the initial huge build.  If
> they intend compiling, why are they asking for the binaries?

The "huge initial build" is no more than a few minutes, *provided* that they
don't have to crawl over the web too to get source for, and figure out what
to do with, the subprojects w/ a 3rd-party component (_tkinter, bsddb,
pyexpat and zlib).  Dealing with the latter for the first time can consume
hours.

> My experience with people wanting debug binaries is that they either don't
> want to, or can not build.

If they can't build, it's hard to take their claim to be developing
extension modules seriously <wink>.

> ...
> For the last year or so, I have been making Debug builds of win32all
> available to registered users.  This has always been made available in
> the "install" structure - quite a bit different than the source/build
> structure.  I've never been asked for anything different.

Were you *asked* for even that much?  Barry's was the first request Guido
recalls ever getting.  It sounded reasonable to me to supply *something*, so
I did.  But the download stats for this zip file suggest it's not popular
enough to be worth  arguing over.  Still, I've gotten a little feedback on
it, and most people seem to be happy.  Not all developers want the same
thing, and a flat .zip file with no internal directory structure is
maximally flexible.

If a handful of other Windows developers pop up who swear they can't live
with a flat file, and can't bear to write a little Python or .bat script to
move the files to where they want them, and swear they want some directory
structure that's a fuzzy generalization of the Windows install structure,
and swear they all want the same fuzzy generalization (e.g., where do they
want the .pdb files?  there are none in the install tree now), then, sure,
I'll make the *other* peoples' lives a bit more difficult by default.  I'm
not going to ship two (or more!) of these things, though.

view-it-as-a-chance-for-activestate-to-take-over<wink>-ly y'rs  - tim





From tim_one at email.msn.com  Sun Oct 15 22:35:27 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Sun, 15 Oct 2000 16:35:27 -0400
Subject: [Python-Dev] RE: [Numpy-discussion] RE: Possible bug (was Re: numpy,  overflow, inf, ieee, and rich comparison)
In-Reply-To: <200010151904.VAA32561@chinon.cnrs-orleans.fr>
Message-ID: <LNBBLJKPBEHFEDALKOLCGEFLHLAA.tim_one@email.msn.com>

[cbarker at jps.net]
>> I've come to Python from MATLAB for numerics, and I really appreciated
>> MATLAB's way of handling all this. I don't think MATLAB has true 754 ...

[Konrad Hinsen]
> MATLAB is fine for simple interactive data processing, and its
> behaviour is adapted to this task. I don't think anyone would use
> MATLAB for developing complex algorithms, its programming language
> isn't strong enough for that. Python is, so complex algorithms have to
> be considered as well. And for that kind of application, continuing a
> calculation with Infs and NaNs is a debugging nightmare.

A non-constructive (because futile) speculation:  the first time I saw what
754 was intending to do, my immediate reaction was "hmm -- the exponent
field is too narrow!".  With a max (double) val in the ballpark of 1e300,
you get an infinity as soon as you square something as small as 1e150, and
once you get a few infinities, NaNs are sure to follow (due to Inf-Inf and
Inf/Inf).  The dynamic range for 754 singles is much smaller still.

There's no doubt about Cray arithmetic being hard to live with, but while
Mr. Cray didn't worry about proper rounding, he did devote 15 bits to Cray's
exponent field (vs. 11 for 754).  As a result, overflows were generally a
non-issue on Cray boxes, and *nobody* complained (in my decade there) about
Cray HW raising a fatal exception if one occurred.

In return, you got only 48 bits of precision (vs. 53 for 754).  But, for
most physical problems, how accurate are the inputs?  10 bits on a good day,
20 bits on a great day?  Crays worked despite their sloppy numerics because,
for most problems to which they were applied, they carried more than twice
the precision *and* dynamic range than the final results needed.

>> I have not yet heard a decent response to the question of what to do
>> when a single value in a large array is bad, and causes an exception.

I'd usually trace back and try to figure out how it got "bad" to begin with
...

> I'd like to have at least the option of raising an exception in that
> case. Note that this is not what NumPy does today.

Does NumPy use the fpectl module?  I suppose not.  LLNL contribued that
code, but we hear very little feedback on it.  It arranges to (in
platform-dependent ways) convert the 754 overflow, divide-by-0 and
invalid-operation signals into Python exceptions.  In core Python, this is
accomplished at the extraordinary expense of doing a setjmp before, and a
function call + double->int conversion after, every single fp operation.  A
chief problem is that SIGFPE is the only handle C gives us on fp "errors",
and the C std does not allow returning from a SIGFPE handler (the result of
trying to is undefined, and indeed varies wildly across platforms); so if
you want to regain control, you have to longjmp out of the handler.

The NumPy implementation could use the PyFPE_START_PROTECT and
PyFPE_END_PROTECT macros to brackete entire array operations, though, and so
pay for the setjmp etc only once per array op.  This is difficult stuff, but
doable.


>> >> sqrt(-1)
>> ans =
>>	   0 + 1.0000i
>>
>> Hey! I like that! Python is dynamic, why can't we just get the actual
>> answer to sqrt(-1), without using cmath, that always returns a complex ?

> For the same reason that makes 2/3 return zero instead of a float
> division result. Like C or Fortran, Python treats integers, floats,
> and complex numbers as different data types.

You know I'm in general agreement with you on this one, but I have to draw a
distinction here:  Guido thinks that 2/3 returning 0 was a design mistake,
but not that math.sqrt(-1) raising an exception is a mistake.  Most Python
users won't know what to do with a complex number, so it's "an error" to
them.  I would like to view this in P3K (if not earlier) as being akin to
754 exceptions:  some people are delighted to have 1e300**2 return +Inf,
while others want to see OverflowError instead, and still others want to see
+Inf *and* have a sticky flag set saying "an overflow occurred".  We could
treat f(x) (for f == sqrt and everything else) the same way wrt to a new
ComplexResultFromNonComplexInputsError:  define "non-stop" complex results,
let the user choose whether to do nonstop or raise an exception, and a
supply a sticky flag saying whether or not any complex results were
generated from non-complex inputs.

> ...
> The "right" solution, in my opinion, would be to have a single
> "number" type of which integers, float, and complex numbers are simply
> different internal representations. But such a change cannot be
> introduced without breaking a lot of code.

The current distinction between ints and longs (unbounded ints) should also
get swallowed by this.  A way to get from here to there is especially
irksome at the C API level, since, e.g., many C API functions pass Python
ints as C longs directly.  A smaller number pass Python floats as C doubles
directly.

it's-wonderful-that-p3k-will-solve-everything<wink>-ly y'rs  - tim





From MarkH at ActiveState.com  Mon Oct 16 01:49:19 2000
From: MarkH at ActiveState.com (Mark Hammond)
Date: Mon, 16 Oct 2000 10:49:19 +1100
Subject: [Python-Dev] Wierd buffer "add" behaviour.
Message-ID: <ECEPKNMJLHAPFFJHDOJBIEJMDNAA.MarkH@ActiveState.com>

I just struck this, and wonder if it is intentional:

* Adding 2 buffer objects together yields a string.  Fair enough.
* Adding a buffer and a string yields a type error!  Eeek.

This yields the following strange behaviour:

>>> a=buffer('a')
>>> a+a
'aa'
>>> a+a+a
Traceback (innermost last):
  File "<interactive input>", line 1, in ?
TypeError: cannot add type "buffer" to string
>>> 

That doesnt seem correct to me?

Mark.



From rob at hooft.net  Mon Oct 16 07:39:13 2000
From: rob at hooft.net (Rob W. W. Hooft)
Date: Mon, 16 Oct 2000 07:39:13 +0200 (CEST)
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib calendar.py,1.17,1.18
In-Reply-To: <200010091242.FAA02671@slayer.i.sourceforge.net>
References: <200010091242.FAA02671@slayer.i.sourceforge.net>
Message-ID: <14826.38017.352907.716552@temoleh.chem.uu.nl>

Just checking my E-mail coming back from holidays, I see:

  diff -C2 -r1.17 -r1.18
  *** calendar.py 2000/08/30 14:01:28     1.17
  --- calendar.py 2000/10/09 12:42:04     1.18
  ***************
  *** 55,60 ****
    def leapdays(y1, y2):
        """Return number of leap years in range [y1, y2).
  !        Assume y1 <= y2 and no funny (non-leap century) years."""
  !     return (y2+3)/4 - (y1+3)/4

    def weekday(year, month, day):
  --- 55,62 ----
    def leapdays(y1, y2):
        """Return number of leap years in range [y1, y2).
  !        Assume y1 <= y2."""
  !     y1 -= 1
  !     y2 -= 1
  !     return (y2/4 - y1/4) - (y2/100 - y1/100) + (y2/400 - y1/400)

    def weekday(year, month, day):

I am worried about the use of "-=" here. The code basically says: "if the
arguments are mutable numeric types, I'd like to modify them in place". In
c.l.py it has been stressed multiple times that "-=" is not the same as
"=   -". I think this is clearly a place where "=   -" is preferable over
"-=". Even though you might think people will always call this with 
python integers, you can never be sure enough.

Rob

-- 
=====   rob at hooft.net          http://www.hooft.net/people/rob/  =====
=====   R&D, Nonius BV, Delft  http://www.nonius.nl/             =====
===== PGPid 0xFA19277D ========================== Use Linux! =========



From pf at artcom-gmbh.de  Mon Oct 16 09:23:11 2000
From: pf at artcom-gmbh.de (Peter Funk)
Date: Mon, 16 Oct 2000 09:23:11 +0200 (MEST)
Subject: [Python-Dev] gettext may fail to find .mo file (was Re: [PATCH] gettext)
In-Reply-To: <lblmvq8czj.fsf@mask.tf.hut.fi>
Message-ID: <m13l4c3-000Dm8C@artcom0.artcom-gmbh.de>

Hi Ulf,

Ulf Betlehem:
[...]
>         ok, I compiled 2.0c1 and tried gettext. Now, there seems to be
>         a bug in the "normalize and expand" code that can prevent
>         gettext from finding an existing .mo file. The normalization
>         is done using a dictionary and therefore the languages get
>         reordered (as dict keys do). Later when selecting language the
>         function returns None if 'C' happens to come before the
>         required languages. I've included a patch to fix this.

Your patch looks good to me.  Thanks for taking the time to test and 
contributing the patch.  I've submitted your bug report and your 
patch to sourceforge.

See:
https://sourceforge.net/bugs/?func=detailbug&bug_id=116964&group_id=5470
https://sourceforge.net/patch/?func=detailpatch&patch_id=101928&group_id=5470

Regards, Peter
P.S.: Cc to python-dev
-- 
Peter Funk, Oldenburger Str.86, D-27777 Ganderkesee, Germany, Fax:+49 4222950260
office: +49 421 20419-0 (ArtCom GmbH, Grazer Str.8, D-28359 Bremen)



From mal at lemburg.com  Mon Oct 16 09:50:22 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Mon, 16 Oct 2000 09:50:22 +0200
Subject: [Python-Dev] Wierd buffer "add" behaviour.
References: <ECEPKNMJLHAPFFJHDOJBIEJMDNAA.MarkH@ActiveState.com>
Message-ID: <39EAB33E.35B72EA4@lemburg.com>

Mark Hammond wrote:
> 
> I just struck this, and wonder if it is intentional:
> 
> * Adding 2 buffer objects together yields a string.  Fair enough.
> * Adding a buffer and a string yields a type error!  Eeek.

This just seems plain wrong. Adding two buffers should yield
a new buffer -- in the long run, buffers should replace strings
wrt to holding binary data. If not even buffers themselves
implement this idea, I don't see any perspective for ever getting
there...
 
> This yields the following strange behaviour:
> 
> >>> a=buffer('a')
> >>> a+a
> 'aa'
> >>> a+a+a
> Traceback (innermost last):
>   File "<interactive input>", line 1, in ?
> TypeError: cannot add type "buffer" to string
> >>>
> 
> That doesnt seem correct to me?

Neither to me.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From thomas.heller at ion-tof.com  Mon Oct 16 11:14:49 2000
From: thomas.heller at ion-tof.com (Thomas Heller)
Date: Mon, 16 Oct 2000 11:14:49 +0200
Subject: [Python-Dev] Wierd buffer "add" behaviour.
References: <ECEPKNMJLHAPFFJHDOJBIEJMDNAA.MarkH@ActiveState.com>
Message-ID: <037601c03751$88ecc1b0$e000a8c0@thomasnotebook>

IMHO, the whole buffer interface is weird.

- Only the Buffer_FromObject() function is exposed to the python
level (as buffer()), the other functions are missing. This
means that one could only use the buffer interface in
extension modules. Was this intentional?

- No way a python class can expose the buffer interface

- There is a bug in the buffer interface (which
prevented recently that I could use buffer objects
at all, I had to implement my own)

PyObject *base = PyBuffer_New(100);
PyObject *buffer = PyBuffer_FromObject(base, 0, 100);
Py_DECREF(base);

After this code is executed,
buffer points to deallocated memory (because
buffer does not hold a reference to base anymore).

(Guido classified this as a wish, but at least
it contradicts the documentation)

Thomas




From MarkH at ActiveState.com  Mon Oct 16 11:38:26 2000
From: MarkH at ActiveState.com (Mark Hammond)
Date: Mon, 16 Oct 2000 20:38:26 +1100
Subject: [Python-Dev] Wierd buffer "add" behaviour.
In-Reply-To: <037601c03751$88ecc1b0$e000a8c0@thomasnotebook>
Message-ID: <ECEPKNMJLHAPFFJHDOJBMEKHDNAA.MarkH@ActiveState.com>

> IMHO, the whole buffer interface is weird.

I'm not sure that weird is the correct term for your points (it is for my
spelling, though :-)

> - Only the Buffer_FromObject() function is exposed to the
...
> - No way a python class can expose the buffer interface

These are simply oversights, I would suggest.  Nothing in the design
prevents this.

> - There is a bug in the buffer interface (which
> prevented recently that I could use buffer objects
> at all, I had to implement my own)

This looks like quite a simple bug.  bufferobject.c, line 77:

	/* if the base object is another buffer, then "deref" it */
	if ( PyBuffer_Check(base) )
		base = ((PyBufferObject *)base)->b_base;

if the condition was changed to:

	if ( PyBuffer_Check(base) && ((PyBufferObject *)base)->b_base)

Then I think this one would be solved?

A more serious design flaw is the one Fredrik pointed out quite some time
ago.  If you have (eg.) an "array" object and query for its buffer, life is
good.  If the array then resizes itself, your pointer is now dangling.  The
simplest solution to this is probably to simply define the lifetimes of
these pointers as very very short ;-)

Mark.




From mal at lemburg.com  Mon Oct 16 12:14:46 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Mon, 16 Oct 2000 12:14:46 +0200
Subject: [Python-Dev] Wierd buffer "add" behaviour.
References: <ECEPKNMJLHAPFFJHDOJBMEKHDNAA.MarkH@ActiveState.com>
Message-ID: <39EAD516.7EA34C20@lemburg.com>

Mark Hammond wrote:
> [Problems with the buffer interface]
> If you have (eg.) an "array" object and query for its buffer, life is
> good.  If the array then resizes itself, your pointer is now dangling.  The
> simplest solution to this is probably to simply define the lifetimes of
> these pointers as very very short ;-)

...or disable the buffer interface for mutable types altogether !

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From gstein at lyra.org  Mon Oct 16 15:01:26 2000
From: gstein at lyra.org (Greg Stein)
Date: Mon, 16 Oct 2000 06:01:26 -0700
Subject: [Python-Dev] Wierd buffer "add" behaviour.
In-Reply-To: <39EAB33E.35B72EA4@lemburg.com>; from mal@lemburg.com on Mon, Oct 16, 2000 at 09:50:22AM +0200
References: <ECEPKNMJLHAPFFJHDOJBIEJMDNAA.MarkH@ActiveState.com> <39EAB33E.35B72EA4@lemburg.com>
Message-ID: <20001016060126.X347@lyra.org>

On Mon, Oct 16, 2000 at 09:50:22AM +0200, M.-A. Lemburg wrote:
> Mark Hammond wrote:
>...
> > This yields the following strange behaviour:
> > 
> > >>> a=buffer('a')
> > >>> a+a
> > 'aa'
> > >>> a+a+a
> > Traceback (innermost last):
> >   File "<interactive input>", line 1, in ?
> > TypeError: cannot add type "buffer" to string
> > >>>
> > 
> > That doesnt seem correct to me?
> 
> Neither to me.

It is caused by the non-commutative aspect of Python types. You end up with
a string, and that type doesn't know how to add a buffer to itself.

Ideally, it might be nice to allow a string to append any object that
exports the buffer-interface. But when somebody goes and writes
"abc"+my_array ... hoo boy, will we hear complaints.

The alternative is to allow the buffer to resolve the type conflict and do
the appending within the buffer code.

Of course, the choice of returning a string (from buf+buf) rather than a
buffer was arguably the wrong choice.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/



From guido at python.org  Mon Oct 16 16:30:44 2000
From: guido at python.org (Guido van Rossum)
Date: Mon, 16 Oct 2000 09:30:44 -0500
Subject: [Python-Dev] mutable integers
In-Reply-To: Your message of "Mon, 16 Oct 2000 07:39:13 +0200."
             <14826.38017.352907.716552@temoleh.chem.uu.nl> 
References: <200010091242.FAA02671@slayer.i.sourceforge.net>  
            <14826.38017.352907.716552@temoleh.chem.uu.nl> 
Message-ID: <200010161430.JAA28885@cj20424-a.reston1.va.home.com>

Rob W. W. Hooft:

> Just checking my E-mail coming back from holidays, I see:
[...]
>     def leapdays(y1, y2):
>         """Return number of leap years in range [y1, y2).
>   !        Assume y1 <= y2."""
>   !     y1 -= 1
>   !     y2 -= 1
>   !     return (y2/4 - y1/4) - (y2/100 - y1/100) + (y2/400 - y1/400)
> 
> I am worried about the use of "-=" here. The code basically says: "if the
> arguments are mutable numeric types, I'd like to modify them in place". In
> c.l.py it has been stressed multiple times that "-=" is not the same as
> "=   -". I think this is clearly a place where "=   -" is preferable over
> "-=". Even though you might think people will always call this with 
> python integers, you can never be sure enough.

Hmm...  Your fear sounds a little paranoid for this particular case,
but I can't say that I totally disagree in general.  This is
definitely something to keep in mind when writing polymorphic
functions for which a NumPy array might be an acceptable input
argument.

I don't think it's worth checking in a patch in this case.

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



From hinsen at cnrs-orleans.fr  Mon Oct 16 17:52:43 2000
From: hinsen at cnrs-orleans.fr (Konrad Hinsen)
Date: Mon, 16 Oct 2000 17:52:43 +0200
Subject: [Python-Dev] RE: [Numpy-discussion] RE: Possible bug (was Re: numpy,  overflow, inf, ieee, and rich comparison)
In-Reply-To: <LNBBLJKPBEHFEDALKOLCGEFLHLAA.tim_one@email.msn.com>
References: <LNBBLJKPBEHFEDALKOLCGEFLHLAA.tim_one@email.msn.com>
Message-ID: <200010161552.RAA02685@chinon.cnrs-orleans.fr>

> > I'd like to have at least the option of raising an exception in that
> > case. Note that this is not what NumPy does today.
> 
> Does NumPy use the fpectl module?  I suppose not.  LLNL contribued that

No. Perhaps it should, but it doesn't make sense unless fpectl works
on a large number of platforms. I confess I have never looked at it. I
want my code to be portable, so I don't even consider using packages
that aren't.

> > For the same reason that makes 2/3 return zero instead of a float
> > division result. Like C or Fortran, Python treats integers, floats,
> > and complex numbers as different data types.
> 
> You know I'm in general agreement with you on this one, but I have to draw a
> distinction here:  Guido thinks that 2/3 returning 0 was a design mistake,
> but not that math.sqrt(-1) raising an exception is a mistake.  Most Python
> users won't know what to do with a complex number, so it's "an error" to
> them.

Well, that would be a good occasion to learn about complex numbers! I
remember having learned about generalized inverses by using APL in
high school (in a very similar way: I was amazed that it could invert
non-square matrices), and that turned out to be very useful knowledge
later on. Perhaps that's a topic for the EDU-SIG...

Anyway, I don't care what math.sqrt(-1) does, but I would definitely
prefer Numeric.sqrt(-1) to return a complex result. And I think that
someone who uses NumPy has probably heard about complex numbers.


> I would like to view this in P3K (if not earlier) as being akin to
> 754 exceptions:  some people are delighted to have 1e300**2 return +Inf,
> while others want to see OverflowError instead, and still others want to see
> +Inf *and* have a sticky flag set saying "an overflow occurred".  We could
> treat f(x) (for f == sqrt and everything else) the same way wrt to a new
> ComplexResultFromNonComplexInputsError:  define "non-stop" complex results,
> let the user choose whether to do nonstop or raise an exception, and a
> supply a sticky flag saying whether or not any complex results were
> generated from non-complex inputs.

There is, however, one difference: in properly debugged production
code, there should be no overflow situations, so it doesn't matter
much how they are treated. Complex number can (do!) occur in
production code, but there could also be production code relying on
exceptions for sqrt(-1) (e.g. for input error checking). Therefore a
program using several libraries might be impossible to run with either
setting.

Since this concerns only the math module, I'd prefer to keep separate
module versions for the two cases, which can be used in parallel.

> > The "right" solution, in my opinion, would be to have a single
> > "number" type of which integers, float, and complex numbers are simply
> > different internal representations. But such a change cannot be
> > introduced without breaking a lot of code.
> 
> The current distinction between ints and longs (unbounded ints) should also
> get swallowed by this.  A way to get from here to there is especially
> irksome at the C API level, since, e.g., many C API functions pass Python
> ints as C longs directly.  A smaller number pass Python floats as C doubles
> directly.

I don't see the problem in that direction, it's rather C API functions
that *return* numbers in C data types that would be difficult to
adapt. But then, why should be C API not be allowed in P3K?

it's-wonderful-that-anything-may-be-changed-in-p3k'ly
  Konrad.
-- 
-------------------------------------------------------------------------------
Konrad Hinsen                            | E-Mail: hinsen at cnrs-orleans.fr
Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24
Rue Charles Sadron                       | Fax:  +33-2.38.63.15.17
45071 Orleans Cedex 2                    | Deutsch/Esperanto/English/
France                                   | Nederlands/Francais
-------------------------------------------------------------------------------



From guido at python.org  Mon Oct 16 20:08:07 2000
From: guido at python.org (Guido van Rossum)
Date: Mon, 16 Oct 2000 13:08:07 -0500
Subject: [Python-Dev] The buffer interface
In-Reply-To: Your message of "Mon, 16 Oct 2000 06:01:26 MST."
             <20001016060126.X347@lyra.org> 
References: <ECEPKNMJLHAPFFJHDOJBIEJMDNAA.MarkH@ActiveState.com> <39EAB33E.35B72EA4@lemburg.com>  
            <20001016060126.X347@lyra.org> 
Message-ID: <200010161808.NAA32318@cj20424-a.reston1.va.home.com>

The buffer interface is one of the most misunderstood parts of
Python.  I believe that if it were PEPped today, it would have a hard
time getting accepted in its current form.

There are also two different parts that are commonly referred by this
name: the "buffer API", which is a C-only API, and the "buffer
object", which has both a C API and a Python API.

Both were largely proposed, implemented and extended by others, and I
have to admit that I'm still uneasy with defending them, especially
the buffer object.  Both are extremely implementation-dependent (in
JPython, neither makes much sense).

The Buffer API
--------------

The C-only buffer API was originally intended to allow efficient
binary I/O from and (in some cases) to large objects that have a
relatively well-understood underlying memory representation.  Examples
of such objects include strings, array module arrays, memory-mapped
files, NumPy arrays, and PIL objects.

It was created with the desire to avoid an expensive memory-copy
operation when reading or writing large arrays.  For example, if you
have an array object containing several millions of double precision
floating point numbers, and you want to dump it to a file, you might
prefer to do the I/O directly from the array's memory buffer rather
than first copying it to a string.  (You lose portability of the data,
but that's often not a problem the user cares about in these cases.)

An alternative solution for this particular problem was consdered:
object types in need of this kind of efficient I/O could define their
own I/O methods, thereby allowing them to hide their internal
representation.  This was implemented in some cases (e.g. the array
module has read() and write() methods) but rejected, because a
simple-minded implementation of this approach would not work with
"file-like" objects (e.g. StringIO files).  It was deemed important
that file-like objects would not place restrictions on the kind of
objects that could interact with them (compared to real file objects).

A possible solution would have been to require that each object
implementing its own read and write methods should support both
efficient I/O to/from "real" file objects and fall-back I/O to/from
"file-like" objects.  The fall-back I/O would have to convert the
object's data to a string object which would then be passed to the
write() method of the file-like object.  This approach was rejected
because it would make it impossible to implement an alternative file
object that would be as efficient as the real file object, since large
object I/O would be using the inefficient fallback interface.

To address these issues, we decided to define an interface that would
let I/O operations ask the objects where their data bytes are in
memory, so that the I/O can go directly to/from the memory allocated
by the object.  This is the classic buffer API.  It has a read-only
and a writable variant -- the writable variant is for mutable objects
that will allow I/O directly into them.  Because we expected that some
objects might have an internal representation distributed over a
(small) number of separately allocated pieces of memory, we also added
the getsegcount() API.  All objects that I know support the buffer API
return a segment count of 1, and most places that use the buffer API
give up if the segment count is larger; so this may be considered as
an unnecessary generalization (and source of complexity).

The buffer API has found significant use in a way that wasn't
originally intended: as a sort of informal common base class for
string-like objects in situations where a char[] or char* type must be
passed (in a read-only fashion) to C code.  This is in fact the most
common use of the buffer API now, and appears to be the reason why the
segment count must typically be 1.

In connection with this, the buffer API has grown a distinction
between character and binary buffers (on the read-only end only).
This may have been a mistake; it was intended to help with Unicode but
it ended up not being used.

The Buffer Object
-----------------

The buffer object has a much less clear reason for its existence.
When Greg Stein first proposed it, he wrote:

    The intent of this type is to expose a string-like interface from
    an object that supports the buffer interface (without making a
    copy). In addition, it is intended to support slices of the target
    object.

    My eventual goal here is to tweak the file object to support
    memory mapping and the buffer interface. The buffer object can
    then return slices of the file without making a new copy. Next
    step: change marshal.c, ceval.c, and compile.c to support a buffer
    for the co_code attribute. Net result is that copies of code
    streams don't need to be copied onto the heap, but can be left in
    an mmap'd file or a frozen file. I'm hoping there will be some
    perf gains (time and memory).

    Even without some of the co_code work, enabling mmap'd files and
    buffers onto them should be very useful. I can probably rattle off
    a good number of other uses for the buffer type.

I don't think that any of these benefits have been realized yet, and
altogether I think that the buffer object causes a lot of confusion.
The buffer *API* doesn't guarantee enough about the lifetime of the
pointers for the buffer *object* to be able to safely preserve those
pointers, even if the buffer object holds on to the base object.  (The
C-level buffer API informally guarantees that the data remains valid
only until you do anything to the base object; this is usually fine as
long as you don't release the global interpreter lock.)

The buffer object's approach to implementing the various sequence
operations is strange: sometimes it behaves like a string, sometimes
it doesn't.  E.g. a slice returns a new string object unless it
happens to address the whole buffer, in which case it returns a
reference to the existing buffer object.  It would seem more logical
that a subslice would return a new buffer object.  Concatenation and
repetition of buffer objects are likewise implemented inconsistently;
it would have been more consistent with the intended purpose if these
weren't supported at all (i.e. if none of the buffer object operations
would allocate new memory except for buffer object headers).

I would have concluded that the buffer object is entirely useless, if
it weren't for some very light use that is being made of it by the
Unicode machinery.  I can't quite tell whether that was done just
because it was convenient, or whether that shows there is a real
need.

What Now?
---------

I'm not convinced that we need the buffer object at all.  For example,
the mmap module defines a sequence object so doesn't seem to need the
buffer object to help it support slices.

Regarding the buffer API, it's clearly useful, although I'm not
convinced that it needs the multiple segment count option or the char
vs. binary buffer distinction, given that we're not using this for
Unicode objects as we originally planned.

I also feel that it would be helpful if there was an explicit way to
lock and unlock the data, so that a file object can release the global
interpreter lock while it is doing the I/O.  But that's not a high
priority (and there are no *actual* problems caused by the lack of
such an API -- just *theoretical*).

For Python 3000, I think I'd like to rethink this whole mess.  Perhaps
byte buffers and character strings should be different beasts, and
maybe character strings could have Unicode and 8-bit subclasses (and
maybe other subclasses that explicitly know about their encoding).
And maybe we'd have a real file base class.  And so on.

What to do in the short run?  I'm still for severely simplifing the
buffer object (ripping out the unused operations) and deprecating it.

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



From cbarker at jps.net  Mon Oct 16 19:38:11 2000
From: cbarker at jps.net (Chris Barker)
Date: Mon, 16 Oct 2000 10:38:11 -0700
Subject: [Python-Dev] Re: numpy,  overflow, inf, ieee, and rich comparison
References: <LNBBLJKPBEHFEDALKOLCGEFLHLAA.tim_one@email.msn.com>
Message-ID: <39EB3D03.A00C78B6@jps.net>


> >> I have not yet heard a decent response to the question of what to do
> >> when a single value in a large array is bad, and causes an exception.
> 
> I'd usually trace back and try to figure out how it got "bad" to begin with

And from Konrad Hinsen
>I'd like to have at least the option of raising an exception in that
>case. Note that this is not what NumPy does today.

Exactly. This was Huaiyu's point. The problem is that for your code to
be usable for folks other than yourself, you'd have to have a lot of
checks in there, and essentially revert to elementwise code, which would
kill you. With the addition of the occasional "isnan" and something like
Matlab's "any" ( "any(isnan(A))" returns true if any of the elements of
A are NaNs) you could set up your code to raise an exception in the
middle of computation. If, on the other hand the Code definiately raises
an exception, than you are stuck with a lot of elementwise coding.

> over/under-flows in IDL are reported but do 
> not stop execution.  This is the best (only) possible scenario for an 
> interactive arrays and visualization environment.

Exactly!!! ("the best (only) possible scenario" part)
 
> IDL> print, 54/0
>       54
> % Program caused arithmetic error: Integer divide by 0

This, however, is wierd!!  54/0 == 54 ??? I'd much rather see a NaN or
Inf here!

> MATLAB is fine for simple interactive data processing, and its
> behaviour is adapted to this task. I don't think anyone would use
> MATLAB for developing complex algorithms, its programming language
> isn't strong enough for that. Python is, so complex algorithms have to
> be considered as well. And for that kind of application, continuing a
> calculation with Infs and NaNs is a debugging nightmare.

People do some pretty complex algorith develpment with MATLAB. I'm also
no so sure about "continuing a calculation with Infs and NaNs is a
debugging nightmare" I'm don't think it's any more of a nighmare than
having your calculation on an entire array stop because of one Inf. It's
just a different trade off. Sprinkle a few "isnan"'s in there and and
you can get the behaviour you want, while not forcing it on all
calculations. Of course, the best option is to have it switchable, but
that may prove to be very difficult.

Are people doing the kind of numeric programming with "complex
algorithms" using Python that Konrad refers to? More importantly, how
many people?

>  Guido thinks that 2/3 returning 0 was a design mistake,
> but not that math.sqrt(-1) raising an exception is a mistake.  Most Python
> users won't know what to do with a complex number, so it's "an error" to
> them.

Guido's philosophy is clearly that Python defaults should be geared to
"Most Python users". I agree, and as I wrote in an earlier post, the
only users for whom the "exception raising only" option is best are the
users Konrad refers to as writing "complex algorithms". I would argue
that those users are few, and the group most able to deal with a
less-that-optimum system.

Maybe we can have true 754 compliance in Py3k, and we can all be happy!!

-Chris





-- 
Christopher Barker,
Ph.D.                                                           
cbarker at jps.net                      ---           ---           ---
http://www.jps.net/cbarker          -----@@       -----@@       -----@@
                                   ------@@@     ------@@@     ------@@@
Water Resources Engineering       ------   @    ------   @   ------   @
Coastal and Fluvial Hydrodynamics -------      ---------     --------    
------------------------------------------------------------------------
------------------------------------------------------------------------



From effbot at telia.com  Mon Oct 16 19:47:55 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Mon, 16 Oct 2000 19:47:55 +0200
Subject: [Python-Dev] The buffer interface
References: <ECEPKNMJLHAPFFJHDOJBIEJMDNAA.MarkH@ActiveState.com> <39EAB33E.35B72EA4@lemburg.com>             <20001016060126.X347@lyra.org>  <200010161808.NAA32318@cj20424-a.reston1.va.home.com>
Message-ID: <00f601c03799$39f2c7b0$3c6340d5@hagrid>

guido wrote:
> What to do in the short run?  I'm still for severely simplifing the
> buffer object (ripping out the unused operations) and deprecating it.

agreed.

(does this mean that we're in post-2.0 mode? ;-)

</F>




From mal at lemburg.com  Mon Oct 16 19:42:15 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Mon, 16 Oct 2000 19:42:15 +0200
Subject: [Python-Dev] Wierd buffer "add" behaviour.
References: <ECEPKNMJLHAPFFJHDOJBIEJMDNAA.MarkH@ActiveState.com> <39EAB33E.35B72EA4@lemburg.com> <20001016060126.X347@lyra.org>
Message-ID: <39EB3DF7.459A1BC1@lemburg.com>

Greg Stein wrote:
> 
> On Mon, Oct 16, 2000 at 09:50:22AM +0200, M.-A. Lemburg wrote:
> > Mark Hammond wrote:
> >...
> > > This yields the following strange behaviour:
> > >
> > > >>> a=buffer('a')
> > > >>> a+a
> > > 'aa'
> > > >>> a+a+a
> > > Traceback (innermost last):
> > >   File "<interactive input>", line 1, in ?
> > > TypeError: cannot add type "buffer" to string
> > > >>>
> > >
> > > That doesnt seem correct to me?
> >
> > Neither to me.
> 
> It is caused by the non-commutative aspect of Python types. You end up with
> a string, and that type doesn't know how to add a buffer to itself.

The problem is that buffer() objects coerce to strings in the
first place... they should return new buffer objects instead
of strings -- then we wouldn't have the above problems.
 
> ... 
> Of course, the choice of returning a string (from buf+buf) rather than a
> buffer was arguably the wrong choice.

Right :-/

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From guido at python.org  Mon Oct 16 20:51:51 2000
From: guido at python.org (Guido van Rossum)
Date: Mon, 16 Oct 2000 13:51:51 -0500
Subject: [Python-Dev] The buffer interface
In-Reply-To: Your message of "Mon, 16 Oct 2000 19:47:55 +0200."
             <00f601c03799$39f2c7b0$3c6340d5@hagrid> 
References: <ECEPKNMJLHAPFFJHDOJBIEJMDNAA.MarkH@ActiveState.com> <39EAB33E.35B72EA4@lemburg.com> <20001016060126.X347@lyra.org> <200010161808.NAA32318@cj20424-a.reston1.va.home.com>  
            <00f601c03799$39f2c7b0$3c6340d5@hagrid> 
Message-ID: <200010161851.NAA32597@cj20424-a.reston1.va.home.com>

> guido wrote:
> > What to do in the short run?  I'm still for severely simplifing the
> > buffer object (ripping out the unused operations) and deprecating it.
> 
> agreed.
> 
> (does this mean that we're in post-2.0 mode? ;-)

Yes :-)

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



From mal at lemburg.com  Mon Oct 16 20:03:15 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Mon, 16 Oct 2000 20:03:15 +0200
Subject: [Python-Dev] The buffer interface
References: <ECEPKNMJLHAPFFJHDOJBIEJMDNAA.MarkH@ActiveState.com> <39EAB33E.35B72EA4@lemburg.com>  
	            <20001016060126.X347@lyra.org> <200010161808.NAA32318@cj20424-a.reston1.va.home.com>
Message-ID: <39EB42E3.B76F37EB@lemburg.com>

Guido van Rossum wrote:
> ...
> I would have concluded that the buffer object is entirely useless, if
> it weren't for some very light use that is being made of it by the
> Unicode machinery.  I can't quite tell whether that was done just
> because it was convenient, or whether that shows there is a real
> need.

I used the buffer object since I thought that buffer() objects
were to replace strings as container for binary data. The buffer
object wraps a memory buffer into a Python object for the purpose
of decoding it into Unicode. 8-bit string objects would have worked
just as well...
 
> What Now?
> ---------
> 
> I'm not convinced that we need the buffer object at all.  For example,
> the mmap module defines a sequence object so doesn't seem to need the
> buffer object to help it support slices.

It would be nice to have an object for "copy by reference" rather
than "malloc + copy". This would be useful for strings (e.g. to
access substrings of a large string), Unicode and binary
data. The buffer object almost does this... it would only have
to stick to always returning buffer objects in coercion, slicing
etc. I also think that the name "buffer" is misleading, since it
really means "reference" in the context published by the Python
interface (the C API also has a way of defining new malloc areas
and referencing them through the buffer interface, but that is
not published in Python).

The other missing data type in Python is one for binary data.
Currently, string objects are in common use for this kind of
data. The problems with this are obvious: in some contexts strings
are expected to contain text data in other binary data. When the
two meet there's great confusion. I'd suggest either making
arrays the Python standard type for holding binary data, or
creating a completely new type (this should then be called
something like "buffer").

> Regarding the buffer API, it's clearly useful, although I'm not
> convinced that it needs the multiple segment count option or the char
> vs. binary buffer distinction, given that we're not using this for
> Unicode objects as we originally planned.

True.
 
> I also feel that it would be helpful if there was an explicit way to
> lock and unlock the data, so that a file object can release the global
> interpreter lock while it is doing the I/O.  But that's not a high
> priority (and there are no *actual* problems caused by the lack of
> such an API -- just *theoretical*).

How about adding a generic low-level lock type for these kind
of tasks. The interpreter could be made aware of these types
to allow a much more fine-grained lock mechanism, e.g. to check
for acquired locks of certain objects only.
 
> For Python 3000, I think I'd like to rethink this whole mess.  Perhaps
> byte buffers and character strings should be different beasts, and
> maybe character strings could have Unicode and 8-bit subclasses (and
> maybe other subclasses that explicitly know about their encoding).
> And maybe we'd have a real file base class.  And so on.

Great... but 3000 is a long way ahead :-(
 
> What to do in the short run?  I'm still for severely simplifing the
> buffer object (ripping out the unused operations) and deprecating it.

Since it isn't all that known anyway, how about streamlining
the buffer object implementations of the various protocols and
removing the distinction between "s" and "t" ?!

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From jcollins at endtech.com  Mon Oct 16 22:22:22 2000
From: jcollins at endtech.com (Jeff Collins)
Date: Mon, 16 Oct 2000 13:22:22 -0700 (PDT)
Subject: [Python-Dev] The buffer interface
In-Reply-To: <200010161808.NAA32318@cj20424-a.reston1.va.home.com>
Message-ID: <Pine.LNX.4.21.0010161135470.15198-100000@localhost.localdomain>

All this just when I was getting accustomed to the thought of using buffer
objects in the Palm Python port...

I need buffer objects for many the same reasons as Greg Stein originally
proposed, as you quoted below.  The on the Palm, the datamanager heap
(used for permanent database storage and limited by the physical memory
size) already stores the compiled python module.  Directly referencing the
data of objects like bytecodes and strings would greatly reduce the
dynamic heap (current limit of 256K on PalmOS 3.5 on devices with 4M RAM
or greater) requirements.

Buffer objects seem like a natural choice.  A record in a Palm database is
just chunk of contiguous memory.  Representing this chunk as a buffer
object would allow the direct referencing it and any of it's slices.  So,
the co_code of code objects could be unmarshalled with a reference to
permanent storage.  Further, with the appropriate modifications, string
objects (char *ob_sval?) could access this memory as well, though this
additional optimization is probably only appropriate for small platforms.

I think that buffer object is fairly important.  They provide a mechanism
for exposing arbitrary chunks of memory (eg, PyBuffer_FromMemory),
something that no other python object does, AFIAK.  Perhaps clarifying the
interface (such as the slice operator returning a buffer, as suggested
below) and providing more hooks from Python for creating buffers (via
newmodule, say) would be helpful.



On Mon, 16 Oct 2000, Guido van Rossum wrote:

> The buffer interface is one of the most misunderstood parts of
> Python.  I believe that if it were PEPped today, it would have a hard
> time getting accepted in its current form.
> 
> There are also two different parts that are commonly referred by this
> name: the "buffer API", which is a C-only API, and the "buffer
> object", which has both a C API and a Python API.
> 
> Both were largely proposed, implemented and extended by others, and I
> have to admit that I'm still uneasy with defending them, especially
> the buffer object.  Both are extremely implementation-dependent (in
> JPython, neither makes much sense).
> 
> The Buffer API
> --------------
> 
> The C-only buffer API was originally intended to allow efficient
> binary I/O from and (in some cases) to large objects that have a
> relatively well-understood underlying memory representation.  Examples
> of such objects include strings, array module arrays, memory-mapped
> files, NumPy arrays, and PIL objects.
> 
> It was created with the desire to avoid an expensive memory-copy
> operation when reading or writing large arrays.  For example, if you
> have an array object containing several millions of double precision
> floating point numbers, and you want to dump it to a file, you might
> prefer to do the I/O directly from the array's memory buffer rather
> than first copying it to a string.  (You lose portability of the data,
> but that's often not a problem the user cares about in these cases.)
> 
> An alternative solution for this particular problem was consdered:
> object types in need of this kind of efficient I/O could define their
> own I/O methods, thereby allowing them to hide their internal
> representation.  This was implemented in some cases (e.g. the array
> module has read() and write() methods) but rejected, because a
> simple-minded implementation of this approach would not work with
> "file-like" objects (e.g. StringIO files).  It was deemed important
> that file-like objects would not place restrictions on the kind of
> objects that could interact with them (compared to real file objects).
> 
> A possible solution would have been to require that each object
> implementing its own read and write methods should support both
> efficient I/O to/from "real" file objects and fall-back I/O to/from
> "file-like" objects.  The fall-back I/O would have to convert the
> object's data to a string object which would then be passed to the
> write() method of the file-like object.  This approach was rejected
> because it would make it impossible to implement an alternative file
> object that would be as efficient as the real file object, since large
> object I/O would be using the inefficient fallback interface.
> 
> To address these issues, we decided to define an interface that would
> let I/O operations ask the objects where their data bytes are in
> memory, so that the I/O can go directly to/from the memory allocated
> by the object.  This is the classic buffer API.  It has a read-only
> and a writable variant -- the writable variant is for mutable objects
> that will allow I/O directly into them.  Because we expected that some
> objects might have an internal representation distributed over a
> (small) number of separately allocated pieces of memory, we also added
> the getsegcount() API.  All objects that I know support the buffer API
> return a segment count of 1, and most places that use the buffer API
> give up if the segment count is larger; so this may be considered as
> an unnecessary generalization (and source of complexity).
> 
> The buffer API has found significant use in a way that wasn't
> originally intended: as a sort of informal common base class for
> string-like objects in situations where a char[] or char* type must be
> passed (in a read-only fashion) to C code.  This is in fact the most
> common use of the buffer API now, and appears to be the reason why the
> segment count must typically be 1.
> 
> In connection with this, the buffer API has grown a distinction
> between character and binary buffers (on the read-only end only).
> This may have been a mistake; it was intended to help with Unicode but
> it ended up not being used.
> 
> The Buffer Object
> -----------------
> 
> The buffer object has a much less clear reason for its existence.
> When Greg Stein first proposed it, he wrote:
> 
>     The intent of this type is to expose a string-like interface from
>     an object that supports the buffer interface (without making a
>     copy). In addition, it is intended to support slices of the target
>     object.
> 
>     My eventual goal here is to tweak the file object to support
>     memory mapping and the buffer interface. The buffer object can
>     then return slices of the file without making a new copy. Next
>     step: change marshal.c, ceval.c, and compile.c to support a buffer
>     for the co_code attribute. Net result is that copies of code
>     streams don't need to be copied onto the heap, but can be left in
>     an mmap'd file or a frozen file. I'm hoping there will be some
>     perf gains (time and memory).
> 
>     Even without some of the co_code work, enabling mmap'd files and
>     buffers onto them should be very useful. I can probably rattle off
>     a good number of other uses for the buffer type.
> 
> I don't think that any of these benefits have been realized yet, and
> altogether I think that the buffer object causes a lot of confusion.
> The buffer *API* doesn't guarantee enough about the lifetime of the
> pointers for the buffer *object* to be able to safely preserve those
> pointers, even if the buffer object holds on to the base object.  (The
> C-level buffer API informally guarantees that the data remains valid
> only until you do anything to the base object; this is usually fine as
> long as you don't release the global interpreter lock.)
> 
> The buffer object's approach to implementing the various sequence
> operations is strange: sometimes it behaves like a string, sometimes
> it doesn't.  E.g. a slice returns a new string object unless it
> happens to address the whole buffer, in which case it returns a
> reference to the existing buffer object.  It would seem more logical
> that a subslice would return a new buffer object.  Concatenation and
> repetition of buffer objects are likewise implemented inconsistently;
> it would have been more consistent with the intended purpose if these
> weren't supported at all (i.e. if none of the buffer object operations
> would allocate new memory except for buffer object headers).
> 
> I would have concluded that the buffer object is entirely useless, if
> it weren't for some very light use that is being made of it by the
> Unicode machinery.  I can't quite tell whether that was done just
> because it was convenient, or whether that shows there is a real
> need.
> 
> What Now?
> ---------
> 
> I'm not convinced that we need the buffer object at all.  For example,
> the mmap module defines a sequence object so doesn't seem to need the
> buffer object to help it support slices.
> 
> Regarding the buffer API, it's clearly useful, although I'm not
> convinced that it needs the multiple segment count option or the char
> vs. binary buffer distinction, given that we're not using this for
> Unicode objects as we originally planned.
> 
> I also feel that it would be helpful if there was an explicit way to
> lock and unlock the data, so that a file object can release the global
> interpreter lock while it is doing the I/O.  But that's not a high
> priority (and there are no *actual* problems caused by the lack of
> such an API -- just *theoretical*).
> 
> For Python 3000, I think I'd like to rethink this whole mess.  Perhaps
> byte buffers and character strings should be different beasts, and
> maybe character strings could have Unicode and 8-bit subclasses (and
> maybe other subclasses that explicitly know about their encoding).
> And maybe we'd have a real file base class.  And so on.
> 
> What to do in the short run?  I'm still for severely simplifing the
> buffer object (ripping out the unused operations) and deprecating it.
> 
> --Guido van Rossum (home page: http://www.python.org/~guido/)
> 
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://www.python.org/mailman/listinfo/python-dev
> 

-- 
Jeffery D. Collins  
Sr. Software Developer
Endeavors Technology, Inc.





From akuchlin at cnri.reston.va.us  Mon Oct 16 21:35:13 2000
From: akuchlin at cnri.reston.va.us (Andrew M. Kuchling)
Date: Mon, 16 Oct 2000 15:35:13 -0400
Subject: [Python-Dev] Post-2.0 strategy
In-Reply-To: <200010161851.NAA32597@cj20424-a.reston1.va.home.com>; from guido@python.org on Mon, Oct 16, 2000 at 01:51:51PM -0500
References: <ECEPKNMJLHAPFFJHDOJBIEJMDNAA.MarkH@ActiveState.com> <39EAB33E.35B72EA4@lemburg.com> <20001016060126.X347@lyra.org> <200010161808.NAA32318@cj20424-a.reston1.va.home.com> <00f601c03799$39f2c7b0$3c6340d5@hagrid> <200010161851.NAA32597@cj20424-a.reston1.va.home.com>
Message-ID: <20001016153513.A14693@amarok.cnri.reston.va.us>

On Mon, Oct 16, 2000 at 01:51:51PM -0500, Guido van Rossum wrote:
>> (does this mean that we're in post-2.0 mode? ;-)
>Yes :-)

Then this is a good time to ask what strategy will be followed
post-2.0.  Do you want a moratorium on massive checkins for a time
while 2.0 shakes out, re-opening the tree for larger changes in a few
months?  Or will you try to live with a CVS branch for 2.0 and re-open
the tree immediately?

--amk




From fdrake at beopen.com  Mon Oct 16 21:37:30 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Mon, 16 Oct 2000 15:37:30 -0400 (EDT)
Subject: [Python-Dev] Post-2.0 strategy
In-Reply-To: <20001016153513.A14693@amarok.cnri.reston.va.us>
References: <ECEPKNMJLHAPFFJHDOJBIEJMDNAA.MarkH@ActiveState.com>
	<39EAB33E.35B72EA4@lemburg.com>
	<20001016060126.X347@lyra.org>
	<200010161808.NAA32318@cj20424-a.reston1.va.home.com>
	<00f601c03799$39f2c7b0$3c6340d5@hagrid>
	<200010161851.NAA32597@cj20424-a.reston1.va.home.com>
	<20001016153513.A14693@amarok.cnri.reston.va.us>
Message-ID: <14827.22778.902987.343492@cj42289-a.reston1.va.home.com>

Andrew M. Kuchling writes:
 > Then this is a good time to ask what strategy will be followed
 > post-2.0.  Do you want a moratorium on massive checkins for a time
 > while 2.0 shakes out, re-opening the tree for larger changes in a few
 > months?  Or will you try to live with a CVS branch for 2.0 and re-open
 > the tree immediately?

  I think a maintenance branch for 2.0.1 (or whatever) should be
created as part of the release process in case we need a quick release
for critical bug fixes.
  The tree should be re-opened after the release via a message to
python-dev after the release is published.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From guido at python.org  Mon Oct 16 22:46:22 2000
From: guido at python.org (Guido van Rossum)
Date: Mon, 16 Oct 2000 15:46:22 -0500
Subject: [Python-Dev] Post-2.0 strategy
In-Reply-To: Your message of "Mon, 16 Oct 2000 15:35:13 -0400."
             <20001016153513.A14693@amarok.cnri.reston.va.us> 
References: <ECEPKNMJLHAPFFJHDOJBIEJMDNAA.MarkH@ActiveState.com> <39EAB33E.35B72EA4@lemburg.com> <20001016060126.X347@lyra.org> <200010161808.NAA32318@cj20424-a.reston1.va.home.com> <00f601c03799$39f2c7b0$3c6340d5@hagrid> <200010161851.NAA32597@cj20424-a.reston1.va.home.com>  
            <20001016153513.A14693@amarok.cnri.reston.va.us> 
Message-ID: <200010162046.PAA05288@cj20424-a.reston1.va.home.com>

> Then this is a good time to ask what strategy will be followed
> post-2.0.  Do you want a moratorium on massive checkins for a time
> while 2.0 shakes out, re-opening the tree for larger changes in a few
> months?  Or will you try to live with a CVS branch for 2.0 and re-open
> the tree immediately?

If we need to issue a patch release, we'll use a branch.  That seems
the only reasonable approach.

The tree will be open for checkins as soon as 2.0 is released (tonight
is looking good!), but I hope the people exercise some restraint and
discuss their plans for significant checkins on the python-dev list
first.

A lot of things should probably be discussed in the form of PEPs too!

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



From tim_one at email.msn.com  Mon Oct 16 21:47:05 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Mon, 16 Oct 2000 15:47:05 -0400
Subject: [Python-Dev] Post-2.0 strategy
In-Reply-To: <20001016153513.A14693@amarok.cnri.reston.va.us>
Message-ID: <LNBBLJKPBEHFEDALKOLCCEICHLAA.tim_one@email.msn.com>

[Andrew M. Kuchling]
> Then this is a good time to ask what strategy will be followed
> post-2.0.  Do you want a moratorium on massive checkins for a time
> while 2.0 shakes out ...

It's not a great time to ask, as we're still balls-to-the-wall *building*
the release and doing last-second checkins (things like NEWS, not code).  So
there's an absolute ban on any checkins until further notice (on
Python-Dev), excepting for those explicitly approved by Jeremy.

After that, I agree with Fred that we should make a 2.0.1 branch
simultaneous with the release.





From jeremy at beopen.com  Tue Oct 17 00:11:49 2000
From: jeremy at beopen.com (Jeremy Hylton)
Date: Mon, 16 Oct 2000 18:11:49 -0400 (EDT)
Subject: [Python-Dev] Python 2.1 Release Schedule (tentative)
Message-ID: <14827.32037.652156.120714@bitdiddle.concentric.net>

FYI: In anticpation of the Python 2.0 final release this evening, we
just created a new PEP describing the release schedule for Python 2.1.

Jeremy


PEP: 226
Title: Python 2.1 Release Schedule
Version: $Revision: 1.1 $
Author: Jeremy Hylton <jeremy at beopen.com>
Status: Incomplete
Type: Informational
Created: 16-Oct-2000
Python-Version: 2.1
Post-History:

Abstract

    This document describes the post Python 2.0 development and
    release schedule.  According to this schedule, Python 2.1 will be
    released in mid-March of 2001.  The schedule primarily concerns
    itself with PEP-size items.  Small bug fixes and changes will
    occur up until the first beta release.


Tentative Release Schedule

    16-Oct-2000: Python 2.0 final release
 
    These dates represent goals, not commitments.

    16-Dec-2000: 2.1 PEPs ready for review
    01-Feb-2001: First 2.1 beta release
    16-Mar-2001: 2.1 final release


Guidelines for making changes for Python 2.1

    The guidelines and schedule will be revised based on discussion in
    the python-dev at python.org mailing list.

    The PEP system was instituted late in the Python 2.0 development
    cycle and many changes did not follow the process described in PEP
    1.  The development process for 2.1, however, will follow the PEP
    process as documented.

    The first eight weeks following 2.0 final will be the design and
    review phase.  By the end of this period, any PEP that is proposed
    for 2.1 should be ready for review.  This means that the PEP is
    written and discussion has occurred on the python-dev at python.org
    and python-list at python.org mailing lists.

    The next six weeks will be spent reviewing the PEPs and
    implementing and testing the accepted PEPs.  When this period
    stops, we will end consideration of any incomplete PEPs.  Near the
    end of this period, there will be a feature freeze where any small
    features not worthy of a PEP will not be accepted.

    Before the final release, we will have six weeks of beta testing
    and a release candidate or two.


Bug fix releases before 2.1

    We may have to issue Python 2.0.1 for critical bug fixes.  If we
    need to issue a bug fix release, we will use a CVS branch. 


General guidelines for submitting patches and making changes

    Use good sense when committing changes.  You should know what we
    mean by good sense or we wouldn't have given you commit privileges
    <0.5 wink>.  Some specific examples of good sense include:

    - Do whatever the dictator tells you.

    - Discuss any controversial changes on python-dev first.  If you
      get a lot of +1 votes and no -1 votes, make the change.  If you
      get a some -1 votes, think twice; consider asking Guido what he
      thinks.

    - If the change is to code you contributed, it probably makes
      sense for you to fix it.

    - If the change affects code someone else wrote, it probably makes
      sense to ask him or her first.

    - You can use the SourceForge (SF) Patch Manager to submit a patch
      and assign it to someone for review.

    Any significant new feature must be described in a PEP and
    approved before it is checked in.

    Any significant code addition, such as a new module or large
    patch, must include test cases for the regression test and
    documentation.  A patch should not be checked in until the tests
    and documentation are ready.

    If you fix a bug, you should write a test case that would have
    caught the bug.

    If you commit a patch from the SF Patch Manager or fix a bug from
    the Jitterbug database, be sure to reference the patch/bug number
    in the CVS log message.  Also be sure to change the status in the
    patch manager or bug database (if you have access to the bug
    database).

    It is not acceptable for any checked in code to cause the
    regression test to fail.  If a checkin causes a failure, it must
    be fixed within 24 hours or it will be backed out.

    All contributed C code must be ANSI C.  If possible check it with
    two different compilers, e.g. gcc and MSVC.

    All contributed Python code must follow Guido's Python style
    guide.  http://www.python.org/doc/essays/styleguide.html

    It is understood that any code contributed will be released under
    an Open Source license.  Do not contribute code if it can't be
    released this way.



From greg at cosc.canterbury.ac.nz  Tue Oct 17 01:09:55 2000
From: greg at cosc.canterbury.ac.nz (Greg Ewing)
Date: Tue, 17 Oct 2000 12:09:55 +1300 (NZDT)
Subject: [Python-Dev] The buffer interface
In-Reply-To: <200010161808.NAA32318@cj20424-a.reston1.va.home.com>
Message-ID: <200010162309.MAA26975@s454.cosc.canterbury.ac.nz>

Guido:

> The buffer *API* doesn't guarantee enough about the lifetime of the
> pointers for the buffer *object* to be able to safely preserve those
> pointers, even if the buffer object holds on to the base object.

This seems like a fatal flaw to me, which should have
prevented the buffer object in its present form from
ever having been implemented.

I suggest that this problem MUST be fixed, or the
buffer object removed entirely.

Greg Ewing, Computer Science Dept, +--------------------------------------+
University of Canterbury,	   | A citizen of NewZealandCorp, a	  |
Christchurch, New Zealand	   | wholly-owned subsidiary of USA Inc.  |
greg at cosc.canterbury.ac.nz	   +--------------------------------------+



From gstein at lyra.org  Tue Oct 17 03:57:09 2000
From: gstein at lyra.org (Greg Stein)
Date: Mon, 16 Oct 2000 18:57:09 -0700
Subject: [Python-Dev] The buffer interface
In-Reply-To: <Pine.LNX.4.21.0010161135470.15198-100000@localhost.localdomain>; from jcollins@endtech.com on Mon, Oct 16, 2000 at 01:22:22PM -0700
References: <200010161808.NAA32318@cj20424-a.reston1.va.home.com> <Pine.LNX.4.21.0010161135470.15198-100000@localhost.localdomain>
Message-ID: <20001016185709.J25097@lyra.org>

On Mon, Oct 16, 2000 at 01:22:22PM -0700, Jeff Collins wrote:
>...
> I think that buffer object is fairly important.  They provide a mechanism
> for exposing arbitrary chunks of memory (eg, PyBuffer_FromMemory),
> something that no other python object does, AFIAK.  Perhaps clarifying the
> interface (such as the slice operator returning a buffer, as suggested
> below) and providing more hooks from Python for creating buffers (via
> newmodule, say) would be helpful.

There have been quite a few C extensions (and embedding Python!) where the
buffer objects have been used in this fashion. For example, if you have a
string argument that you wish to pass into Python, then you can avoid a copy
by wrapping a Buffer Object around it and passing that.

Many of the issues with the buffer object can be solved with simple changes.
For example, the "mutable object" thing is easily dealt with by having the
object not record the pointer, but just fetch it every time that it wants to
do an operation.
[ and if we extend the buffer API, we could potentially optimize the
  behavior to avoid the ptr refetch on each operation ]

I don't recall the motivation for returning strings. I believe it was based
on an attempt to make the buffer look as much like a string as possible (and
slices and concats return strings). That was a poor choice :-)  ... so,
again, some basic changes to return slices and concats as buffer objects
would make sense.

Extending the buffer() builtin to create writeable buffer objects has been a
reasonably common request. What seems to happen instead is that people
developing C extensions (which desire buffer objects as their params) just
add a new function to the extension to create buffer objects.

Re: the buffer API: At the time the "s"/"t" codes were introduced (before
1.5.2 was released), we had a very different concept of how Unicode objects
would be implemented. At that time, Unicode objects had no 8-bit
representation (just 16-bit chars), so the difference was important. I'm not
clued in enough on the ramifications of torching the difference in the API,
but it would be a nice simplification.

Buffers vs arrays: this is a harder question. Which is the "recommended
binary type [for series of bytes]" ? Buffers can refer to arbitrary memory.
Arrays maintain their own memory. I believe the two models are needed, so
I'd initially offer that both buffers and arrays need to be maintained.
However, given that... what is the purpose of the array if a buffer can
*also* maintain its own memory?

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/



From guido at python.org  Tue Oct 17 05:35:02 2000
From: guido at python.org (Guido van Rossum)
Date: Mon, 16 Oct 2000 22:35:02 -0500
Subject: [Python-Dev] Python 2.0 final release is out!
Message-ID: <200010170335.WAA07253@cj20424-a.reston1.va.home.com>

I am happy to announce that Python 2.0 is released.  I thank my
colleagues at BeOpen PythonLabs and the many volunteers in the Python
developer community for their incredible work on this release over the
past months.  Please pick up the new release at

    http://www.pythonlabs.com/products/python2.0/

There you will find a Windows installer, a source tarball, RedHat
RPMs, downloadable and online documentation, and a long list of new
features and fixed bugs.  Among the new features in Python 2.0 are:

  - Augmented assignment, e.g. x += 1
  - List comprehensions, e.g. [x**2 for x in range(10)]
  - Extended import statement, e.g. import Module as Name
  - Extended print statement, e.g. print >> file, "Hello"
  - Collection of cyclical garbage

For a fuller discussion of the changes in Python 2.0 since Python
1.5.2, please see the article "What's New in Python 2.0" by A.M.
Kuchling and Moshe Zadka:
http://starship.python.net/crew/amk/python/writing/new-python/

All major reported bugs have been fixed in this final release.  We've
gone through an extremely thorough set of beta releases followed by a
release candidate, and therefore we expect that this release will be
stable and virtually problem-free.  If you nevertheless run into a
bug, use the SourceForge bug tracker to report it:
http://sourceforge.net/bugs/?group_id=5470

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



From fdrake at beopen.com  Tue Oct 17 06:53:25 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Tue, 17 Oct 2000 00:53:25 -0400 (EDT)
Subject: [Python-Dev] CVS repository open for business
Message-ID: <14827.56133.84421.68885@cj42289-a.reston1.va.home.com>

  The Python CVS repository is now open for further development.

  If critical patches are needed to the 2.0 release, they should be
developed against the branch tagged "release20-maint", and should be
posted at SourceForge and discussed here on python-dev before checking
them into the branch.
  Thanks to all the Python developers for your hard work and
contributions!


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From mal at lemburg.com  Tue Oct 17 10:16:56 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Tue, 17 Oct 2000 10:16:56 +0200
Subject: [Python-Dev] The buffer interface
References: <200010161808.NAA32318@cj20424-a.reston1.va.home.com> <Pine.LNX.4.21.0010161135470.15198-100000@localhost.localdomain> <20001016185709.J25097@lyra.org>
Message-ID: <39EC0AF8.5FA79E97@lemburg.com>

Greg Stein wrote:
> 
> On Mon, Oct 16, 2000 at 01:22:22PM -0700, Jeff Collins wrote:
> >...
> > I think that buffer object is fairly important.  They provide a mechanism
> > for exposing arbitrary chunks of memory (eg, PyBuffer_FromMemory),
> > something that no other python object does, AFIAK.  Perhaps clarifying the
> > interface (such as the slice operator returning a buffer, as suggested
> > below) and providing more hooks from Python for creating buffers (via
> > newmodule, say) would be helpful.
> 
> There have been quite a few C extensions (and embedding Python!) where the
> buffer objects have been used in this fashion. For example, if you have a
> string argument that you wish to pass into Python, then you can avoid a copy
> by wrapping a Buffer Object around it and passing that.

Perhaps we ought to flesh out the current uses of buffer objects and
then decide how to proceed ?!

IMHO, the problem with buffer objects (apart from the sometimes strange
protocol behaviour) is that there too many "features" built into
it. Simplification and possibly diversification is needed: instead
of trying to achieve every possible C hack with buffer objects
we should try to come up with a reasonably small set of types
which allow only very basic tasks, e.g. 

1. wrapping C memory areas with the possibility of accessing the
   raw bytes in a read-only way (this should be buffer()),

2. providing a non-copying object reference type (I'd call this
   reference()) and

3. maintaining a writeable C memory buffer (arrays provide this feature).

The buffer object currently tries to do all three.

> Many of the issues with the buffer object can be solved with simple changes.
> For example, the "mutable object" thing is easily dealt with by having the
> object not record the pointer, but just fetch it every time that it wants to
> do an operation.
> [ and if we extend the buffer API, we could potentially optimize the
>   behavior to avoid the ptr refetch on each operation ]

Please don't extend the buffer API: the whole design is flawed
since it undermines data encapsulation in very dangerous ways.

If at all, we should consider a new API at abstract API level
which doesn't return raw C pointers, but real Python objects
(e.g. type 2 reference objects).
 
> I don't recall the motivation for returning strings. I believe it was based
> on an attempt to make the buffer look as much like a string as possible (and
> slices and concats return strings). That was a poor choice :-)  ... so,
> again, some basic changes to return slices and concats as buffer objects
> would make sense.

+1.
 
> Extending the buffer() builtin to create writeable buffer objects has been a
> reasonably common request. What seems to happen instead is that people
> developing C extensions (which desire buffer objects as their params) just
> add a new function to the extension to create buffer objects.

Please don't. Instead either suggest to use arrays or come up
with some new type with the sole purpose of providing read-write
access to a chunk of bytes.
 
> Re: the buffer API: At the time the "s"/"t" codes were introduced (before
> 1.5.2 was released), we had a very different concept of how Unicode objects
> would be implemented. At that time, Unicode objects had no 8-bit
> representation (just 16-bit chars), so the difference was important. I'm not
> clued in enough on the ramifications of torching the difference in the API,
> but it would be a nice simplification.

Well, think of it this way: Unicode was the first object to actually
try to make a difference between "s" and "t" -- and failed badly.
In the end, we reverted the decision to make any difference and
now special case Unicode objects in the getargs.c parser (so that
"s" and "t" work virtually the same for Unicode).

+1 on the idea of removing the difference altogether in 2.1.

If anyone needs to a special representation of an object, the object
should provide a clearly defined C API for this instead. E.g.
Unicode has lots of APIs to encode Unicode into quite a few
new repesentations.

> Buffers vs arrays: this is a harder question. Which is the "recommended
> binary type [for series of bytes]" ? Buffers can refer to arbitrary memory.
> Arrays maintain their own memory. I believe the two models are needed, so
> I'd initially offer that both buffers and arrays need to be maintained.
> However, given that... what is the purpose of the array if a buffer can
> *also* maintain its own memory?

Right and that's the problem: buffers shouldn't be able to
own memory. See above.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From barry at scottb.demon.co.uk  Tue Oct 17 10:40:52 2000
From: barry at scottb.demon.co.uk (Barry Scott)
Date: Tue, 17 Oct 2000 09:40:52 +0100
Subject: [Python-Dev] build problems large and small on FreeBSD
In-Reply-To: <14823.38174.143372.125749@bitdiddle.concentric.net>
Message-ID: <001201c03815$f54c4960$060210ac@private>

The FreeBSD ports collection had to be updated to support
importing C++ extensions with Python 1.5.2. (You get things
like cout not defined when importing).

Are the nessesary compile/link changes in 2.0?

		BArry




From gstein at lyra.org  Tue Oct 17 12:48:27 2000
From: gstein at lyra.org (Greg Stein)
Date: Tue, 17 Oct 2000 03:48:27 -0700
Subject: [Python-Dev] Re: [XML-SIG] PyXML home page on SF
In-Reply-To: <Pine.LNX.4.21.0010171130030.9897-100000@aries>; from Nicolas.Chauvat@logilab.fr on Tue, Oct 17, 2000 at 12:18:41PM +0200
References: <200010162335.BAA01015@loewis.home.cs.tu-berlin.de> <Pine.LNX.4.21.0010171130030.9897-100000@aries>
Message-ID: <20001017034827.F26804@lyra.org>

[ moving from xml-sig to python-dev ]

Reality check time...

On Tue, Oct 17, 2000 at 12:18:41PM +0200, Nicolas Chauvat wrote:
> [maintaining a pythonforge.org would take time and ressources]
> 
> Yes. But I understand a commercial company (BeOpen) has taken over python
> development. I think it is the kind of free services they could give
> back to the python community.

If VA Linux is already offering the service, then how does the community
benefit from BeOpen offering the same thing?

More importantly: how is BeOpen going to benefit from it? How do they get a
business return on that investment? That *will* come into play, you know.
Somebody has to pay for those sysadmins and hardware and connectivity.

> > > That would be pyxml.pythonforge.org, distutils.pythonforge.org, etc. :-)
> > 
> > I'd personally hope that python.org becomes accessible in that
> > way. You could probably have all of the current content there, and
> > then also have python.org/projects/pyxml; python.org/users/someone;
> > xml.python.org (and whatever other gimmicks they offer).

The last I heard, the intent was to move python.org from CNRI to a machine
at VA Linux. The content would then become available for the community to
work on; possibly through SourceForge facilities.

> > One advantage of taking things off SF is that responsiveness of that
> > system was really bad. That seems to have improved recently;
> 
> My concern is not about responsiveness as much as distribution (as in
> Internet is a distributed system). SourceForge is a great service. Good.
> Now are we to host every single open source project on SourceForge ? If we
> do so, the day SourceForge closes or changes its policy, or whatever,
> every single open source project will be halted or maybe discontinued.

There is no way that SF is ever going to close and take all of those
projects with it. VA Linux would be see their business instantly vaporized.
As ESR is fond to point out: VA Linux has built their business on trust from
the community. *ANY* failure to meet that trust will kill their biz.

> The people at SourceForge know their job: they provide a good service and
> the tools (code+doc) to implement that same service at other places.
> 
> Why wouldn't a community as big an active as python's put up ressources in
> common to offer such a useful service, but dedicated to python
> development ? There use to be a python.starship.net, maintained by
> volunteers, that is now hosted by BeOpen. Why not take the next step ?

python.starship.net has historically been a disaster area. Poorly maintained
or (even worse) maintained by a whole bunch of people. Have you ever seen
what happens when you give 20 people root access?

Then there was the time that a drive crashed. The machine was *gone* for
months.

Oh, and the network connectivity loss. A month offline, maybe?

The community is way to busy to run a service. Sorry.

That is why I like SF so much. They are ready and willing to run a service
and to fund that operation. And to all appearances, they are running it very
well (and continually upgrading it!).

> > if anybody is to host a similar server, they need to be aware that it
> > is probably hard to compete with SF in terms of provided services. For
> > example, I trust that SF has a reasonable backup strategy - they

They do. It is somewhere on their site. They have a complete backup
strategy. In fact, a while back, they lost a drive and restored most of it
from backup. I forget if there was any actual material lost.

> > simply can't risk a desaster. Anybody hosting a server for just a few
> > projects would not get the same sort of trust from me.
> 
> That's why I think we shouldn't look for someone able to host a server for
> a few projects but for some company(ies) able to put up the ressources for
> "python projects" and volunteers that help them.

Idealistic, but it won't happen. starship.net is my case in point.

> That would also make it easier for people to look for python ressources:
> code in development would be at something.python.org and 3rd party
> software at www.vex.net/parnassus. But I would agree that's a weak
> argument as long as www.python.org continues to be well-maintained with
> no broken links and stays the central hub for python information.

When python.org moves, then it will be maintained much better. I don't
recall the status of that, but I presume that Guido is still pushing to see
it happen.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/



From guido at python.org  Tue Oct 17 05:35:02 2000
From: guido at python.org (Guido van Rossum)
Date: Mon, 16 Oct 2000 22:35:02 -0500
Subject: [Python-Dev] Python 2.0 final release is out!
Message-ID: <mailman.971750281.20361.clpa-moderators@python.org>

I am happy to announce that Python 2.0 is released.  I thank my
colleagues at BeOpen PythonLabs and the many volunteers in the Python
developer community for their incredible work on this release over the
past months.  Please pick up the new release at

    http://www.pythonlabs.com/products/python2.0/

There you will find a Windows installer, a source tarball, RedHat
RPMs, downloadable and online documentation, and a long list of new
features and fixed bugs.  Among the new features in Python 2.0 are:

  - Augmented assignment, e.g. x += 1
  - List comprehensions, e.g. [x**2 for x in range(10)]
  - Extended import statement, e.g. import Module as Name
  - Extended print statement, e.g. print >> file, "Hello"
  - Collection of cyclical garbage

For a fuller discussion of the changes in Python 2.0 since Python
1.5.2, please see the article "What's New in Python 2.0" by A.M.
Kuchling and Moshe Zadka:
http://starship.python.net/crew/amk/python/writing/new-python/

All major reported bugs have been fixed in this final release.  We've
gone through an extremely thorough set of beta releases followed by a
release candidate, and therefore we expect that this release will be
stable and virtually problem-free.  If you nevertheless run into a
bug, use the SourceForge bug tracker to report it:
http://sourceforge.net/bugs/?group_id=5470

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




From guido at python.org  Tue Oct 17 16:06:00 2000
From: guido at python.org (Guido van Rossum)
Date: Tue, 17 Oct 2000 09:06:00 -0500
Subject: [Python-Dev] build problems large and small on FreeBSD
In-Reply-To: Your message of "Tue, 17 Oct 2000 09:40:52 +0100."
             <001201c03815$f54c4960$060210ac@private> 
References: <001201c03815$f54c4960$060210ac@private> 
Message-ID: <200010171406.JAA09272@cj20424-a.reston1.va.home.com>

> The FreeBSD ports collection had to be updated to support
> importing C++ extensions with Python 1.5.2. (You get things
> like cout not defined when importing).
> 
> Are the nessesary compile/link changes in 2.0?

Tell you what: I have no idea. :-(

I believe there were some changes to the Makefile and/or config file
to support C++, but I don't know if this works on FreeBSD.  I'm not a
big C++ user myself, so I rarely try this...

Can you try it?  If it doesn't work out of the box, let's sit down
together and figure out a fix.

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




From fdrake at beopen.com  Tue Oct 17 15:59:46 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Tue, 17 Oct 2000 09:59:46 -0400 (EDT)
Subject: [Python-Dev] Re: [XML-SIG] PyXML home page on SF
In-Reply-To: <Pine.LNX.4.21.0010171130030.9897-100000@aries>
References: <200010162335.BAA01015@loewis.home.cs.tu-berlin.de>
	<Pine.LNX.4.21.0010171130030.9897-100000@aries>
Message-ID: <14828.23378.795196.804989@cj42289-a.reston1.va.home.com>

[Moved to python-dev, since the shift has begun.]

Nicolas Chauvat writes:
 > I'm sure several people from PythonLabs are on this list. What is their
 > opinion ?

  I rather like letting the SourceForge crew take care of running the
service.  Running a website that needs constant updates is no trivial
matter, and SourceForge is *much* more complex than that!
  I have a great deal of respect for the hard work that I know goes
into running SourceForge, and would rather see that effort bolstered
by volunteers & contributions (docs, code, whatever) by people who are
able, than to see the efforts splintered.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From Nicolas.Chauvat at logilab.fr  Tue Oct 17 16:07:36 2000
From: Nicolas.Chauvat at logilab.fr (Nicolas Chauvat)
Date: Tue, 17 Oct 2000 16:07:36 +0200 (CEST)
Subject: [Python-Dev] Re: [XML-SIG] PyXML home page on SF
In-Reply-To: <14828.23378.795196.804989@cj42289-a.reston1.va.home.com>
Message-ID: <Pine.LNX.4.21.0010171600440.10465-100000@aries>

>   I have a great deal of respect for the hard work that I know goes
> into running SourceForge, and would rather see that effort bolstered
> by volunteers & contributions (docs, code, whatever) by people who are
> able, than to see the efforts splintered.

Hum, maybe I did not explain myself correctly and I don't want a
misunderstanding: I never meant "let's create a SourceForge-like tool,
SourceForge is bad", but only "why not host a python specific service
using the SourceForge code and tools", as www.bioinformatics.org does for
projects related to bio-ingeneering.

-- 
Nicolas Chauvat

http://www.logilab.com - "Mais o? est donc Ornicar ?" - LOGILAB, Paris (France)




From guido at python.org  Tue Oct 17 17:26:31 2000
From: guido at python.org (Guido van Rossum)
Date: Tue, 17 Oct 2000 10:26:31 -0500
Subject: [Python-Dev] Re: [XML-SIG] PyXML home page on SF
In-Reply-To: Your message of "Tue, 17 Oct 2000 16:07:36 +0200."
             <Pine.LNX.4.21.0010171600440.10465-100000@aries> 
References: <Pine.LNX.4.21.0010171600440.10465-100000@aries> 
Message-ID: <200010171526.KAA09461@cj20424-a.reston1.va.home.com>

> Hum, maybe I did not explain myself correctly and I don't want a
> misunderstanding: I never meant "let's create a SourceForge-like tool,
> SourceForge is bad", but only "why not host a python specific service
> using the SourceForge code and tools", as www.bioinformatics.org does for
> projects related to bio-ingeneering.

Why not indeed?  Why spend time running a service that SourceForge is
already providing, and very well at that?  This has come up
occasionally at BeOpen but the only argument for it that was ever
brought up (by the marketing folks, of course :-) was the hope that it
would help sell banner ads -- not that there would be an advantage for
the community.

What would be the advantage for the community or running our own?
What's wrong with using SourceForge?  I say, if it ain't broke don't
fix it.  (And then again, there may be a very good reason to run our
own, and maybe I just don't see it. :-)

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




From thomas at xs4all.net  Tue Oct 17 17:11:11 2000
From: thomas at xs4all.net (Thomas Wouters)
Date: Tue, 17 Oct 2000 17:11:11 +0200
Subject: [Python-Dev] Re: [XML-SIG] PyXML home page on SF
In-Reply-To: <200010171526.KAA09461@cj20424-a.reston1.va.home.com>; from guido@python.org on Tue, Oct 17, 2000 at 10:26:31AM -0500
References: <Pine.LNX.4.21.0010171600440.10465-100000@aries> <200010171526.KAA09461@cj20424-a.reston1.va.home.com>
Message-ID: <20001017171111.K12812@xs4all.nl>

On Tue, Oct 17, 2000 at 10:26:31AM -0500, Guido van Rossum wrote:

> > Hum, maybe I did not explain myself correctly and I don't want a
> > misunderstanding: I never meant "let's create a SourceForge-like tool,
> > SourceForge is bad", but only "why not host a python specific service
> > using the SourceForge code and tools", as www.bioinformatics.org does for
> > projects related to bio-ingeneering.

> What would be the advantage for the community or running our own?
> What's wrong with using SourceForge?  I say, if it ain't broke don't
> fix it.  (And then again, there may be a very good reason to run our
> own, and maybe I just don't see it. :-)

There is no advantage that I know of. I know a lot about keeping machines
and websites up and running (that's what I do for a living(*), after all)
and I can tell you you need a big (or very dedicated) sysadmin staff to be
able to offer anything as reliable as SourceForge.

So the website & CVS tree itself could be run on a low-end machine. Say a
PII-300 with 128 MB RAM. You need at least two, preferably three machines,
regardless of performance, to be able to offer 'reliable' services.
Preferably load-balanced by something like a smart switch (we use Alteon
Layer-4 ethernet switches for that task, and you can do cool things with
them. They're also pretty expensive.) And you need a way to back it up. A
tape library or DAT streamer of some kind. Preferably a separate machine to
do the actual backups. Live or fast-cycled backups can also be a lifesaver,
which either requires another machine or two with speedy disks, or storing
your data on something dedicated like a NetApp Filer. (Very cool machine, a
dedicated NFS and CIFS (SMB) fileserver with excellent live backups,
'snapshots', as many as you want/need. Only costs you diskspace. Oh, and
this quality comes at a price, too, of course.)

And then there's the reliable network access, reliable system room (with
reliable and preferably redundant power), and the 24/7 warning system that
wakes up stand-by sysadmins to fix problems.

And for the specialized hardware and software, you need a few people who
know how to handle them. You need several people anyway, to cover all bases
even in the face of illness, vacations and the famous bus accidents. We have
a crew of 12 now, with a few new additions, and even then we run into
trouble with vacations. I dare say we offer more reliable services than
SourceForge does, but we also cost more :-)

In short, the only advantage to not using SourceForge is that you can do
things SourceForge can't or won't. Run software SourceForge won't, for
instance. However, I would strongly suggest making such software
'non-essential', keeping most of the stuff on SourceForge, spend lots less
money on the technical setup, and suffer a bit when the service is down.

*) Where living is defined as 'making enough money to stay breathing and
work on Python', and 'work on Python' has higher importance, of course :-)

-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!



From akuchlin at mems-exchange.org  Tue Oct 17 18:47:34 2000
From: akuchlin at mems-exchange.org (Andrew Kuchling)
Date: Tue, 17 Oct 2000 12:47:34 -0400
Subject: [Python-Dev] Publicity for 2.0 release?
Message-ID: <E13lZtm-0001b4-00@kronos.cnri.reston.va.us>

Is BeOpen doing any publicity for the release of 2.0?  For example,
issuing a press release and sending it to lots of different
publications, such as DDJ, Web Development, Windows programming magazines,
whatever that XML magazine is called, etc.?

(Hmm... www.beopen.com hasn't been updated to mention the new release
-- nor even 2.0c1.)

--amk



From pf at artcom-gmbh.de  Tue Oct 17 19:21:19 2000
From: pf at artcom-gmbh.de (Peter Funk)
Date: Tue, 17 Oct 2000 19:21:19 +0200 (MEST)
Subject: [Python-Dev] Publicity for 2.0 release?
In-Reply-To: <E13lZtm-0001b4-00@kronos.cnri.reston.va.us> from Andrew Kuchling at "Oct 17, 2000 12:47:34 pm"
Message-ID: <m13laQR-000Dm8C@artcom0.artcom-gmbh.de>

Andrew Kuchling:
> Is BeOpen doing any publicity for the release of 2.0?  For example,
> issuing a press release and sending it to lots of different
> publications, such as DDJ, Web Development, Windows programming magazines,
> whatever that XML magazine is called, etc.?
> 
> (Hmm... www.beopen.com hasn't been updated to mention the new release
> -- nor even 2.0c1.)

Really bad marketing! ;-)  But not as bad as it could have been:
Other places hopping into my mind were:
	http://slashdot.org/  (already done, see below)
	http://freshmeat.net/ (already done by Andrew Kuchling, 3249 hits)
	http://www.newsforge.com/ (didn't see Python mentioned there yet)
and not to forget 
	http://www.python.org/ (already done)

quoting from slashdot:
     """Python 2.0 Released

        Posted by timothy on 5:34 Tuesday 17 October 2000
        from the Perl-6-times-infinity-nyeahnyeah-nyeahnyeah dept.
        atallah writes: "It would appear that the long awaited Python 2.0 was
        finally released today. The front page of the Web site has the
        announcement." According to that announcement, Python 2.0 will receive
        minor-version updates around every 6 months, even as work begins on the
        shoot-for-the-moon Python 3000. For the curious, here's the list of what's new in 2.0; the list
        includes "full XML support and several forms of new syntax," as well as the BeOpen label. 

        ( Read More... | 164 comments )
     """

Regards, Peter
-- 
Peter Funk, Oldenburger Str.86, D-27777 Ganderkesee, Germany, Fax:+49 4222950260
office: +49 421 20419-0 (ArtCom GmbH, Grazer Str.8, D-28359 Bremen)



From akuchlin at mems-exchange.org  Tue Oct 17 19:33:22 2000
From: akuchlin at mems-exchange.org (Andrew Kuchling)
Date: Tue, 17 Oct 2000 13:33:22 -0400
Subject: [Python-Dev] Publicity for 2.0 release?
In-Reply-To: <m13laQR-000Dm8C@artcom0.artcom-gmbh.de>; from pf@artcom-gmbh.de on Tue, Oct 17, 2000 at 07:21:19PM +0200
References: <E13lZtm-0001b4-00@kronos.cnri.reston.va.us> <m13laQR-000Dm8C@artcom0.artcom-gmbh.de>
Message-ID: <20001017133322.A6158@kronos.cnri.reston.va.us>

On Tue, Oct 17, 2000 at 07:21:19PM +0200, Peter Funk wrote:
>	http://freshmeat.net/ (already done by Andrew Kuchling, 3249 hits)

By Jeremy, actually.  I'm not sure why it lists my name instead --
Freshmeat bug?

--amk



From hinsen at cnrs-orleans.fr  Tue Oct 17 22:27:10 2000
From: hinsen at cnrs-orleans.fr (Konrad Hinsen)
Date: Tue, 17 Oct 2000 22:27:10 +0200
Subject: [Python-Dev] Re: [Numpy-discussion] Re: numpy,  overflow, inf, ieee, and rich comparison
In-Reply-To: <39EB3D03.A00C78B6@jps.net> (message from Chris Barker on Mon, 16
	Oct 2000 10:38:11 -0700)
References: <LNBBLJKPBEHFEDALKOLCGEFLHLAA.tim_one@email.msn.com> <39EB3D03.A00C78B6@jps.net>
Message-ID: <200010172027.WAA11907@chinon.cnrs-orleans.fr>

> Are people doing the kind of numeric programming with "complex
> algorithms" using Python that Konrad refers to? More importantly, how
> many people?

At least one: me.

> >  Guido thinks that 2/3 returning 0 was a design mistake,
> > but not that math.sqrt(-1) raising an exception is a mistake.  Most Python
> > users won't know what to do with a complex number, so it's "an error" to
> > them.
>
> Guido's philosophy is clearly that Python defaults should be geared to
> "Most Python users". I agree, and as I wrote in an earlier post, the

It's difficult to say what "most Python users" want; it's not a static
community. I'd say the basic principle is "no bad surprises".  2/3 ==
0 is a bad surprise for anyone who knows elementary math but is not
familiar with certain programming languages, especially since the
program goes on silently with a "wrong" intermediate result.

> Maybe we can have true 754 compliance in Py3k, and we can all be happy!!

Py3k forever!

Konrad.
--
-------------------------------------------------------------------------------
Konrad Hinsen                            | E-Mail: hinsen at cnrs-orleans.fr
Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24
Rue Charles Sadron                       | Fax:  +33-2.38.63.15.17
45071 Orleans Cedex 2                    | Deutsch/Esperanto/English/
France                                   | Nederlands/Francais
-------------------------------------------------------------------------------



From Nicolas.Chauvat at logilab.fr  Wed Oct 18 10:35:02 2000
From: Nicolas.Chauvat at logilab.fr (Nicolas Chauvat)
Date: Wed, 18 Oct 2000 10:35:02 +0200 (CEST)
Subject: [Python-Dev] Re: [XML-SIG] PyXML home page on SF
In-Reply-To: <200010172151.XAA00871@loewis.home.cs.tu-berlin.de>
Message-ID: <Pine.LNX.4.21.0010181025220.12124-100000@aries>

On Tue, 17 Oct 2000, Martin v. Loewis wrote:

[about my suggestion concerning a SourceForge dedicated to python]

That was only a suggestion, not a demand as someone stated. I would love
to set up a pythonforge myself if I had the resources, unfortunately I
don't... maybe in a few months? Time will tell. For now I'll just go
back to hacking and keep quiet.

Cheers, :)

-- 
Nicolas Chauvat

http://www.logilab.com - "Mais o? est donc Ornicar ?" - LOGILAB, Paris (France)




From barry at scottb.demon.co.uk  Wed Oct 18 11:57:04 2000
From: barry at scottb.demon.co.uk (Barry Scott)
Date: Wed, 18 Oct 2000 10:57:04 +0100
Subject: [Python-Dev] build problems large and small on FreeBSD
In-Reply-To: <200010171406.JAA09272@cj20424-a.reston1.va.home.com>
Message-ID: <001401c038e9$c4cabbd0$060210ac@private>

O.k. will do, hopefully this weekend.

		BArry

> -----Original Message-----
> From: guido at cj20424-a.reston1.va.home.com
> [mailto:guido at cj20424-a.reston1.va.home.com]On Behalf Of Guido van
> Rossum
> Sent: 17 October 2000 15:06
> To: Barry Scott
> Cc: jeremy at beopen.com; python-dev at python.org
> Subject: Re: [Python-Dev] build problems large and small on FreeBSD
> 
> 
> > The FreeBSD ports collection had to be updated to support
> > importing C++ extensions with Python 1.5.2. (You get things
> > like cout not defined when importing).
> > 
> > Are the nessesary compile/link changes in 2.0?
> 
> Tell you what: I have no idea. :-(
> 
> I believe there were some changes to the Makefile and/or config file
> to support C++, but I don't know if this works on FreeBSD.  I'm not a
> big C++ user myself, so I rarely try this...
> 
> Can you try it?  If it doesn't work out of the box, let's sit down
> together and figure out a fix.
> 
> --Guido van Rossum (home page: http://www.python.org/~guido/)
> 
> 



From mal at lemburg.com  Wed Oct 18 18:03:16 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Wed, 18 Oct 2000 18:03:16 +0200
Subject: [Python-Dev] Ready for Python 2.1 ?
Message-ID: <39EDC9C4.7D61454@lemburg.com>

Before starting to work on postponed patches and checking them
in: is the current CVS tree ready for new checkins (tags applied,
etc.) ?

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From fdrake at beopen.com  Wed Oct 18 18:29:45 2000
From: fdrake at beopen.com (Fred L. Drake, Jr.)
Date: Wed, 18 Oct 2000 12:29:45 -0400 (EDT)
Subject: [Python-Dev] Ready for Python 2.1 ?
In-Reply-To: <39EDC9C4.7D61454@lemburg.com>
References: <39EDC9C4.7D61454@lemburg.com>
Message-ID: <14829.53241.51394.729109@cj42289-a.reston1.va.home.com>

M.-A. Lemburg writes:
 > Before starting to work on postponed patches and checking them
 > in: is the current CVS tree ready for new checkins (tags applied,
 > etc.) ?

  Yes; I posted a note re-opening the tree yesterday (or late Monday
night; I can't remember that far back).
  We've just been too tired to do a lot since the release.  ;)


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member




From tim_one at email.msn.com  Wed Oct 18 18:52:52 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Wed, 18 Oct 2000 12:52:52 -0400
Subject: [Python-Dev] Ready for Python 2.1 ?
In-Reply-To: <14829.53241.51394.729109@cj42289-a.reston1.va.home.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCOEMMHLAA.tim_one@email.msn.com>

[Fred L. Drake, Jr.]
> ...
>   We've just been too tired to do a lot since the release.  ;)

LOL!  You're the very soul of diplomacy, Fred -- but I guess, overall, it
really is prudent not to mention all our recent suicide attempts <wink>.

my-wrists-are-killing-me-ly y'rs  - tim





From skip at mojam.com  Wed Oct 18 19:19:25 2000
From: skip at mojam.com (Skip Montanaro)
Date: Wed, 18 Oct 2000 12:19:25 -0500 (CDT)
Subject: [Python-Dev] Ready for Python 2.1 ?
In-Reply-To: <LNBBLJKPBEHFEDALKOLCOEMMHLAA.tim_one@email.msn.com>
References: <14829.53241.51394.729109@cj42289-a.reston1.va.home.com>
	<LNBBLJKPBEHFEDALKOLCOEMMHLAA.tim_one@email.msn.com>
Message-ID: <14829.56221.303087.523464@beluga.mojam.com>

    Tim> my-wrists-are-killing-me-ly y'rs  - tim

You need my typing watcher:

    http://www.musi-cal.com/~skip/python/watch.py

Only problem is I never figured out how to make it watch keystrokes
directly.  It detects mouse movement.  Since I do most of my typing in
Emacs, I fudged the keystroke thing by having the auto-save hook jiggle the
mouse a little...

I've tried, so far unsuccessfully, to make this a SourceForge project.  I've
even asked for help from SF, but their response wasn't helpful, and the
round-trip time for a response is too long to make pursuing that path
worthwhile.  The watch project is at

    http://sourceforge.net/projects/watch/

All I have is a CVSROOT/modules file.  Nothing I've tried has successfully
imported the one project file into cvs.

If anyone has any suggestions for kickstarting this thing, it would be much
appreciated.

Thx,

Skip




From thomas at xs4all.net  Wed Oct 18 20:43:19 2000
From: thomas at xs4all.net (Thomas Wouters)
Date: Wed, 18 Oct 2000 20:43:19 +0200
Subject: [Python-Dev] Ready for Python 2.1 ?
In-Reply-To: <14829.56221.303087.523464@beluga.mojam.com>; from skip@mojam.com on Wed, Oct 18, 2000 at 12:19:25PM -0500
References: <14829.53241.51394.729109@cj42289-a.reston1.va.home.com> <LNBBLJKPBEHFEDALKOLCOEMMHLAA.tim_one@email.msn.com> <14829.56221.303087.523464@beluga.mojam.com>
Message-ID: <20001018204319.L12812@xs4all.nl>

On Wed, Oct 18, 2000 at 12:19:25PM -0500, Skip Montanaro wrote:

>     Tim> my-wrists-are-killing-me-ly y'rs  - tim

> You need my typing watcher:

Given his remark about suicide attempts, I'm not sure if Tim really meant
'RSI' when he wrote that :-)

>     http://www.musi-cal.com/~skip/python/watch.py

> Only problem is I never figured out how to make it watch keystrokes
> directly.  It detects mouse movement.  Since I do most of my typing in
> Emacs, I fudged the keystroke thing by having the auto-save hook jiggle the
> mouse a little...

Funny, a colleague of mine has a similar tool. Also written in Python, I
think, though it may have been created in his Perl Period. On a linux box,
you can determine keystrokes by using /proc/interrupts. At least, if your
keyboard has an interrupt all for itself. (Pretty likely, really :)

-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!



From skip at mojam.com  Wed Oct 18 21:11:20 2000
From: skip at mojam.com (Skip Montanaro)
Date: Wed, 18 Oct 2000 14:11:20 -0500 (CDT)
Subject: [Python-Dev] Ready for Python 2.1 ?
In-Reply-To: <20001018204319.L12812@xs4all.nl>
References: <14829.53241.51394.729109@cj42289-a.reston1.va.home.com>
	<LNBBLJKPBEHFEDALKOLCOEMMHLAA.tim_one@email.msn.com>
	<14829.56221.303087.523464@beluga.mojam.com>
	<20001018204319.L12812@xs4all.nl>
Message-ID: <14829.62936.109759.567547@beluga.mojam.com>

    Thomas> On a linux box, you can determine keystrokes by using
    Thomas> /proc/interrupts. At least, if your keyboard has an interrupt
    Thomas> all for itself. (Pretty likely, really :)

Thanks, Neil S. sent me a patch for that already.  I'll try to work it into
the code.  Anyone have any idea how to monitor keystrokes on Windows, Mac or
other Unix flavors?  I suspect I'll just have to bite the bullet and work in
platform-dependent code for this.

Skip



From esr at thyrsus.com  Wed Oct 18 21:36:01 2000
From: esr at thyrsus.com (Eric S. Raymond)
Date: Wed, 18 Oct 2000 15:36:01 -0400
Subject: [Python-Dev] Ready for Python 2.1 ?
In-Reply-To: <14829.62936.109759.567547@beluga.mojam.com>; from skip@mojam.com on Wed, Oct 18, 2000 at 02:11:20PM -0500
References: <14829.53241.51394.729109@cj42289-a.reston1.va.home.com> <LNBBLJKPBEHFEDALKOLCOEMMHLAA.tim_one@email.msn.com> <14829.56221.303087.523464@beluga.mojam.com> <20001018204319.L12812@xs4all.nl> <14829.62936.109759.567547@beluga.mojam.com>
Message-ID: <20001018153601.A18127@thyrsus.com>

Skip Montanaro <skip at mojam.com>:
> Thanks, Neil S. sent me a patch for that already.  I'll try to work it into
> the code.  Anyone have any idea how to monitor keystrokes on Windows, Mac or
> other Unix flavors?  I suspect I'll just have to bite the bullet and work in
> platform-dependent code for this.

Might this monitoring function be a candidate for the Python library when 
it's done?
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

A man with a gun is a citizen.  A man without a gun is a subject.



From cgw at fnal.gov  Wed Oct 18 21:53:09 2000
From: cgw at fnal.gov (Charles G Waldman)
Date: Wed, 18 Oct 2000 14:53:09 -0500 (CDT)
Subject: [Python-Dev] Ready for Python 2.1 ?
In-Reply-To: <14829.62936.109759.567547@beluga.mojam.com>
References: <14829.53241.51394.729109@cj42289-a.reston1.va.home.com>
	<LNBBLJKPBEHFEDALKOLCOEMMHLAA.tim_one@email.msn.com>
	<14829.56221.303087.523464@beluga.mojam.com>
	<20001018204319.L12812@xs4all.nl>
	<14829.62936.109759.567547@beluga.mojam.com>
Message-ID: <14829.65445.421622.258893@buffalo.fnal.gov>

Skip Montanaro writes:
 > 
 > Thanks, Neil S. sent me a patch for that already.  I'll try to work it into
 > the code.  Anyone have any idea how to monitor keystrokes on Windows, Mac or
 > other Unix flavors?  I suspect I'll just have to bite the bullet and work in
 > platform-dependent code for this.

Can't tell you about Windows or Mac, but for Unix I'd read the file
driver/timers.c in the XScreensaver distribution (www.jwz.org).  This
code is pretty sophisticated and runs on all the major Unix flavors.



From skip at mojam.com  Wed Oct 18 22:22:45 2000
From: skip at mojam.com (Skip Montanaro)
Date: Wed, 18 Oct 2000 15:22:45 -0500 (CDT)
Subject: [Python-Dev] Ready for Python 2.1 ?
In-Reply-To: <14829.65445.421622.258893@buffalo.fnal.gov>
References: <14829.53241.51394.729109@cj42289-a.reston1.va.home.com>
	<LNBBLJKPBEHFEDALKOLCOEMMHLAA.tim_one@email.msn.com>
	<14829.56221.303087.523464@beluga.mojam.com>
	<20001018204319.L12812@xs4all.nl>
	<14829.62936.109759.567547@beluga.mojam.com>
	<14829.65445.421622.258893@buffalo.fnal.gov>
Message-ID: <14830.1685.932659.181060@beluga.mojam.com>

    Charles> ... but for Unix I'd read the file driver/timers.c in the
    Charles> XScreensaver distribution (www.jwz.org).  This code is pretty
    Charles> sophisticated and runs on all the major Unix flavors.

Thanks, Charles.  I will check it out.

Those of you who are former (or current) od users will appreciate Jamie
Zawinski's home page even if you're not interested in this topic.  I revisit
his site periodically.  I'm never disappointed...

Skip



From est at hyperreal.org  Wed Oct 18 22:30:46 2000
From: est at hyperreal.org (est at hyperreal.org)
Date: Wed, 18 Oct 2000 13:30:46 -0700 (PDT)
Subject: [Python-Dev] Ready for Python 2.1 ?
In-Reply-To: <14830.1685.932659.181060@beluga.mojam.com> from Skip Montanaro
 at "Oct 18, 2000 03:22:45 pm"
Message-ID: <20001018203047.27215.qmail@hyperreal.org>

Skip Montanaro discourseth:
> 
> Those of you who are former (or current) od users will appreciate Jamie
> Zawinski's home page even if you're not interested in this topic.  I revisit
> his site periodically.  I'm never disappointed...

Looks more like emacs hexl-mode to me.

Hmm..I guess you got this thread off topic. :)

E



From martin at loewis.home.cs.tu-berlin.de  Wed Oct 18 23:09:36 2000
From: martin at loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Wed, 18 Oct 2000 23:09:36 +0200
Subject: [Python-Dev] This Project Has Not Released Any Files
Message-ID: <200010182109.XAA00917@loewis.home.cs.tu-berlin.de>

What is the reason for not publishing Python 2.0 on SF for download?
SF certainly wouldn't be the primary source, but I think at least the
source distribution should be available there, with the release notes
telling where to get binary distributions (BeOpen, ActiveState, who
else?)

Regards,
Martin




From tim_one at email.msn.com  Wed Oct 18 23:34:38 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Wed, 18 Oct 2000 17:34:38 -0400
Subject: [Python-Dev] This Project Has Not Released Any Files
In-Reply-To: <200010182109.XAA00917@loewis.home.cs.tu-berlin.de>
Message-ID: <LNBBLJKPBEHFEDALKOLCAENKHLAA.tim_one@email.msn.com>

[Martin v. Loewis]
> What is the reason for not publishing Python 2.0 on SF for download?


From gstein at lyra.org  Thu Oct 19 00:44:13 2000
From: gstein at lyra.org (Greg Stein)
Date: Wed, 18 Oct 2000 15:44:13 -0700
Subject: [Python-Dev] This Project Has Not Released Any Files
In-Reply-To: <LNBBLJKPBEHFEDALKOLCAENKHLAA.tim_one@email.msn.com>; from tim_one@email.msn.com on Wed, Oct 18, 2000 at 05:34:38PM -0400
References: <200010182109.XAA00917@loewis.home.cs.tu-berlin.de> <LNBBLJKPBEHFEDALKOLCAENKHLAA.tim_one@email.msn.com>
Message-ID: <20001018154413.A31010@lyra.org>

On Wed, Oct 18, 2000 at 05:34:38PM -0400, Tim Peters wrote:
> [Martin v. Loewis]
> > What is the reason for not publishing Python 2.0 on SF for download?
> 
> >From BeOpen.com's POV, so long as they were paying major bills, they would
> rather have download traffic tickle their ad banners than SF's ad banners.
> 
> >From our (PythonLabs) POV, another publishing site is more work, and one URL
> is about as good as any other.  Besides, rising to the top of SF's "most
> active" list has not been an explicit life goal for any of us <wink>.

And here is where the larger community can help. Presuming that non-admins
can publish files, then we could take on the burden of publishing the files
via SF.

> > SF certainly wouldn't be the primary source, but I think at least the
> > source distribution should be available there, with the release notes
> > telling where to get binary distributions (BeOpen, ActiveState, who
> > else?)
> 
> I didn't see any advantage claimed for publishing on SF.  Without an
> advantage, the work/benefit ratio is infinite.

Work == 0 for you guys, presuming that non-admins can publish.

[ off to take a look... ]

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/



From akuchlin at mems-exchange.org  Thu Oct 19 18:20:37 2000
From: akuchlin at mems-exchange.org (Andrew Kuchling)
Date: Thu, 19 Oct 2000 12:20:37 -0400
Subject: [Python-Dev] 2.0 articles
Message-ID: <20001019122037.C21214@kronos.cnri.reston.va.us>

Before we all become focused on new features for Python 2.1, it would
be nice to do a bit more work on raising awareness of the new features
in 2.0.  There's little point in developing software if you don't
actually tell anyone about it, after all.

I'd like to suggest that people try to write some brief articles, just
a few pages long, each covering a particular feature in some detail.

Looking through the list of new stuff, the most significant features are:

* Unicode support.  (Perl's UTF-8 support still seems incomplete, with
  developers referring to it as "unusable", so we should definitely try and
  point out that we have working Unicode support right now.)

* Distutils: an introduction to writing setup scripts for simple
  Python modules, packages, and C extensions.

* The new XML tools.

* The new gettext support.

* Maybe the linuxaudiodev module, too.

Any other suggestions?

If the story of how a particular feature was implemented is
interesting, then that would also make a fine topic for a more
developer-oriented publication such as DDJ.  SRE or Unicode may be the
best candidates for this sort of thing, as their implementation
presented various tricky technical problems along the way.

Any volunteers?

--amk



From gvwilson at nevex.com  Thu Oct 19 18:53:31 2000
From: gvwilson at nevex.com (Greg Wilson)
Date: Thu, 19 Oct 2000 12:53:31 -0400 (EDT)
Subject: [Python-Dev] 2.0 articles
In-Reply-To: <20001019122037.C21214@kronos.cnri.reston.va.us>
Message-ID: <Pine.LNX.4.10.10010191237320.8628-100000@akbar.nevex.com>

> Andrew Kuchling wrote:
> Before we all become focused on new features for Python 2.1, it would be
> nice to do a bit more work on raising awareness of the new features in 2.0.  

"Doctor Dobb's Journal" would be very interested in articles --- 3000 words
(plus or minus), plus some code examples and diagrams.

> * Unicode support.  (Perl's UTF-8 support still seems incomplete, with
>   developers referring to it as "unusable", so we should definitely try and
>   point out that we have working Unicode support right now.)

Definitely --- the practical details of implementing Unicode, and a
Unicode-aware regular expression engine, would be very interesting to our
readers.  However, please steer clear of saying, "And anyway, Perl is broken."
(I just got a review copy of Hunt and Thomas's book on Ruby.  There are three
places in the first two chapters where they say, "And Ruby has more users in
Japan than Python."  I'll finish the book anyway.)

> * Distutils: an introduction to writing setup scripts for simple
>   Python modules, packages, and C extensions.

Possibly interesting; would be more so if Distutils could be applied/was being
applied to installation problems in other languages.

> * The new XML tools.

Definitely.

> * The new gettext support.
> * Maybe the linuxaudiodev module, too.

These are both probably too specialized...

> Any other suggestions?

The garbage collector: Java and Ruby both score points by having full garbage
collection, so its availability in Python 2.0 (along with a discussion of the
things that might break or change as a result) would be very interesting.

Thanks,
Greg (a contributing editor with DDJ)





From nas at arctrix.com  Thu Oct 19 12:09:52 2000
From: nas at arctrix.com (Neil Schemenauer)
Date: Thu, 19 Oct 2000 03:09:52 -0700
Subject: [Python-Dev] 2.0 articles
In-Reply-To: <Pine.LNX.4.10.10010191237320.8628-100000@akbar.nevex.com>; from gvwilson@nevex.com on Thu, Oct 19, 2000 at 12:53:31PM -0400
References: <20001019122037.C21214@kronos.cnri.reston.va.us> <Pine.LNX.4.10.10010191237320.8628-100000@akbar.nevex.com>
Message-ID: <20001019030952.A32671@glacier.fnational.com>

On Thu, Oct 19, 2000 at 12:53:31PM -0400, Greg Wilson wrote:
> The garbage collector: Java and Ruby both score points by having full garbage
> collection, so its availability in Python 2.0 (along with a discussion of the
> things that might break or change as a result) would be very interesting.

This is on my todo list.  I think there are some interesting
implementation issues.  Also, the article would be useful
documentation for python-dev type people.

  Neil



From akuchlin at mems-exchange.org  Thu Oct 19 19:32:08 2000
From: akuchlin at mems-exchange.org (Andrew Kuchling)
Date: Thu, 19 Oct 2000 13:32:08 -0400
Subject: [Python-Dev] 2.0 articles
In-Reply-To: <Pine.LNX.4.10.10010191237320.8628-100000@akbar.nevex.com>; from gvwilson@nevex.com on Thu, Oct 19, 2000 at 12:53:31PM -0400
References: <20001019122037.C21214@kronos.cnri.reston.va.us> <Pine.LNX.4.10.10010191237320.8628-100000@akbar.nevex.com>
Message-ID: <20001019133208.D21214@kronos.cnri.reston.va.us>

On Thu, Oct 19, 2000 at 12:53:31PM -0400, Greg Wilson wrote:
>"Doctor Dobb's Journal" would be very interested in articles --- 3000 words
>(plus or minus), plus some code examples and diagrams.

I was thinking more about on-line places such as
oreillynet.com/python/, but DDJ would be better still.

>The garbage collector: Java and Ruby both score points by having full garbage
>collection, so its availability in Python 2.0 (along with a discussion of the
>things that might break or change as a result) would be very interesting.

Arising out of lunch-time discussion, a comparison of how different
FFIs (Lisp, Java, Smalltalk, others?) deal with garbage collection
would be interesting, though perhaps unsuitable for DDJ, since the
topic is a rather unfocused one.

--amk




From martin at loewis.home.cs.tu-berlin.de  Thu Oct 19 19:31:58 2000
From: martin at loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Thu, 19 Oct 2000 19:31:58 +0200
Subject: [Python-Dev] This Project Has Not Released Any Files
Message-ID: <200010191731.TAA01114@loewis.home.cs.tu-berlin.de>

[Tim Peters]
> From BeOpen.com's POV, so long as they were paying major bills, they
> would rather have download traffic tickle their ad banners than SF's
> ad banners.

Even though this should have been clear to me all the time, stating it
explicitly triggers alarms for me.

I just checked, and it appears that Python 2.0 is not available for
download via ftp. In particular, it is not available via ftp from
ftp.python.org! If it was there, mirrors all over the world would pick
it up and bring it in a location near me (ftp.fu-berlin.de would be
nearest) (*).

So while making it available on SF may indeed give no advantage,
making it available on python.org would provide users with alternative
download locations, so that I don't feel the bandwidth limitation that
Web download from pythonlabs.com produces. That would be a clear
advantage to me, at least.

Of course, having ftp mirrors would mean that many downloads do not
tickle anybody's ad banners - which would probably be in the interest
of other users as well, just not in the interest of BeOpen. So I'm
curious how this conflict of interest is resolved...

Regards,
Martin

(*) ftp://ftp.python.org/python/src/README does not even mention
Python 2.0, and ftp://ftp.python.org/python/src/README.ftp says

Note that some mirrors only collect the this directory (src), and the
doc and contrib siblings, while the ftp master site,
<URL:ftp://ftp.python.org/>, has much more.

"Much more" may be true, just nothing recent... I probably should ask
ftpmaster.python.org to put Python-2.0.tar.gz in that directory.



From akuchlin at mems-exchange.org  Thu Oct 19 19:42:19 2000
From: akuchlin at mems-exchange.org (Andrew Kuchling)
Date: Thu, 19 Oct 2000 13:42:19 -0400
Subject: [Python-Dev] This Project Has Not Released Any Files
In-Reply-To: <200010191731.TAA01114@loewis.home.cs.tu-berlin.de>; from martin@loewis.home.cs.tu-berlin.de on Thu, Oct 19, 2000 at 07:31:58PM +0200
References: <200010191731.TAA01114@loewis.home.cs.tu-berlin.de>
Message-ID: <20001019134219.A29218@kronos.cnri.reston.va.us>

On Thu, Oct 19, 2000 at 07:31:58PM +0200, Martin v. Loewis wrote:
>(*) ftp://ftp.python.org/python/src/README does not even mention
>Python 2.0, and ftp://ftp.python.org/python/src/README.ftp says

Unless one of the BeOpen Pythoneers is already going to do this, I'll
go ahead and drop the relevant files into places.  Guys?

While we're at it, how about making the filenames for the source code
consistent? 

-rw-r--r--    1 guido    psa       2533053 Apr 13  1999 py152.tgz
-rw-r--r--    1 1103     psa       2259957 Oct 31  1998 pyth151.tgz
-rw-r--r--    1 guido    psa       1907724 May 31  1995 python1.2.tar.gz
-rw-r--r--    1 guido    psa       2037062 Oct 12  1995 python1.3.tar.gz
-rw-r--r--    1 guido    psa       2252481 Oct 25  1996 python1.4.tar.gz
-rw-r--r--    1 guido    psa       2904353 Jan  3  1998 python1.5.tar.gz

I like pythonX.X.tar.gz best, and will change the filenames (leaving
bc-compat symlinks for py152.tgz and pyth151.tgz) unless vetoed.
Though isn't the standard GNU naming convention more like
python-1.5.tar.gz?

--amk



From esr at thyrsus.com  Thu Oct 19 20:05:48 2000
From: esr at thyrsus.com (Eric S. Raymond)
Date: Thu, 19 Oct 2000 14:05:48 -0400
Subject: [Python-Dev] This Project Has Not Released Any Files
In-Reply-To: <20001019134219.A29218@kronos.cnri.reston.va.us>; from akuchlin@mems-exchange.org on Thu, Oct 19, 2000 at 01:42:19PM -0400
References: <200010191731.TAA01114@loewis.home.cs.tu-berlin.de> <20001019134219.A29218@kronos.cnri.reston.va.us>
Message-ID: <20001019140548.A21315@thyrsus.com>

Andrew Kuchling <akuchlin at mems-exchange.org>:
> I like pythonX.X.tar.gz best, and will change the filenames (leaving
> bc-compat symlinks for py152.tgz and pyth151.tgz) unless vetoed.
> Though isn't the standard GNU naming convention more like
> python-1.5.tar.gz?

It is, and I wish we'd move to it as did the Perl guys.  It makes life
substantially easier to have really uniform naming conventions,
especially for programs like the Metalabs file clerk.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Don't ever think you know what's right for the other person.
He might start thinking he knows what's right for you.
	-- Paul Williams, `Das Energi'



From mwh21 at cam.ac.uk  Thu Oct 19 20:01:29 2000
From: mwh21 at cam.ac.uk (Michael Hudson)
Date: 19 Oct 2000 19:01:29 +0100
Subject: [Python-Dev] 2.0 articles
In-Reply-To: Andrew Kuchling's message of "Thu, 19 Oct 2000 12:20:37 -0400"
References: <20001019122037.C21214@kronos.cnri.reston.va.us>
Message-ID: <m3d7gwsoau.fsf@atrus.jesus.cam.ac.uk>

Andrew Kuchling <akuchlin at mems-exchange.org> writes:

> Before we all become focused on new features for Python 2.1, it would
> be nice to do a bit more work on raising awareness of the new features
> in 2.0.  There's little point in developing software if you don't
> actually tell anyone about it, after all.
> 
> I'd like to suggest that people try to write some brief articles, just
> a few pages long, each covering a particular feature in some detail.
[snip]
> Any volunteers?

It's not as exciting as Unicode or XML, but I've thrashed out a few
hundred words on the new "setdefault" dictionary method.  It's up
here:

http://starship.python.net/crew/mwh/hacks/setdefault.html

Tell me what you think!  There's the beginning of a longer example in
a comment at the bottom, but I felt it was getting a bit long-winded
to be of interest.

Cheers,
M.

-- 
  If i don't understand lisp,  it would be wise to not bray about
  how lisp is stupid or otherwise criticize, because my stupidity 
  would be archived and open for all in the know to see.
                                                -- Xah, comp.lang.lisp




From gstein at lyra.org  Thu Oct 19 20:52:53 2000
From: gstein at lyra.org (Greg Stein)
Date: Thu, 19 Oct 2000 11:52:53 -0700
Subject: [Python-Dev] This Project Has Not Released Any Files
In-Reply-To: <200010191731.TAA01114@loewis.home.cs.tu-berlin.de>; from martin@loewis.home.cs.tu-berlin.de on Thu, Oct 19, 2000 at 07:31:58PM +0200
References: <200010191731.TAA01114@loewis.home.cs.tu-berlin.de>
Message-ID: <20001019115253.W31108@lyra.org>

On Thu, Oct 19, 2000 at 07:31:58PM +0200, Martin v. Loewis wrote:
>...
> Of course, having ftp mirrors would mean that many downloads do not
> tickle anybody's ad banners - which would probably be in the interest
> of other users as well, just not in the interest of BeOpen. So I'm
> curious how this conflict of interest is resolved...

Stating that a "conflict of interest" even EXISTS is a rather sorry
statement on things.

-g

-- 
Greg Stein, http://www.lyra.org/



From gstein at lyra.org  Thu Oct 19 20:54:36 2000
From: gstein at lyra.org (Greg Stein)
Date: Thu, 19 Oct 2000 11:54:36 -0700
Subject: [Python-Dev] This Project Has Not Released Any Files
In-Reply-To: <20001019134219.A29218@kronos.cnri.reston.va.us>; from akuchlin@mems-exchange.org on Thu, Oct 19, 2000 at 01:42:19PM -0400
References: <200010191731.TAA01114@loewis.home.cs.tu-berlin.de> <20001019134219.A29218@kronos.cnri.reston.va.us>
Message-ID: <20001019115436.X31108@lyra.org>

On Thu, Oct 19, 2000 at 01:42:19PM -0400, Andrew Kuchling wrote:
> On Thu, Oct 19, 2000 at 07:31:58PM +0200, Martin v. Loewis wrote:
> >(*) ftp://ftp.python.org/python/src/README does not even mention
> >Python 2.0, and ftp://ftp.python.org/python/src/README.ftp says
> 
> Unless one of the BeOpen Pythoneers is already going to do this, I'll
> go ahead and drop the relevant files into places.  Guys?

Please... just do it.

>...
> I like pythonX.X.tar.gz best, and will change the filenames (leaving
> bc-compat symlinks for py152.tgz and pyth151.tgz) unless vetoed.
> Though isn't the standard GNU naming convention more like
> python-1.5.tar.gz?

I'm with Eric -- go for the GNU standard.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/



From akuchlin at mems-exchange.org  Thu Oct 19 21:11:42 2000
From: akuchlin at mems-exchange.org (Andrew Kuchling)
Date: Thu, 19 Oct 2000 15:11:42 -0400
Subject: [Python-Dev] This Project Has Not Released Any Files
In-Reply-To: <20001019115436.X31108@lyra.org>; from gstein@lyra.org on Thu, Oct 19, 2000 at 11:54:36AM -0700
References: <200010191731.TAA01114@loewis.home.cs.tu-berlin.de> <20001019134219.A29218@kronos.cnri.reston.va.us> <20001019115436.X31108@lyra.org>
Message-ID: <20001019151142.A29651@kronos.cnri.reston.va.us>

On Thu, Oct 19, 2000 at 11:54:36AM -0700, Greg Stein wrote:
>On Thu, Oct 19, 2000 at 01:42:19PM -0400, Andrew Kuchling wrote:
>> Unless one of the BeOpen Pythoneers is already going to do this, I'll
>> go ahead and drop the relevant files into places.  Guys?

>Please... just do it.

I charged ahead and did it anyway; the Pythoneers can spank me for it
later.  (Worse, maybe they'll do something *bad* to me...)  There were
already doc/1.6/ and doc/2.0/ directories, and binaries (Windows,
RPMs) were in /pub/python/2.0/, along with the source. 

So I only touched /pub/python/src/.  All the releases and betas are
now consistently named python-X.Y.Z.tar.gz.  I've left symlinks in
place for the original filenames of the 1.5.1, 1.5.2 and 1.6 final
releases, but didn't bother making links for releases older than 1.5.1
or for beta versions, so any FTP URLs pointing directly to those files
will be broken.

--amk



From jeremy at alum.mit.edu  Fri Oct 20 18:28:19 2000
From: jeremy at alum.mit.edu (Jeremy Hylton)
Date: Fri, 20 Oct 2000 12:28:19 -0400 (EDT)
Subject: [Python-Dev] This Project Has Not Released Any Files
In-Reply-To: <20001019115436.X31108@lyra.org>
References: <200010191731.TAA01114@loewis.home.cs.tu-berlin.de>
	<20001019134219.A29218@kronos.cnri.reston.va.us>
	<20001019115436.X31108@lyra.org>
Message-ID: <14832.29347.622325.95025@bitdiddle.concentric.net>

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

  GS> On Thu, Oct 19, 2000 at 01:42:19PM -0400, Andrew Kuchling wrote:
  >> On Thu, Oct 19, 2000 at 07:31:58PM +0200, Martin v. Loewis wrote:
  >> >(*) ftp://ftp.python.org/python/src/README does not even mention
  >> >Python 2.0, and ftp://ftp.python.org/python/src/README.ftp says
  >>
  >> Unless one of the BeOpen Pythoneers is already going to do this,
  >> I'll go ahead and drop the relevant files into places.  Guys?

  GS> Please... just do it.

In the interest of making the distribution as widely available as
possible, I've placed files on SourceForge and at
http://www.python.org/2.0/

  >> ...  I like pythonX.X.tar.gz best, and will change the filenames
  >> (leaving bc-compat symlinks for py152.tgz and pyth151.tgz) unless
  >> vetoed.  Though isn't the standard GNU naming convention more
  >> like python-1.5.tar.gz?

  GS> I'm with Eric -- go for the GNU standard.

I used the file name conventions that we used throughout the 2.0
release cycle, e.g. Python-2.0.tar.gz.  I don't know if that's the GNU
standard or not (didn't realize it was a standard; don't know where to
find said standard; or is it just a custom?)

Jeremy



From jeremy at alum.mit.edu  Fri Oct 20 18:31:47 2000
From: jeremy at alum.mit.edu (Jeremy Hylton)
Date: Fri, 20 Oct 2000 12:31:47 -0400 (EDT)
Subject: [Python-Dev] 2.0 articles
In-Reply-To: <20001019133208.D21214@kronos.cnri.reston.va.us>
References: <20001019122037.C21214@kronos.cnri.reston.va.us>
	<Pine.LNX.4.10.10010191237320.8628-100000@akbar.nevex.com>
	<20001019133208.D21214@kronos.cnri.reston.va.us>
Message-ID: <14832.29555.123226.831103@bitdiddle.concentric.net>

>>>>> "AMK" == Andrew Kuchling <akuchlin at mems-exchange.org> writes:

  AMK> On Thu, Oct 19, 2000 at 12:53:31PM -0400, Greg Wilson wrote:
  >> "Doctor Dobb's Journal" would be very interested in articles ---
  >> 3000 words (plus or minus), plus some code examples and diagrams.

  AMK> I was thinking more about on-line places such as
  AMK> oreillynet.com/python/, but DDJ would be better still.

And, of course, there's the Python conference: http://python9.org/

  >> The garbage collector: Java and Ruby both score points by having
  >> full garbage collection, so its availability in Python 2.0 (along
  >> with a discussion of the things that might break or change as a
  >> result) would be very interesting.

  AMK> Arising out of lunch-time discussion, a comparison of how
  AMK> different FFIs (Lisp, Java, Smalltalk, others?) deal with
  AMK> garbage collection would be interesting, though perhaps
  AMK> unsuitable for DDJ, since the topic is a rather unfocused one.

A comparison of different FFIs with respect to garbage collection
might be interesting; hard to say without seeing what the conclusions
are.

Jeremy



From akuchlin at mems-exchange.org  Fri Oct 20 18:26:56 2000
From: akuchlin at mems-exchange.org (Andrew Kuchling)
Date: Fri, 20 Oct 2000 12:26:56 -0400
Subject: [Python-Dev] This Project Has Not Released Any Files
In-Reply-To: <14832.29347.622325.95025@bitdiddle.concentric.net>; from jeremy@alum.mit.edu on Fri, Oct 20, 2000 at 12:28:19PM -0400
References: <200010191731.TAA01114@loewis.home.cs.tu-berlin.de> <20001019134219.A29218@kronos.cnri.reston.va.us> <20001019115436.X31108@lyra.org> <14832.29347.622325.95025@bitdiddle.concentric.net>
Message-ID: <20001020122656.A9679@kronos.cnri.reston.va.us>

On Fri, Oct 20, 2000 at 12:28:19PM -0400, Jeremy Hylton wrote:
>release cycle, e.g. Python-2.0.tar.gz.  I don't know if that's the GNU
>standard or not (didn't realize it was a standard; don't know where to
>find said standard; or is it just a custom?)

See http://www.cs.utah.edu/dept/old/texinfo/standards/standards.html#SEC24
Though I think here the standard is just codifying an existing custom
that's proved convenient.

www.fsf.org seems unresponsive at the moment, hence the strange link;
is *every* Web site in the world breaking today for some reason?

--amk





From akuchlin at mems-exchange.org  Fri Oct 20 18:28:10 2000
From: akuchlin at mems-exchange.org (Andrew Kuchling)
Date: Fri, 20 Oct 2000 12:28:10 -0400
Subject: [Python-Dev] 2.0 articles
In-Reply-To: <14832.29555.123226.831103@bitdiddle.concentric.net>; from jeremy@alum.mit.edu on Fri, Oct 20, 2000 at 12:31:47PM -0400
References: <20001019122037.C21214@kronos.cnri.reston.va.us> <Pine.LNX.4.10.10010191237320.8628-100000@akbar.nevex.com> <20001019133208.D21214@kronos.cnri.reston.va.us> <14832.29555.123226.831103@bitdiddle.concentric.net>
Message-ID: <20001020122810.B9679@kronos.cnri.reston.va.us>

On Fri, Oct 20, 2000 at 12:31:47PM -0400, Jeremy Hylton wrote:
>And, of course, there's the Python conference: http://python9.org/

That's preaching to the converted, though.  

--amk



From fdrake at acm.org  Fri Oct 20 18:51:44 2000
From: fdrake at acm.org (Fred L. Drake, Jr.)
Date: Fri, 20 Oct 2000 12:51:44 -0400 (EDT)
Subject: [Python-Dev] This Project Has Not Released Any Files
In-Reply-To: <14832.29347.622325.95025@bitdiddle.concentric.net>
References: <200010191731.TAA01114@loewis.home.cs.tu-berlin.de>
	<20001019134219.A29218@kronos.cnri.reston.va.us>
	<20001019115436.X31108@lyra.org>
	<14832.29347.622325.95025@bitdiddle.concentric.net>
Message-ID: <14832.30752.210553.712758@cj42289-a.reston1.va.home.com>

Jeremy Hylton writes:
 > In the interest of making the distribution as widely available as
 > possible, I've placed files on SourceForge and at
 > http://www.python.org/2.0/

  There's a separate python-rpms "Package"; the RPM files should go
there (I think).


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at acm.org>
PythonLabs Team Member




From thomas at xs4all.net  Fri Oct 20 22:21:18 2000
From: thomas at xs4all.net (Thomas Wouters)
Date: Fri, 20 Oct 2000 22:21:18 +0200
Subject: [Python-Dev] Re: Compiling python 2.0
In-Reply-To: <m37l73s8r3.fsf@atrus.jesus.cam.ac.uk>; from mwh21@cam.ac.uk on Fri, Oct 20, 2000 at 06:49:36PM +0100
References: <L3JH5.990$yK.3812548@nnrp3.proxad.net> <m37l73s8r3.fsf@atrus.jesus.cam.ac.uk>
Message-ID: <20001020222118.M12812@xs4all.nl>

On Fri, Oct 20, 2000 at 06:49:36PM +0100, Michael Hudson wrote:
> "Jean-Claude Levieux" <jclevieux at sud2000.com> writes:

> > I just tried to compile Python 2.0.
> > on BSDI BSD/OS 4.0.1

[ Sorry, missed the original message. Used the Archive to find it, tho ]

> Random guess, but you are using a ANSI C compiler, aren't you?  Python
> 2.0 now demands that.

BSDI uses gcc, so that's not the problem. Neither are these three warnings:

/usr/include/math.h:177: warning: function declaration isn't a prototype
/usr/include/math.h:257: warning: function declaration isn't a prototype
/usr/include/wchar.h:17: warning: function declaration isn't a prototype

(or any other warnings regarding 'function decl isn't a prototype)

They are a result of Python using '-Wstrict-prototypes' by default, if the
compiler is gcc. It just means BSDI declares a few functions without
specifying argument lists (prototypes) and has nothing to do with Python
(other than that Python always defines CFLAGS to contain
-Wstrict-prototypes.) There isn't an easy way to get this 'fixed',
unfortunately. If you want to quench the warnings, you'll have to edit
./Makefile, Objects/Makefile, Parser/Makefile, Python/Makefile,
and ./Modules/Makefile.pre. (Do not edit ./Modules/Makefile directly,
because it's overwritten by the 'makesetup' script, which parses the Setup
file.)

As for the other error, that's really an error :(

../libpython2.0.a(fileobject.o): In function portable_fseek':
/usr/home/thomas/Python-2.0/Objects/fileobject.c:274: undefined
reference to `TELL64'

The problem is that BSDI has an 'off_t' type that is larger than the 'long'
type, and Python's configure makes the flawed assumption that this means
BSDI supports large files (larger than 2Gb.) However, BSDI doesn't. This bug
is even present with BSDI 4.1, and probably more platforms. You can fix this
by editing './config.h' after running './configure', and commenting out the
HAVE_LARGEFILE_SUPPORT line; changing this:

#define HAVE_LARGEFILE_SUPPORT 1

into something like this:

/* #define HAVE_LARGEFILE_SUPPORT 1 */

(You can just remove the line as well.) The downside of both these 'hacks'
(excuse me, 'hotfixes'), is that you'll have to reedit the files again after
running configure again (or something that runs configure, like
'config.status'.)

I see a total of three bugs here: Python adds -Wstrict-prototypes even
though it can generate a lot of warnings that aren't related to Python;
there is no way to override the CFLAGS variable (you can pass it to
configure, and it uses it at first, but then just overwrites it); and
mis-detecting large file support. I can't decide which of the last two is
the biggest bug :-)

I would write a patch for the lot of 'm, but I'm in the middle of getting
ready to head to London for the Apache conference (any other Pythonistas
going ? :) and Have I Got News For You is about to start on BBC1. If you
don't do it, Jean-Claude, I'll submit bugreports on these when I'm back,
next Thursday.

(Oh, another hint: *disable threads* when compiling Python for BSDI 4.0.1.
You can leave them on for 4.1, but 4.0.1 has very broken threads, and it
will cause lots of problems in the signal module if you leave them on. You
can disable them by using '--with-threads=no' -- this is also listed in the
README, by the way. And note that BSDI 4.1 only has the large file support
problem, none of the others, and I strongly suggest upgrading for other
reasons as well.)

Python-dev: CC'd because this is material for a bugfix-release. There are
likely to be other platforms hit by the large filesupport misdetection.
Don't think this is enough to warrant a bugfix release (it's not *that*
brownbaggy) but it should definately go in if there is one ;P If I or
someone else didn't fix it by the time a bugfix release is considered,
please hit me. I also appologize for not properly testing Python 2.0 on BSDI
4.0.1 or 4.1... We still have those machines, but we are using less and less
of them. Out of sight, out of mind, and I'm happier using FreeBSD and Linux
:)

BSDI-isn't-all-bad--it's-just-that-by-now-Linux-and-FreeBSD-have-all-
	-those-good-sides-too-ly y'rs,

-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!



From trentm at ActiveState.com  Fri Oct 20 22:54:59 2000
From: trentm at ActiveState.com (Trent Mick)
Date: Fri, 20 Oct 2000 13:54:59 -0700
Subject: [Python-Dev] Re: Compiling python 2.0
In-Reply-To: <20001020222118.M12812@xs4all.nl>; from thomas@xs4all.net on Fri, Oct 20, 2000 at 10:21:18PM +0200
References: <L3JH5.990$yK.3812548@nnrp3.proxad.net> <m37l73s8r3.fsf@atrus.jesus.cam.ac.uk> <20001020222118.M12812@xs4all.nl>
Message-ID: <20001020135459.C1562@ActiveState.com>

On Fri, Oct 20, 2000 at 10:21:18PM +0200, Thomas Wouters wrote:
> As for the other error, that's really an error :(
> 
> ../libpython2.0.a(fileobject.o): In function portable_fseek':
> /usr/home/thomas/Python-2.0/Objects/fileobject.c:274: undefined
> reference to `TELL64'
> 
> The problem is that BSDI has an 'off_t' type that is larger than the 'long'
> type, and Python's configure makes the flawed assumption that this means
> BSDI supports large files (larger than 2Gb.) However, BSDI doesn't. This bug
> is even present with BSDI 4.1, and probably more platforms. You can fix this
> by editing './config.h' after running './configure', and commenting out the
> HAVE_LARGEFILE_SUPPORT line; changing this:
> 
> #define HAVE_LARGEFILE_SUPPORT 1
> 
> into something like this:
> 
> /* #define HAVE_LARGEFILE_SUPPORT 1 */
> 
> (You can just remove the line as well.) The downside of both these 'hacks'
> (excuse me, 'hotfixes'), is that you'll have to reedit the files again after
> running configure again (or something that runs configure, like
> 'config.status'.)

This one isthe saem problem that showed up for NetBSD1.4.2 and OpenBSD (I see
a pattern)
http://sourceforge.net/bugs/?func=detailbug&bug_id=112289&group_id=5470

It was fixed by adding a hack in fileobject.c to *define* TELL64.
http://sourceforge.net/patch/index.php?func=detailpatch&patch_id=101558&group_id=5470

For the quickfix, the same hack could be used for BSDI.

As you suggest Thomas, the proper fix is to patch configure.in such that it
does not report that these system support largefiles.

I don't have the time to do this right away, nor do I have one of these boxes
on which to test it. I can try to make a patch though. We don't you file a
bug and assign it to me.

Trent


-- 
Trent Mick
TrentM at ActiveState.com



From martin at loewis.home.cs.tu-berlin.de  Fri Oct 20 22:54:02 2000
From: martin at loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Fri, 20 Oct 2000 22:54:02 +0200
Subject: [Python-Dev] This Project Has Released Files
Message-ID: <200010202054.WAA01567@loewis.home.cs.tu-berlin.de>

> In the interest of making the distribution as widely available as
> possible, I've placed files on SourceForge and at
> http://www.python.org/2.0/

Thanks! also to anybody else contributing to the release process, in
particular to amk for his ongoing maintainance of various pieces on
python.org, and his efforts in getting the word out.

Regards,
Martin



From cgw at fnal.gov  Fri Oct 13 17:11:03 2000
From: cgw at fnal.gov (Charles G Waldman)
Date: Fri, 13 Oct 2000 10:11:03 -0500 (CDT)
Subject: [Python-Dev] can't build with threads on OSF/1
Message-ID: <14823.9735.525711.927269@buffalo.fnal.gov>

Sorry, I don't have time to investigate this fully right now.  Maybe
this weekend.  For now this is just a heads-up.  Hopefully, something
is just misconfigured on this system.

The machine in question is running OSF1 V4.0 878 alpha

I can only build Python from current CVS sources on OSF/1 if I specify
--without-thread.   If I don't specify this I get the following errors
at link time:

Unresolved:
__pthread_mutex_init
__pthread_mutex_destroy
__pthread_mutex_lock
__pthread_mutex_unlock
__pthread_cond_init
__pthread_cond_destroy
__pthread_cond_signal
__pthread_cond_wait
__pthread_create
__pthread_detach


Below find the output of cc -V as well as the output of ./configure
and make (sorry for the flood,  I assume too much detail is better
than not enough)

creating cache ./config.cache
checking MACHDEP... osf1V4
checking for --without-gcc... 
checking for --with-cxx=<compiler>... no
checking for gcc... cc
checking whether the C compiler (cc   ) works... yes
checking whether the C compiler (cc   ) is a cross-compiler... no
checking whether we are using GNU C... no
checking whether cc accepts -g... yes
checking for --with-suffix... 
checking LINKCC... $(PURIFY) $(CC)
checking LDLIBRARY... 
checking for ranlib... ranlib
checking for ar... ar
checking how to run the C preprocessor... cc -E
checking for AIX... no
checking for minix/config.h... no
checking whether cc accepts -OPT:Olimit=0... no
checking whether cc accepts -Olimit 1500... yes
checking for ANSI C header files... yes
checking for dlfcn.h... yes
checking for fcntl.h... yes
checking for limits.h... yes
checking for locale.h... yes
checking for ncurses.h... no
checking for poll.h... yes
checking for pthread.h... yes
checking for signal.h... yes
checking for stdarg.h... yes
checking for stddef.h... yes
checking for stdlib.h... yes
checking for thread.h... no
checking for unistd.h... yes
checking for utime.h... yes
checking for sys/audioio.h... no
checking for sys/file.h... yes
checking for sys/lock.h... yes
checking for db_185.h... no
checking for db.h... yes
checking for sys/param.h... yes
checking for sys/select.h... yes
checking for sys/socket.h... yes
checking for sys/time.h... yes
checking for sys/times.h... yes
checking for sys/un.h... yes
checking for sys/utsname.h... yes
checking for sys/wait.h... yes
checking for pty.h... yes
checking for libutil.h... no
checking for ndbm.h... yes
checking for db1/ndbm.h... no
checking for gdbm/ndbm.h... no
checking for dirent.h that defines DIR... yes
checking for opendir in -ldir... no
checking for clock_t in time.h... yes
checking for mode_t... yes
checking for off_t... yes
checking for pid_t... yes
checking return type of signal handlers... void
checking for size_t... yes
checking for uid_t in sys/types.h... yes
checking size of int... 4
checking size of long... 8
checking size of void *... 8
checking size of char... 1
checking size of short... 2
checking size of float... 4
checking size of double... 8
checking size of fpos_t... 8
checking for long long support... yes
checking size of long long... 8
checking for uintptr_t support... no
checking size of off_t... 8
checking whether to enable large file support... no
checking size of time_t... 4
checking for pthread_t... yes
checking size of pthread_t... 8
checking for --with-next-framework... no
checking for --with-dyld... no
checking SO... .so
checking LDSHARED... ld -shared -expect_unresolved "*"
checking CCSHARED... 
checking LINKFORSHARED... 
checking for dlopen in -ldl... no
checking for shl_load in -ldld... no
checking for --with-pydebug... no
checking for t_open in -lnsl... no
checking for socket in -lsocket... no
checking for --with-libs... no
checking for --with-dec-threads... no
checking for --with-threads... yes
checking for mach/cthreads.h... no
checking for --with-pth... no
checking for pthread_create in -lpthread... no
checking for pthread_detach... no
checking for kernel/OS.h... no
checking for pthread_create in -lpthreads... yes
checking for usconfig in -lmpc... no
checking for thr_create in -lthread... no
checking for --with-cycle-gc... yes
checking for --with-libdb... yes
checking for dbopen... no
checking for --with-wctype-functions... no
checking for --with-sgi-dl... no
checking for --with-dl-dld... no
checking for dlopen... yes
checking DYNLOADFILE... dynload_shlib.o
checking for alarm... yes
checking for chown... yes
checking for clock... yes
checking for confstr... yes
checking for ctermid... yes
checking for ctermid_r... no
checking for execv... yes
checking for flock... yes
checking for fork... yes
checking for fsync... yes
checking for fdatasync... yes
checking for fpathconf... yes
checking for ftime... yes
checking for ftruncate... yes
checking for getgroups... yes
checking for getlogin... yes
checking for getpeername... yes
checking for getpid... yes
checking for getpwent... yes
checking for getwd... yes
checking for kill... yes
checking for link... yes
checking for lstat... yes
checking for mkfifo... yes
checking for mktime... yes
checking for mremap... no
checking for nice... yes
checking for pathconf... yes
checking for pause... yes
checking for plock... yes
checking for poll... yes
checking for pthread_init... no
checking for putenv... yes
checking for readlink... yes
checking for select... yes
checking for setegid... yes
checking for seteuid... yes
checking for setgid... yes
checking for setlocale... yes
checking for setregid... yes
checking for setreuid... yes
checking for setsid... yes
checking for setpgid... yes
checking for setuid... yes
checking for setvbuf... yes
checking for sigaction... yes
checking for siginterrupt... yes
checking for sigrelse... yes
checking for strftime... yes
checking for strptime... yes
checking for symlink... yes
checking for sysconf... yes
checking for tcgetpgrp... yes
checking for tcsetpgrp... yes
checking for tempnam... yes
checking for timegm... no
checking for times... yes
checking for tmpfile... yes
checking for tmpnam... yes
checking for tmpnam_r... no
checking for truncate... yes
checking for uname... yes
checking for waitpid... yes
checking for _getpty... no
checking for openpty... yes
checking for forkpty... yes
checking for fseek64... no
checking for fseeko... no
checking for fstatvfs... yes
checking for ftell64... no
checking for ftello... no
checking for statvfs... yes
checking for dup2... yes
checking for getcwd... yes
checking for strdup... yes
checking for strerror... yes
checking for memmove... yes
checking for getpgrp... yes
checking for setpgrp... yes
checking for gettimeofday... yes
checking whether time.h and sys/time.h may both be included... yes
checking whether struct tm is in sys/time.h or time.h... time.h
checking for member tm_zone in aggregate type struct tm... yes
checking for time.h that defines altzone... no
checking whether sys/select.h and sys/time.h may both be included... yes
checking whether char is unsigned... no
checking for working const... yes
checking for inline... __inline
checking for working volatile... yes
checking for working signed char... yes
checking for prototypes... yes
checking for variable length prototypes and stdarg.h... yes
checking for bad exec* prototypes... no
checking for bad static forward... no
checking whether va_list is an array... no
checking for gethostbyname_r... yes
checking gethostbyname_r with 6 args... yes
checking for __fpu_control... no
checking for __fpu_control in -lieee... no
checking for --with-fpectl... no
checking for --with-libm=STRING... default LIBM="-lm"
checking for --with-libc=STRING... default LIBC=""
checking for hypot... yes
checking for genuine getopt... yes
checking what malloc(0) returns... null
checking for wchar.h... yes
checking for usable wchar_t... no
checking whether byte ordering is bigendian... no
checking whether right shift extends the sign bit... yes
checking for socklen_t... no
updating cache ./config.cache
creating ./config.status
creating Makefile
creating Objects/Makefile
creating Parser/Makefile
creating Grammar/Makefile
creating Python/Makefile
creating Modules/Makefile.pre
creating Modules/Setup.config
creating config.h


(cd Modules; make -f Makefile.pre Makefile)
+ cp ./Setup.in Setup 
rm -rf ../libpython2.0.a
/bin/sh ./makesetup Setup.config Setup.local Setup
making Makefile in subdirectory .
`Makefile' is up to date.
making Makefile in subdirectory Parser
`Makefile' is up to date.
making Makefile in subdirectory Grammar
`Makefile' is up to date.
making Makefile in subdirectory Objects
`Makefile' is up to date.
making Makefile in subdirectory Python
`Makefile' is up to date.
making Makefile in subdirectory Modules
`Makefile' is up to date.
(rm -f Modules/hassignal; cd Modules; make hassignal)
rm -f hassignal
for i in threadmodule.o  gcmodule.o  bsddbmodule.o  regexmodule.o regexpr.o  pcremodule.o pypcre.o  posixmodule.o  signalmodule.o  _sre.o  arraymodule.o  cmathmodule.o  mathmodule.o  stropmodule.o  structmodule.o  timemodule.o  operator.o  _codecsmodule.o  unicodedata.o unicodedatabase.o  ucnhash.o  _localemodule.o  fcntlmodule.o  pwdmodule.o  grpmodule.o  errnomodule.o  selectmodule.o  socketmodule.o  mmapmodule.o  md5module.o md5c.o  shamodule.o  rotormodule.o  newmodule.o  binascii.o  parsermodule.o  cStringIO.o  cPickle.o config.o getpath.o main.o getbuildinfo.o; do  if test "$i" = "signalmodule.o"; then  echo yes >hassignal; break;  fi;  done
cd Parser ; make OPT="-O -Olimit 1500" VERSION="2.0"  prefix="/usr/local" exec_prefix="/usr/local" all
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c pgenmain.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c acceler.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c grammar1.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c listnode.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c node.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c parser.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c parsetok.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c tokenizer.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c bitset.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c metagrammar.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c firstsets.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c grammar.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c pgen.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c printgrammar.c
cc -O -Olimit 1500 pgenmain.o acceler.o grammar1.o  listnode.o node.o parser.o  parsetok.o tokenizer.o bitset.o  metagrammar.o firstsets.o grammar.o pgen.o printgrammar.o -lpthreads -o pgen
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c myreadline.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c intrcheck.c
cc: Warning: /usr/include/unistd.h, line 243: The redefinition of the macro "_POSIX_THREADS" conflicts with a current definition because the replacement lists differ.  The redefinition is now in effect.
#define	_POSIX_THREADS		/* 1003.1c (pthreads) comformant */
-------------------------------------------------------------------^
cd Grammar ; make OPT="-O -Olimit 1500" VERSION="2.0"  prefix="/usr/local" exec_prefix="/usr/local" all
../Parser/pgen ./Grammar
Compiling (meta-) parse tree into NFA grammar
Making DFA for 'single_input' ...
Making DFA for 'file_input' ...
Making DFA for 'eval_input' ...
Making DFA for 'funcdef' ...
Making DFA for 'parameters' ...
Making DFA for 'varargslist' ...
Making DFA for 'fpdef' ...
Making DFA for 'fplist' ...
Making DFA for 'stmt' ...
Making DFA for 'simple_stmt' ...
Making DFA for 'small_stmt' ...
Making DFA for 'expr_stmt' ...
Making DFA for 'augassign' ...
Making DFA for 'print_stmt' ...
Making DFA for 'del_stmt' ...
Making DFA for 'pass_stmt' ...
Making DFA for 'flow_stmt' ...
Making DFA for 'break_stmt' ...
Making DFA for 'continue_stmt' ...
Making DFA for 'return_stmt' ...
Making DFA for 'raise_stmt' ...
Making DFA for 'import_stmt' ...
Making DFA for 'import_as_name' ...
Making DFA for 'dotted_as_name' ...
Making DFA for 'dotted_name' ...
Making DFA for 'global_stmt' ...
Making DFA for 'exec_stmt' ...
Making DFA for 'assert_stmt' ...
Making DFA for 'compound_stmt' ...
Making DFA for 'if_stmt' ...
Making DFA for 'while_stmt' ...
Making DFA for 'for_stmt' ...
Making DFA for 'try_stmt' ...
Making DFA for 'except_clause' ...
Making DFA for 'suite' ...
Making DFA for 'test' ...
Making DFA for 'and_test' ...
Making DFA for 'not_test' ...
Making DFA for 'comparison' ...
Making DFA for 'comp_op' ...
Making DFA for 'expr' ...
Making DFA for 'xor_expr' ...
Making DFA for 'and_expr' ...
Making DFA for 'shift_expr' ...
Making DFA for 'arith_expr' ...
Making DFA for 'term' ...
Making DFA for 'factor' ...
Making DFA for 'power' ...
Making DFA for 'atom' ...
Making DFA for 'listmaker' ...
Making DFA for 'lambdef' ...
Making DFA for 'trailer' ...
Making DFA for 'subscriptlist' ...
Making DFA for 'subscript' ...
Making DFA for 'sliceop' ...
Making DFA for 'exprlist' ...
Making DFA for 'testlist' ...
Making DFA for 'dictmaker' ...
Making DFA for 'classdef' ...
Making DFA for 'arglist' ...
Making DFA for 'argument' ...
Making DFA for 'list_iter' ...
Making DFA for 'list_for' ...
Making DFA for 'list_if' ...
Adding FIRST sets ...
Writing graminit.c ...
Writing graminit.h ...
cp graminit.h ./../Include/graminit.h
cp graminit.c ./../Python/graminit.c
cd Objects ; make OPT="-O -Olimit 1500" VERSION="2.0"  prefix="/usr/local" exec_prefix="/usr/local" all
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c abstract.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c bufferobject.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c classobject.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c cobject.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c complexobject.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c fileobject.c
cc: Warning: /usr/include/unistd.h, line 243: The redefinition of the macro "_POSIX_THREADS" conflicts with a current definition because the replacement lists differ.  The redefinition is now in effect.
#define	_POSIX_THREADS		/* 1003.1c (pthreads) comformant */
-------------------------------------------------------------------^
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c floatobject.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c frameobject.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c funcobject.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c intobject.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c listobject.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c longobject.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c dictobject.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c methodobject.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c moduleobject.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c object.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c rangeobject.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c sliceobject.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c stringobject.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c tupleobject.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c typeobject.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c unicodeobject.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c unicodectype.c
cd Python ; make OPT="-O -Olimit 1500" VERSION="2.0"  prefix="/usr/local" exec_prefix="/usr/local" all
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c bltinmodule.c
cc: Warning: /usr/include/unistd.h, line 243: The redefinition of the macro "_POSIX_THREADS" conflicts with a current definition because the replacement lists differ.  The redefinition is now in effect.
#define	_POSIX_THREADS		/* 1003.1c (pthreads) comformant */
-------------------------------------------------------------------^
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c exceptions.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ceval.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c compile.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c codecs.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c errors.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c frozen.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c frozenmain.c
cc: Warning: /usr/include/unistd.h, line 243: The redefinition of the macro "_POSIX_THREADS" conflicts with a current definition because the replacement lists differ.  The redefinition is now in effect.
#define	_POSIX_THREADS		/* 1003.1c (pthreads) comformant */
-------------------------------------------------------------------^
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c getargs.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c getcompiler.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c getcopyright.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c getmtime.c
cc -c -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -DPLATFORM='"osf1V4"'  ./getplatform.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c getversion.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c graminit.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c import.c
cc: Warning: /usr/include/unistd.h, line 243: The redefinition of the macro "_POSIX_THREADS" conflicts with a current definition because the replacement lists differ.  The redefinition is now in effect.
#define	_POSIX_THREADS		/* 1003.1c (pthreads) comformant */
-------------------------------------------------------------------^
cc -c -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -I/ ./importdl.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c marshal.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c modsupport.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c mystrtoul.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c pyfpe.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c pystate.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c pythonrun.c
cc: Warning: /usr/include/unistd.h, line 243: The redefinition of the macro "_POSIX_THREADS" conflicts with a current definition because the replacement lists differ.  The redefinition is now in effect.
#define	_POSIX_THREADS		/* 1003.1c (pthreads) comformant */
-------------------------------------------------------------------^
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c structmember.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c sysmodule.c
cc: Warning: /usr/include/unistd.h, line 243: The redefinition of the macro "_POSIX_THREADS" conflicts with a current definition because the replacement lists differ.  The redefinition is now in effect.
#define	_POSIX_THREADS		/* 1003.1c (pthreads) comformant */
-------------------------------------------------------------------^
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c traceback.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c dynload_shlib.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c thread.c
cc: Warning: /usr/include/unistd.h, line 243: The redefinition of the macro "_POSIX_THREADS" conflicts with a current definition because the replacement lists differ.  The redefinition is now in effect.
#define	_POSIX_THREADS		/* 1003.1c (pthreads) comformant */
-------------------------------------------------------------------^
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c sigcheck.c
cd Modules ; make OPT="-O -Olimit 1500" VERSION="2.0"  prefix="/usr/local" exec_prefix="/usr/local" all
cc  -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./threadmodule.c
cc  -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./gcmodule.c
cc  -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./bsddbmodule.c
cc  -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./regexmodule.c
cc  -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./regexpr.c
cc  -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./pcremodule.c
cc  -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./pypcre.c
cc  -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./posixmodule.c
cc: Warning: /usr/include/unistd.h, line 243: The redefinition of the macro "_POSIX_THREADS" conflicts with a current definition because the replacement lists differ.  The redefinition is now in effect.
#define	_POSIX_THREADS		/* 1003.1c (pthreads) comformant */
-------------------------------------------------------------------^
cc  -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./signalmodule.c
cc: Warning: /usr/include/unistd.h, line 243: The redefinition of the macro "_POSIX_THREADS" conflicts with a current definition because the replacement lists differ.  The redefinition is now in effect.
#define	_POSIX_THREADS		/* 1003.1c (pthreads) comformant */
-------------------------------------------------------------------^
cc  -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./_sre.c
cc  -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./arraymodule.c
cc  -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./cmathmodule.c
cc  -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./mathmodule.c
cc  -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./stropmodule.c
cc  -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./structmodule.c
cc  -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./timemodule.c
cc: Warning: /usr/include/unistd.h, line 243: The redefinition of the macro "_POSIX_THREADS" conflicts with a current definition because the replacement lists differ.  The redefinition is now in effect.
#define	_POSIX_THREADS		/* 1003.1c (pthreads) comformant */
-------------------------------------------------------------------^
cc  -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./operator.c
cc  -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./_codecsmodule.c
cc  -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./unicodedatabase.c
cc  -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./unicodedata.c
cc  -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./ucnhash.c
cc  -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./_localemodule.c
cc  -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./fcntlmodule.c
cc: Warning: /usr/include/unistd.h, line 243: The redefinition of the macro "_POSIX_THREADS" conflicts with a current definition because the replacement lists differ.  The redefinition is now in effect.
#define	_POSIX_THREADS		/* 1003.1c (pthreads) comformant */
-------------------------------------------------------------------^
cc  -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./pwdmodule.c
cc  -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./grpmodule.c
cc  -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./errnomodule.c
cc  -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./selectmodule.c
cc: Warning: /usr/include/unistd.h, line 243: The redefinition of the macro "_POSIX_THREADS" conflicts with a current definition because the replacement lists differ.  The redefinition is now in effect.
#define	_POSIX_THREADS		/* 1003.1c (pthreads) comformant */
-------------------------------------------------------------------^
cc  -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./socketmodule.c
cc: Warning: /usr/include/unistd.h, line 243: The redefinition of the macro "_POSIX_THREADS" conflicts with a current definition because the replacement lists differ.  The redefinition is now in effect.
#define	_POSIX_THREADS		/* 1003.1c (pthreads) comformant */
-------------------------------------------------------------------^
cc  -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./mmapmodule.c
cc: Warning: /usr/include/unistd.h, line 243: The redefinition of the macro "_POSIX_THREADS" conflicts with a current definition because the replacement lists differ.  The redefinition is now in effect.
#define	_POSIX_THREADS		/* 1003.1c (pthreads) comformant */
-------------------------------------------------------------------^
cc  -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./md5module.c
cc  -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./md5c.c
cc  -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./shamodule.c
cc  -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./rotormodule.c
cc  -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./newmodule.c
cc  -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./binascii.c
cc  -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./parsermodule.c
cc  -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./cStringIO.c
cc  -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c ./cPickle.c
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c config.c
cc -c -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -DPYTHONPATH='":plat-osf1V4:lib-tk"'  -DPREFIX='"/usr/local"'  -DEXEC_PREFIX='"/usr/local"'  -DVERSION='"2.0"'  -DVPATH='""'  ./getpath.c
cc: Warning: /usr/include/unistd.h, line 243: The redefinition of the macro "_POSIX_THREADS" conflicts with a current definition because the replacement lists differ.  The redefinition is now in effect.
#define	_POSIX_THREADS		/* 1003.1c (pthreads) comformant */
-------------------------------------------------------------------^
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c main.c
cc: Warning: /usr/include/unistd.h, line 243: The redefinition of the macro "_POSIX_THREADS" conflicts with a current definition because the replacement lists differ.  The redefinition is now in effect.
#define	_POSIX_THREADS		/* 1003.1c (pthreads) comformant */
-------------------------------------------------------------------^
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c getbuildinfo.c
if test ! -f libpython2.0.a;  then for i in Parser Grammar Objects Python Modules; do rm -f $i/add2lib; done; true;  else true; fi
for i in Parser Grammar Objects Python Modules; do  (cd $i; make VERSION="2.0" add2lib); done
ar cr ../libpython2.0.a acceler.o grammar1.o  listnode.o node.o parser.o  parsetok.o tokenizer.o bitset.o  metagrammar.o myreadline.o
if test ! -f ../Modules/hassignal;  then echo adding intrcheck.o; ar r ../libpython2.0.a intrcheck.o;  else echo leaving intrcheck.o out; fi
leaving intrcheck.o out
touch add2lib
ar cr ../libpython2.0.a abstract.o bufferobject.o  classobject.o cobject.o complexobject.o  fileobject.o floatobject.o  frameobject.o funcobject.o intobject.o listobject.o  longobject.o dictobject.o methodobject.o  moduleobject.o object.o rangeobject.o  sliceobject.o stringobject.o  tupleobject.o typeobject.o  unicodeobject.o unicodectype.o
touch add2lib
ar cr ../libpython2.0.a bltinmodule.o exceptions.o  ceval.o compile.o codecs.o  errors.o  frozen.o frozenmain.o  getargs.o getcompiler.o getcopyright.o getmtime.o  getplatform.o getversion.o graminit.o  import.o importdl.o  marshal.o modsupport.o mystrtoul.o  pyfpe.o pystate.o pythonrun.o  structmember.o sysmodule.o  traceback.o  dynload_shlib.o  thread.o
if test ! -f ../Modules/hassignal;  then echo adding sigcheck.o; ar r ../libpython2.0.a sigcheck.o;  else echo leaving sigcheck.o out; fi
leaving sigcheck.o out
touch add2lib
if test -f hassignal;  then echo removing sigcheck.o intrcheck.o;  ar d ../libpython2.0.a sigcheck.o intrcheck.o 2>/dev/null;  else echo leaving sigcheck.o intrcheck.o in; fi
removing sigcheck.o intrcheck.o
*** Exit 2 (ignored)
ar cr ../libpython2.0.a threadmodule.o  gcmodule.o  bsddbmodule.o  regexmodule.o regexpr.o  pcremodule.o pypcre.o  posixmodule.o  signalmodule.o  _sre.o  arraymodule.o  cmathmodule.o  mathmodule.o  stropmodule.o  structmodule.o  timemodule.o  operator.o  _codecsmodule.o  unicodedata.o unicodedatabase.o  ucnhash.o  _localemodule.o  fcntlmodule.o  pwdmodule.o  grpmodule.o  errnomodule.o  selectmodule.o  socketmodule.o  mmapmodule.o  md5module.o md5c.o  shamodule.o  rotormodule.o  newmodule.o  binascii.o  parsermodule.o  cStringIO.o  cPickle.o config.o getpath.o main.o getbuildinfo.o
touch add2lib
echo 0 >buildno
cd Modules; make OPT="-O -Olimit 1500" python.o
cc -O -Olimit 1500 -I./../Include -I.. -DHAVE_CONFIG_H -c python.c
expr `cat buildno` + 1 >buildno1
mv -f buildno1 buildno
cc -c -O -Olimit 1500 -I. -DHAVE_CONFIG_H -DBUILD=`cat buildno`  ./Modules/getbuildinfo.c
ar cr libpython2.0.a getbuildinfo.o
ranlib libpython2.0.a
true
cd Modules;  make OPT="-O -Olimit 1500" VERSION="2.0"  prefix="/usr/local" exec_prefix="/usr/local"  LIBRARY=../libpython2.0.a link
 cc   python.o  ../libpython2.0.a -ldb                                 -lpthreads -lm  -o python 
ld:
Unresolved:
__pthread_mutex_init
__pthread_mutex_destroy
__pthread_mutex_lock
__pthread_mutex_unlock
__pthread_cond_init
__pthread_cond_destroy
__pthread_cond_signal
__pthread_cond_wait
__pthread_create
__pthread_detach
*** Exit 1
Stop.
*** Exit 1
Stop.


DEC C V5.6-079 on Digital UNIX V4.0 (Rev. 878)
/usr/lib/cmplrs/cc/ld:
	$RCSfile: crt0.s,v $ $Revision: 1.1.21.11 $ (DEC) $Date: 1995/09/06 19:54:27 $
	$RCSfile: ld.c,v $ $Revision: 4.3.123.2 $ (DEC) $Date: 1998/10/06 19:53:55 $
	$RCSfile: doup.c,v $ $Revision: 1.1.3.2 $ (DEC) $Date: 1994/10/20 14:19:31 $
	$RCSfile: pass1.c,v $ $Revision: 4.3.59.5 $ (DEC) $Date: 1997/06/27 15:58:18 $
	$RCSfile: obj_file.c,v $ $Revision: 4.2.38.3 $ (DEC) $Date: 1997/05/06 13:00:05 $
	$RCSfile: file_tbl.c,v $ $Revision: 4.2.38.2 $ (DEC) $Date: 1996/07/08 14:08:20 $
	$RCSfile: fdmap.c,v $ $Revision: 4.2.18.2 $ (DEC) $Date: 1996/07/08 14:08:13 $
	$RCSfile: ext_tbl.c,v $ $Revision: 4.2.80.3 $ (DEC) $Date: 1997/03/17 15:01:44 $
	$RCSfile: extmap.c,v $ $Revision: 4.2.28.2 $ (DEC) $Date: 1996/07/08 14:08:07 $
	$RCSfile: read.c,v $ $Revision: 4.2.64.4 $ (DEC) $Date: 1997/09/30 18:52:59 $
	$RCSfile: read_malloc.c,v $ $Revision: 1.1.44.4 $ (DEC) $Date: 1997/09/30 18:53:01 $
	$RCSfile: layout.c,v $ $Revision: 4.2.111.9 $ (DEC) $Date: 1997/09/12 17:35:22 $
	$RCSfile: relocsym.c,v $ $Revision: 4.2.20.2 $ (DEC) $Date: 1997/02/26 20:47:45 $
	$RCSfile: write.c,v $ $Revision: 4.3.51.3 $ (DEC) $Date: 1996/09/18 17:56:40 $
	$RCSfile: pass2.c,v $ $Revision: 4.3.90.3 $ (DEC) $Date: 1997/03/17 15:03:09 $
	$RCSfile: extlink.c,v $ $Revision: 4.2.7.3 $ (DEC) $Date: 1994/08/05 17:55:56 $
	$RCSfile: tracesym.c,v $ $Revision: 4.2.7.3 $ (DEC) $Date: 1994/08/05 17:59:20 $
	$RCSfile: dn_tbl.c,v $ $Revision: 4.2.7.3 $ (DEC) $Date: 1994/08/05 17:54:50 $
	$RCSfile: dnmap.c,v $ $Revision: 4.2.6.3 $ (DEC) $Date: 1994/09/02 16:10:47 $
	$RCSfile: dynutil.c,v $ $Revision: 4.2.97.2 $ (DEC) $Date: 1998/10/06 19:53:44 $
	$RCSfile: mipscoff.c,v $ $Revision: 4.3.62.3 $ (DEC) $Date: 1997/03/17 15:02:52 $
	$RCSfile: dsoindirect.c,v $ $Revision: 4.2.15.2 $ (DEC) $Date: 1995/02/08 15:21:38 $
	$RCSfile: dsosymbol_table.c,v $ $Revision: 4.3.29.2 $ (DEC) $Date: 1995/10/26 17:16:39 $
	$RCSfile: dsomisc.c,v $ $Revision: 4.2.6.2 $ (DEC) $Date: 1994/08/05 17:55:23 $
	$RCSfile: dsomain.c,v $ $Revision: 4.2.16.3 $ (DEC) $Date: 1994/09/02 16:10:46 $
	$RCSfile: literal.c,v $ $Revision: 4.2.19.2 $ (DEC) $Date: 1995/08/31 18:10:41 $
	$RCSfile: elfhash.c,v $ $Revision: 4.1.25.2 $ (DEC) $Date: 1996/07/08 14:07:40 $
	$RCSfile: register.c,v $ $Revision: 4.2.22.5 $ (DEC) $Date: 1995/05/23 18:46:26 $
	$RCSfile: elf.c,v $ $Revision: 4.3.51.4 $ (DEC) $Date: 1997/05/06 13:00:03 $
	$RCSfile: uldgnum.c,v $ $Revision: 1.1.13.2 $ (DEC) $Date: 1994/10/20 16:22:50 $
	$RCSfile: op.c,v $ $Revision: 1.1.10.2 $ (DEC) $Date: 1994/08/05 17:57:05 $
	$RCSfile: dsoalphainst.c,v $ $Revision: 1.1.13.2 $ (DEC) $Date: 1996/02/02 21:50:45 $
	$RCSfile: alphaop_utils.c,v $ $Revision: 1.1.6.2 $ (DEC) $Date: 1994/08/05 17:54:48 $
	$RCSfile: smap.c,v $ $Revision: 1.1.4.2 $ (DEC) $Date: 1994/08/05 17:59:15 $
	$RCSfile: match.c,v $ $Revision: 4.2.29.3 $ (DEC) $Date: 1997/09/23 18:58:00 $
	$RCSfile: relocate.c,v $ $Revision: 1.1.82.6 $ (DEC) $Date: 1997/09/23 18:58:07 $
	$RCSfile: mgot.c,v $ $Revision: 1.1.46.2 $ (DEC) $Date: 1996/07/08 14:09:29 $
	$RCSfile: gprof.c,v $ $Revision: 1.1.21.2 $ (DEC) $Date: 1996/07/08 14:08:30 $
	$RCSfile: trampoline.c,v $ $Revision: 1.1.23.3 $ (DEC) $Date: 1997/06/20 18:46:07 $
	$RCSfile: gpinfo.c,v $ $Revision: 1.1.11.2 $ (DEC) $Date: 1996/07/08 14:08:23 $
	$RCSfile: stats.c,v $ $Revision: 1.1.8.2 $ (DEC) $Date: 1996/07/08 14:11:02 $
	$RCSfile: obj.c,v $ $Revision: 4.3.48.4 $ (DEC) $Date: 1997/05/29 19:26:42 $
	$RCSfile: wh1.c,v $ $Revision: 1.1.5.5 $ (DEC) $Date: 1995/11/03 18:57:55 $
	$RCSfile: cmrlc_produce.c,v $ $Revision: 1.1.17.3 $ (DEC) $Date: 1997/02/07 20:42:03 $
	$RCSfile: cmrlc_basic.c,v $ $Revision: 1.1.5.2 $ (DEC) $Date: 1995/02/15 16:45:57 $
	$RCSfile: decompresswh1.alpha.s,v $ $Revision: 1.1.2.3 $ (DEC) $Date: 1994/11/15 16:30:26 $
	$RCSfile: allocate.c,v $ $Revision: 1.1.3.3 $ (DEC) $Date: 1994/05/25 19:19:04 $
	$RCSfile: cmrlc_heur.c,v $ $Revision: 1.1.6.2 $ (DEC) $Date: 1995/09/07 17:18:18 $
	$RCSfile: ldgetname.c,v $ $Revision: 4.3.5.2 $ (DEC) $Date: 1994/05/26 18:09:48 $
	$RCSfile: scncomment.c,v $ $Revision: 4.1.12.2 $ (DEC) $Date: 1994/05/04 20:03:47 $
	$RCSfile: lderr.c,v $ $Revision: 1.1.2.2 $ (DEC) $Date: 1995/11/29 19:43:44 $
	$RCSfile: exit.c,v $ $Revision: 4.2.13.8 $ (DEC) $Date: 1996/04/22 20:54:54 $
	$RCSfile: signal.c,v $ $Revision: 4.3.9.2 $ (DEC) $Date: 1995/09/12 17:44:41 $
	$RCSfile: flsbuf.c,v $ $Revision: 4.2.15.2 $ (DEC) $Date: 1996/09/18 19:45:36 $
	$RCSfile: fopen.c,v $ $Revision: 4.2.11.3 $ (DEC) $Date: 1995/06/12 20:40:14 $
	$RCSfile: fprintf.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/04/04 21:28:13 $
	$RCSfile: scanf.c,v $ $Revision: 4.2.10.2 $ (DEC) $Date: 1994/04/05 15:45:13 $
	$RCSfile: printf.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/04/05 15:26:18 $
	$RCSfile: sprintf.c,v $ $Revision: 4.2.13.3 $ (DEC) $Date: 1995/12/14 23:46:41 $
	$RCSfile: fgets.c,v $ $Revision: 4.2.10.2 $ (DEC) $Date: 1994/11/23 20:11:27 $
	$RCSfile: NLSsetup.c,v $ $Revision: 1.1.13.7 $ (DEC) $Date: 1996/01/15 23:46:55 $
	$RCSfile: atoi.c,v $ $Revision: 4.2.10.2 $ (DEC) $Date: 1994/11/07 19:18:55 $
	$RCSfile: atol.c,v $ $Revision: 4.2.10.2 $ (DEC) $Date: 1994/11/07 19:19:01 $
	$RCSfile: malloc.c,v $ $Revision: 4.2.59.2 $ (DEC) $Date: 1998/04/09 14:55:23 $
	$RCSfile: system.c,v $ $Revision: 4.3.13.2 $ (DEC) $Date: 1994/08/03 14:34:15 $
	$RCSfile: strncmp.c,v $ $Revision: 4.2.11.4 $ (DEC) $Date: 1994/04/20 16:56:44 $
	$RCSfile: errlst.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/11/23 19:19:49 $
	$RCSfile: calloc.c,v $ $Revision: 4.2.8.3 $ (DEC) $Date: 1994/04/05 21:09:32 $
	$RCSfile: strncpy.c,v $ $Revision: 4.2.7.2 $ (DEC) $Date: 1994/04/05 15:48:58 $
	$RCSfile: abort.c,v $ $Revision: 4.2.11.3 $ (DEC) $Date: 1995/06/12 20:38:42 $
	$RCSfile: vfprintf.c,v $ $Revision: 4.2.7.2 $ (DEC) $Date: 1994/04/05 16:15:00 $
	$RCSfile: sysconf.c,v $ $Revision: 4.3.27.2 $ (DEC) $Date: 1996/12/03 21:50:05 $
	$RCSfile: qsort.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/11/23 19:23:30 $
	$RCSfile: filbuf.c,v $ $Revision: 4.2.13.3 $ (DEC) $Date: 1995/06/12 20:39:59 $
	$RCSfile: isspace.c,v $ $Revision: 4.2.8.3 $ (DEC) $Date: 1994/05/31 18:13:48 $
	$RCSfile: time.c,v $ $Revision: 4.2.7.2 $ (DEC) $Date: 1994/04/05 16:12:12 $
	$RCSfile: strncat.c,v $ $Revision: 4.2.10.2 $ (DEC) $Date: 1996/02/16 21:06:27 $
	$RCSfile: Ustrtok.c,v $ $Revision: 1.1.2.2 $ (DEC) $Date: 1994/11/23 19:18:34 $
	$RCSfile: strtok.c,v $ $Revision: 4.2.7.2 $ (DEC) $Date: 1994/04/05 15:49:33 $
	$RCSfile: strtol.c,v $ $Revision: 4.3.13.2 $ (DEC) $Date: 1994/08/03 14:33:56 $
	$RCSfile: fseek.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/04/04 21:28:42 $
	$RCSfile: ftell.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/04/04 21:28:58 $
	$RCSfile: strcspn.c,v $ $Revision: 4.2.7.2 $ (DEC) $Date: 1994/04/05 15:48:25 $
	$RCSfile: cfork.c,v $ $Revision: 1.1.3.7 $ (DEC) $Date: 1996/01/24 16:16:02 $
	$RCSfile: brks.c,v $ $Revision: 1.1.2.4 $ (DEC) $Date: 1995/08/30 19:21:18 $
	$RCSfile: nano_timers.c,v $ $Revision: 4.3.14.3 $ (DEC) $Date: 1995/06/12 20:42:02 $
	$RCSfile: assert.c,v $ $Revision: 4.2.9.3 $ (DEC) $Date: 1994/04/05 21:09:04 $
	$RCSfile: mktemp.c,v $ $Revision: 4.2.10.2 $ (DEC) $Date: 1995/08/29 17:56:51 $
	$RCSfile: fread.c,v $ $Revision: 4.3.12.3 $ (DEC) $Date: 1995/07/28 14:53:14 $
	$RCSfile: strdup.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/11/23 19:24:39 $
	$RCSfile: strcasecmp.c,v $ $Revision: 4.2.11.2 $ (DEC) $Date: 1994/11/10 14:57:27 $
	$RCSfile: a64l.c,v $ $Revision: 4.2.9.6 $ (DEC) $Date: 1995/06/28 16:00:16 $
	$RCSfile: sigops.c,v $ $Revision: 4.2.10.2 $ (DEC) $Date: 1994/04/05 15:47:12 $
	$RCSfile: tis.c,v $ $Revision: 1.1.14.5 $ (DEC) $Date: 1997/05/02 19:32:15 $
	$RCSfile: init_libc.c,v $ $Revision: 1.1.32.2 $ (DEC) $Date: 1998/08/06 21:11:39 $
	$RCSfile: ldr_atexit.c,v $ $Revision: 4.2.17.2 $ (DEC) $Date: 1998/03/23 20:01:58 $
	$RCSfile: write_nc.c,v $ $Revision: 1.1.7.2 $ (DEC) $Date: 1997/09/23 14:15:37 $
	$RCSfile: close_nc.c,v $ $Revision: 1.1.7.2 $ (DEC) $Date: 1997/09/23 14:15:32 $
	$RCSfile: isatty.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/04/04 21:44:10 $
	$RCSfile: tis_pthread.c,v $ $Revision: 1.1.5.3 $ (DEC) $Date: 1996/12/18 20:37:50 $
	$RCSfile: open_nc.c,v $ $Revision: 1.1.7.2 $ (DEC) $Date: 1997/09/23 14:15:33 $
	$RCSfile: findiop.c,v $ $Revision: 4.2.12.4 $ (DEC) $Date: 1995/06/12 20:40:02 $
	$RCSfile: doprnt.c,v $ $Revision: 4.2.58.2 $ (DEC) $Date: 1998/07/29 16:22:47 $
	$RCSfile: doscan.c,v $ $Revision: 4.3.40.2 $ (DEC) $Date: 1998/06/15 20:58:58 $
	$RCSfile: ecvt.c,v $ $Revision: 4.2.19.2 $ (DEC) $Date: 1996/04/17 17:50:54 $
	$RCSfile: errno.c,v $ $Revision: 1.1.8.4 $ (DEC) $Date: 1994/04/05 22:09:26 $
	$RCSfile: mallocdata.c,v $ $Revision: 1.1.4.4 $ (DEC) $Date: 1996/02/08 19:08:30 $
	$RCSfile: waitpid.c,v $ $Revision: 4.2.9.3 $ (DEC) $Date: 1995/10/30 21:48:36 $
	$RCSfile: raise.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1995/10/27 19:40:45 $
	$RCSfile: siglist.c,v $ $Revision: 4.2.9.3 $ (DEC) $Date: 1995/02/08 22:02:42 $
	$RCSfile: read_nc.c,v $ $Revision: 1.1.7.2 $ (DEC) $Date: 1997/09/23 14:15:35 $
	$RCSfile: iswctype.c,v $ $Revision: 1.1.12.2 $ (DEC) $Date: 1994/11/23 19:21:20 $
	$RCSfile: strspn.c,v $ $Revision: 4.2.7.2 $ (DEC) $Date: 1994/04/05 15:49:15 $
	$RCSfile: strpbrk.c,v $ $Revision: 4.2.7.2 $ (DEC) $Date: 1994/04/05 15:49:04 $
	$RCSfile: atfork.c,v $ $Revision: 1.1.2.4 $ (DEC) $Date: 1995/08/25 20:52:45 $
	$RCSfile: catopen.c,v $ $Revision: 4.3.18.5 $ (DEC) $Date: 1995/09/25 21:03:54 $
	$RCSfile: catgets.c,v $ $Revision: 4.2.10.3 $ (DEC) $Date: 1994/04/05 21:09:37 $
	$RCSfile: rec_mutex.c,v $ $Revision: 1.1.8.2 $ (DEC) $Date: 1997/06/24 19:15:05 $
	$RCSfile: sleep.c,v $ $Revision: 4.2.9.5 $ (DEC) $Date: 1995/10/31 15:54:41 $
	$RCSfile: schyield.s,v $ $Revision: 1.1.2.2 $ (DEC) $Date: 1995/09/27 17:08:25 $
	$RCSfile: tis_rwlock.c,v $ $Revision: 1.1.5.2 $ (DEC) $Date: 1996/12/03 20:38:25 $
	$RCSfile: ldr_dummy.c,v $ $Revision: 4.2.15.2 $ (DEC) $Date: 1997/10/13 21:06:11 $
	$RCSfile: ldr_status.c,v $ $Revision: 4.2.8.3 $ (DEC) $Date: 1994/04/05 15:05:50 $
	$RCSfile: sched_yield.c,v $ $Revision: 1.1.2.2 $ (DEC) $Date: 1995/11/16 21:59:12 $
	$RCSfile: Ufwrite.c,v $ $Revision: 1.1.2.2 $ (DEC) $Date: 1994/11/23 20:11:24 $
	$RCSfile: fwrite.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/11/23 20:11:38 $
	$RCSfile: __getmbcurmax.c,v $ $Revision: 1.1.7.2 $ (DEC) $Date: 1994/04/05 16:51:10 $
	$RCSfile: wcstombs.c,v $ $Revision: 4.2.7.3 $ (DEC) $Date: 1994/05/31 18:15:14 $
	$RCSfile: wctomb.c,v $ $Revision: 4.2.11.2 $ (DEC) $Date: 1997/07/15 17:35:42 $
	$RCSfile: localeconv.c,v $ $Revision: 4.2.7.3 $ (DEC) $Date: 1994/05/31 18:14:20 $
	$RCSfile: wcslen.c,v $ $Revision: 4.2.9.3 $ (DEC) $Date: 1995/03/09 18:40:34 $
	$RCSfile: mblen.c,v $ $Revision: 4.2.7.3 $ (DEC) $Date: 1994/05/31 18:14:22 $
	$RCSfile: mbtowc.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1995/02/09 15:37:35 $
	$RCSfile: strtod.c,v $ $Revision: 4.2.15.3 $ (DEC) $Date: 1994/08/16 20:01:29 $
	$RCSfile: strtoul.c,v $ $Revision: 4.2.12.2 $ (DEC) $Date: 1994/08/03 14:34:11 $
	$RCSfile: strstr.c,v $ $Revision: 4.2.7.2 $ (DEC) $Date: 1994/04/05 15:49:20 $
	$RCSfile: ungetwc.c,v $ $Revision: 4.2.12.3 $ (DEC) $Date: 1995/05/04 20:48:07 $
	$RCSfile: setlocale.c,v $ $Revision: 4.4.18.4 $ (DEC) $Date: 1995/04/27 20:15:29 $
	$RCSfile: getenv.c,v $ $Revision: 4.2.11.4 $ (DEC) $Date: 1995/06/12 20:40:24 $
	$RCSfile: basename.c,v $ $Revision: 4.2.12.2 $ (DEC) $Date: 1996/09/16 19:39:28 $
	$RCSfile: __ispriv.c,v $ $Revision: 1.1.9.2 $ (DEC) $Date: 1995/09/25 21:03:53 $
	$RCSfile: bsearch.c,v $ $Revision: 4.2.6.3 $ (DEC) $Date: 1994/04/05 21:09:30 $
	$RCSfile: __mbtopc.c,v $ $Revision: 1.1.7.4 $ (DEC) $Date: 1994/05/31 18:12:22 $
	$RCSfile: __lc_load.c,v $ $Revision: 1.1.9.2 $ (DEC) $Date: 1994/11/10 14:56:05 $
	$RCSfile: __lc_dlopen.c,v $ $Revision: 1.1.2.6 $ (DEC) $Date: 1995/06/12 20:38:38 $
	$RCSfile: __lc_dlsym.c,v $ $Revision: 1.1.2.5 $ (DEC) $Date: 1995/06/12 20:38:40 $
	$RCSfile: setjmp_incl.s,v $ $Revision: 1.1.4.5 $ (DEC) $Date: 1994/05/13 18:07:02 $
	$RCSfile: alpha_unwind.c,v $ $Revision: 1.1.19.6 $ (DEC) $Date: 1997/08/04 17:50:22 $
	$RCSfile: ldr_load.c,v $ $Revision: 1.1.3.5 $ (DEC) $Date: 1995/04/28 14:20:17 $
	$RCSfile: tzset.c,v $ $Revision: 1.1.24.2 $ (DEC) $Date: 1997/08/04 17:11:53 $
	$RCSfile: perror.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/04/05 15:25:26 $
	$RCSfile: fputs.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/11/23 20:11:33 $
	 habitat_id = realtime_12:1991
	$RCSfile: allocator.c,v $ $Revision: 1.1.2.2 $ (DEC) $Date: 1992/12/03 19:08:59 $
	$RCSfile: nmach_user.c,v $ $Revision: 4.2.2.2 $ (DEC) $Date: 1993/01/15 18:03:56 $
	$RCSfile: mach_error.c,v $ $Revision: 4.2 $ (DEC) $Date: 1991/09/20 04:10:59 $
	$RCSfile: msg.c,v $ $Revision: 4.2.2.2 $ (DEC) $Date: 93/03/02 16:10:03 $
	$RCSfile: mig_support.c,v $ $Revision: 4.2 $ (DEC) $Date: 1991/09/20 04:11:14 $
	$RCSfile: mach_init.c,v $ $Revision: 4.2.6.2 $ (DEC) $Date: 1995/07/11 20:50:08 $
/usr/lib/cmplrs/cc/ftoc:
	$RCSfile: crt0.s,v $ $Revision: 1.1.21.11 $ (DEC) $Date: 1995/09/06 19:54:27 $
	$RCSfile: exit.c,v $ $Revision: 4.2.13.8 $ (DEC) $Date: 1996/04/22 20:54:54 $
	$RCSfile: fread.c,v $ $Revision: 4.3.12.3 $ (DEC) $Date: 1995/07/28 14:53:14 $
	$RCSfile: flsbuf.c,v $ $Revision: 4.2.17.2 $ (DEC) $Date: 1996/10/07 18:02:48 $
	$RCSfile: fopen.c,v $ $Revision: 4.2.11.3 $ (DEC) $Date: 1995/06/12 20:40:14 $
	$RCSfile: fprintf.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/04/04 21:28:13 $
	$RCSfile: printf.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/04/05 15:26:18 $
	$RCSfile: perror.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/04/05 15:25:26 $
	$RCSfile: qsort.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/11/23 19:23:30 $
	$RCSfile: malloc.c,v $ $Revision: 4.2.47.3 $ (DEC) $Date: 1997/06/17 14:20:56 $
	$RCSfile: sigops.c,v $ $Revision: 4.2.10.2 $ (DEC) $Date: 1994/04/05 15:47:12 $
	$RCSfile: tis.c,v $ $Revision: 1.1.14.5 $ (DEC) $Date: 1997/05/02 19:32:15 $
	$RCSfile: init_libc.c,v $ $Revision: 1.1.21.3 $ (DEC) $Date: 1997/03/06 18:54:43 $
	$RCSfile: ldr_atexit.c,v $ $Revision: 4.2.11.4 $ (DEC) $Date: 1995/06/12 20:41:35 $
	$RCSfile: filbuf.c,v $ $Revision: 4.2.13.3 $ (DEC) $Date: 1995/06/12 20:39:59 $
	$RCSfile: tis_pthread.c,v $ $Revision: 1.1.5.3 $ (DEC) $Date: 1996/12/18 20:37:50 $
	$RCSfile: write_nc.c,v $ $Revision: 1.1.7.2 $ (DEC) $Date: 1997/09/23 14:15:37 $
	$RCSfile: close_nc.c,v $ $Revision: 1.1.7.2 $ (DEC) $Date: 1997/09/23 14:15:32 $
	$RCSfile: isatty.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/04/04 21:44:10 $
	$RCSfile: open_nc.c,v $ $Revision: 1.1.7.2 $ (DEC) $Date: 1997/09/23 14:15:33 $
	$RCSfile: findiop.c,v $ $Revision: 4.2.12.4 $ (DEC) $Date: 1995/06/12 20:40:02 $
	$RCSfile: doprnt.c,v $ $Revision: 4.2.43.3 $ (DEC) $Date: 1997/09/26 15:41:30 $
	$RCSfile: errlst.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/11/23 19:19:49 $
	$RCSfile: catopen.c,v $ $Revision: 4.3.18.5 $ (DEC) $Date: 1995/09/25 21:03:54 $
	$RCSfile: catgets.c,v $ $Revision: 4.2.10.3 $ (DEC) $Date: 1994/04/05 21:09:37 $
	$RCSfile: sprintf.c,v $ $Revision: 4.2.13.3 $ (DEC) $Date: 1995/12/14 23:46:41 $
	$RCSfile: abort.c,v $ $Revision: 4.2.11.3 $ (DEC) $Date: 1995/06/12 20:38:42 $
	$RCSfile: brks.c,v $ $Revision: 1.1.2.4 $ (DEC) $Date: 1995/08/30 19:21:18 $
	$RCSfile: mallocdata.c,v $ $Revision: 1.1.4.4 $ (DEC) $Date: 1996/02/08 19:08:30 $
	$RCSfile: sleep.c,v $ $Revision: 4.2.9.5 $ (DEC) $Date: 1995/10/31 15:54:41 $
	$RCSfile: schyield.s,v $ $Revision: 1.1.2.2 $ (DEC) $Date: 1995/09/27 17:08:25 $
	$RCSfile: calloc.c,v $ $Revision: 4.2.8.3 $ (DEC) $Date: 1994/04/05 21:09:32 $
	$RCSfile: tis_rwlock.c,v $ $Revision: 1.1.5.2 $ (DEC) $Date: 1996/12/03 20:38:25 $
	$RCSfile: ldr_dummy.c,v $ $Revision: 4.2.15.2 $ (DEC) $Date: 1997/10/13 21:06:11 $
	$RCSfile: ldr_status.c,v $ $Revision: 4.2.8.3 $ (DEC) $Date: 1994/04/05 15:05:50 $
	$RCSfile: read_nc.c,v $ $Revision: 1.1.7.2 $ (DEC) $Date: 1997/09/23 14:15:35 $
	$RCSfile: Ufwrite.c,v $ $Revision: 1.1.2.2 $ (DEC) $Date: 1994/11/23 20:11:24 $
	$RCSfile: fwrite.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/11/23 20:11:38 $
	$RCSfile: __getmbcurmax.c,v $ $Revision: 1.1.7.2 $ (DEC) $Date: 1994/04/05 16:51:10 $
	$RCSfile: wcstombs.c,v $ $Revision: 4.2.7.3 $ (DEC) $Date: 1994/05/31 18:15:14 $
	$RCSfile: wctomb.c,v $ $Revision: 4.2.11.2 $ (DEC) $Date: 1997/07/15 17:35:42 $
	$RCSfile: ecvt.c,v $ $Revision: 4.2.21.2 $ (DEC) $Date: 1996/06/28 16:44:57 $
	$RCSfile: localeconv.c,v $ $Revision: 4.2.7.3 $ (DEC) $Date: 1994/05/31 18:14:20 $
	$RCSfile: NLSsetup.c,v $ $Revision: 1.1.13.7 $ (DEC) $Date: 1996/01/15 23:46:55 $
	$RCSfile: wcslen.c,v $ $Revision: 4.2.9.3 $ (DEC) $Date: 1995/03/09 18:40:34 $
	$RCSfile: setlocale.c,v $ $Revision: 4.4.18.4 $ (DEC) $Date: 1995/04/27 20:15:29 $
	$RCSfile: getenv.c,v $ $Revision: 4.2.11.4 $ (DEC) $Date: 1995/06/12 20:40:24 $
	$RCSfile: errno.c,v $ $Revision: 1.1.8.4 $ (DEC) $Date: 1994/04/05 22:09:26 $
	$RCSfile: strdup.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/11/23 19:24:39 $
	$RCSfile: basename.c,v $ $Revision: 4.2.12.2 $ (DEC) $Date: 1996/09/16 19:39:28 $
	$RCSfile: __ispriv.c,v $ $Revision: 1.1.9.2 $ (DEC) $Date: 1995/09/25 21:03:53 $
	$RCSfile: bsearch.c,v $ $Revision: 4.2.6.3 $ (DEC) $Date: 1994/04/05 21:09:30 $
	$RCSfile: raise.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1995/10/27 19:40:45 $
	$RCSfile: time.c,v $ $Revision: 4.2.7.2 $ (DEC) $Date: 1994/04/05 16:12:12 $
	$RCSfile: strncpy.c,v $ $Revision: 4.2.7.2 $ (DEC) $Date: 1994/04/05 15:48:58 $
	$RCSfile: strncat.c,v $ $Revision: 4.2.10.2 $ (DEC) $Date: 1996/02/16 21:06:27 $
	$RCSfile: __lc_load.c,v $ $Revision: 1.1.9.2 $ (DEC) $Date: 1994/11/10 14:56:05 $
	$RCSfile: __lc_dlopen.c,v $ $Revision: 1.1.2.6 $ (DEC) $Date: 1995/06/12 20:38:38 $
	$RCSfile: __lc_dlsym.c,v $ $Revision: 1.1.2.5 $ (DEC) $Date: 1995/06/12 20:38:40 $
	$RCSfile: ldr_load.c,v $ $Revision: 1.1.3.5 $ (DEC) $Date: 1995/04/28 14:20:17 $
	$RCSfile: tzset.c,v $ $Revision: 1.1.24.2 $ (DEC) $Date: 1997/08/04 17:11:53 $
	$RCSfile: assert.c,v $ $Revision: 4.2.9.3 $ (DEC) $Date: 1994/04/05 21:09:04 $
/usr/lib/cmplrs/cc/cord:
	$RCSfile: crt0.s,v $ $Revision: 1.1.21.11 $ (DEC) $Date: 1995/09/06 19:54:27 $
	$RCSfile: ldgetpd.c,v $ $Revision: 4.3.6.2 $ (DEC) $Date: 1995/01/25 20:38:36 $
	$RCSfile: cmrlc_produce.c,v $ $Revision: 1.1.17.3 $ (DEC) $Date: 1997/02/07 20:42:03 $
	$RCSfile: cmrlc_basic.c,v $ $Revision: 1.1.5.2 $ (DEC) $Date: 1995/02/15 16:45:57 $
	$RCSfile: cmrlc_consume.c,v $ $Revision: 1.1.11.2 $ (DEC) $Date: 1995/06/21 19:46:04 $
	$RCSfile: lderr.c,v $ $Revision: 1.1.2.2 $ (DEC) $Date: 1995/11/29 19:43:44 $
	$RCSfile: obj.c,v $ $Revision: 4.3.48.4 $ (DEC) $Date: 1997/05/29 19:26:42 $
	$RCSfile: allocate.c,v $ $Revision: 1.1.3.3 $ (DEC) $Date: 1994/05/25 19:19:04 $
	$RCSfile: ldgetname.c,v $ $Revision: 4.3.5.2 $ (DEC) $Date: 1994/05/26 18:09:48 $
	$RCSfile: cmrlc_heur.c,v $ $Revision: 1.1.6.2 $ (DEC) $Date: 1995/09/07 17:18:18 $
	$RCSfile: scncomment.c,v $ $Revision: 4.1.12.2 $ (DEC) $Date: 1994/05/04 20:03:47 $
	$RCSfile: wh1.c,v $ $Revision: 1.1.5.5 $ (DEC) $Date: 1995/11/03 18:57:55 $
	$RCSfile: decompresswh1.alpha.s,v $ $Revision: 1.1.2.3 $ (DEC) $Date: 1994/11/15 16:30:26 $
	$RCSfile: exit.c,v $ $Revision: 4.2.13.8 $ (DEC) $Date: 1996/04/22 20:54:54 $
	$RCSfile: assert.c,v $ $Revision: 4.2.9.3 $ (DEC) $Date: 1994/04/05 21:09:04 $
	$RCSfile: strncmp.c,v $ $Revision: 4.2.11.4 $ (DEC) $Date: 1994/04/20 16:56:44 $
	$RCSfile: strdup.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/11/23 19:24:39 $
	$RCSfile: fread.c,v $ $Revision: 4.3.12.3 $ (DEC) $Date: 1995/07/28 14:53:14 $
	$RCSfile: fwrite.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/11/23 20:11:38 $
	$RCSfile: flsbuf.c,v $ $Revision: 4.2.17.2 $ (DEC) $Date: 1996/10/07 18:02:48 $
	$RCSfile: fopen.c,v $ $Revision: 4.2.11.3 $ (DEC) $Date: 1995/06/12 20:40:14 $
	$RCSfile: fprintf.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/04/04 21:28:13 $
	$RCSfile: printf.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/04/05 15:26:18 $
	$RCSfile: sprintf.c,v $ $Revision: 4.2.13.3 $ (DEC) $Date: 1995/12/14 23:46:41 $
	$RCSfile: vfprintf.c,v $ $Revision: 4.2.7.2 $ (DEC) $Date: 1994/04/05 16:15:00 $
	$RCSfile: fgets.c,v $ $Revision: 4.2.10.2 $ (DEC) $Date: 1994/11/23 20:11:27 $
	$RCSfile: fseek.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/04/04 21:28:42 $
	$RCSfile: ftell.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/04/04 21:28:58 $
	$RCSfile: fdopen.c,v $ $Revision: 4.2.9.3 $ (DEC) $Date: 1994/04/05 22:09:55 $
	$RCSfile: atoi.c,v $ $Revision: 4.2.10.2 $ (DEC) $Date: 1994/11/07 19:18:55 $
	$RCSfile: malloc.c,v $ $Revision: 4.2.47.3 $ (DEC) $Date: 1997/06/17 14:20:56 $
	$RCSfile: calloc.c,v $ $Revision: 4.2.8.3 $ (DEC) $Date: 1994/04/05 21:09:32 $
	$RCSfile: qsort.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/11/23 19:23:30 $
	$RCSfile: abort.c,v $ $Revision: 4.2.11.3 $ (DEC) $Date: 1995/06/12 20:38:42 $
	$RCSfile: time.c,v $ $Revision: 4.2.7.2 $ (DEC) $Date: 1994/04/05 16:12:12 $
	$RCSfile: atol.c,v $ $Revision: 4.2.10.2 $ (DEC) $Date: 1994/11/07 19:19:01 $
	$RCSfile: strcspn.c,v $ $Revision: 4.2.7.2 $ (DEC) $Date: 1994/04/05 15:48:25 $
	$RCSfile: strncpy.c,v $ $Revision: 4.2.7.2 $ (DEC) $Date: 1994/04/05 15:48:58 $
	$RCSfile: a64l.c,v $ $Revision: 4.2.9.6 $ (DEC) $Date: 1995/06/28 16:00:16 $
	$RCSfile: signal.c,v $ $Revision: 4.3.9.2 $ (DEC) $Date: 1995/09/12 17:44:41 $
	$RCSfile: mktemp.c,v $ $Revision: 4.2.10.2 $ (DEC) $Date: 1995/08/29 17:56:51 $
	$RCSfile: brks.c,v $ $Revision: 1.1.2.4 $ (DEC) $Date: 1995/08/30 19:21:18 $
	$RCSfile: NLSsetup.c,v $ $Revision: 1.1.13.7 $ (DEC) $Date: 1996/01/15 23:46:55 $
	$RCSfile: strcasecmp.c,v $ $Revision: 4.2.11.2 $ (DEC) $Date: 1994/11/10 14:57:27 $
	$RCSfile: sigops.c,v $ $Revision: 4.2.10.2 $ (DEC) $Date: 1994/04/05 15:47:12 $
	$RCSfile: tis.c,v $ $Revision: 1.1.14.5 $ (DEC) $Date: 1997/05/02 19:32:15 $
	$RCSfile: init_libc.c,v $ $Revision: 1.1.21.3 $ (DEC) $Date: 1997/03/06 18:54:43 $
	$RCSfile: ldr_atexit.c,v $ $Revision: 4.2.11.4 $ (DEC) $Date: 1995/06/12 20:41:35 $
	$RCSfile: catopen.c,v $ $Revision: 4.3.18.5 $ (DEC) $Date: 1995/09/25 21:03:54 $
	$RCSfile: catgets.c,v $ $Revision: 4.2.10.3 $ (DEC) $Date: 1994/04/05 21:09:37 $
	$RCSfile: write_nc.c,v $ $Revision: 1.1.7.2 $ (DEC) $Date: 1997/09/23 14:15:37 $
	$RCSfile: filbuf.c,v $ $Revision: 4.2.13.3 $ (DEC) $Date: 1995/06/12 20:39:59 $
	$RCSfile: tis_pthread.c,v $ $Revision: 1.1.5.3 $ (DEC) $Date: 1996/12/18 20:37:50 $
	$RCSfile: close_nc.c,v $ $Revision: 1.1.7.2 $ (DEC) $Date: 1997/09/23 14:15:32 $
	$RCSfile: isatty.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/04/04 21:44:10 $
	$RCSfile: open_nc.c,v $ $Revision: 1.1.7.2 $ (DEC) $Date: 1997/09/23 14:15:33 $
	$RCSfile: findiop.c,v $ $Revision: 4.2.12.4 $ (DEC) $Date: 1995/06/12 20:40:02 $
	$RCSfile: doprnt.c,v $ $Revision: 4.2.43.3 $ (DEC) $Date: 1997/09/26 15:41:30 $
	$RCSfile: ecvt.c,v $ $Revision: 4.2.21.2 $ (DEC) $Date: 1996/06/28 16:44:57 $
	$RCSfile: errno.c,v $ $Revision: 1.1.8.4 $ (DEC) $Date: 1994/04/05 22:09:26 $
	$RCSfile: fcntl_nc.c,v $ $Revision: 1.1.2.2 $ (DEC) $Date: 1995/10/30 21:48:23 $
	$RCSfile: mallocdata.c,v $ $Revision: 1.1.4.4 $ (DEC) $Date: 1996/02/08 19:08:30 $
	$RCSfile: raise.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1995/10/27 19:40:45 $
	$RCSfile: rec_mutex.c,v $ $Revision: 1.1.8.2 $ (DEC) $Date: 1997/06/24 19:15:05 $
	$RCSfile: sleep.c,v $ $Revision: 4.2.9.5 $ (DEC) $Date: 1995/10/31 15:54:41 $
	$RCSfile: schyield.s,v $ $Revision: 1.1.2.2 $ (DEC) $Date: 1995/09/27 17:08:25 $
	$RCSfile: tis_rwlock.c,v $ $Revision: 1.1.5.2 $ (DEC) $Date: 1996/12/03 20:38:25 $
	$RCSfile: ldr_dummy.c,v $ $Revision: 4.2.15.2 $ (DEC) $Date: 1997/10/13 21:06:11 $
	$RCSfile: ldr_status.c,v $ $Revision: 4.2.8.3 $ (DEC) $Date: 1994/04/05 15:05:50 $
	$RCSfile: setlocale.c,v $ $Revision: 4.4.18.4 $ (DEC) $Date: 1995/04/27 20:15:29 $
	$RCSfile: getenv.c,v $ $Revision: 4.2.11.4 $ (DEC) $Date: 1995/06/12 20:40:24 $
	$RCSfile: basename.c,v $ $Revision: 4.2.12.2 $ (DEC) $Date: 1996/09/16 19:39:28 $
	$RCSfile: __ispriv.c,v $ $Revision: 1.1.9.2 $ (DEC) $Date: 1995/09/25 21:03:53 $
	$RCSfile: bsearch.c,v $ $Revision: 4.2.6.3 $ (DEC) $Date: 1994/04/05 21:09:30 $
	$RCSfile: read_nc.c,v $ $Revision: 1.1.7.2 $ (DEC) $Date: 1997/09/23 14:15:35 $
	$RCSfile: Ufwrite.c,v $ $Revision: 1.1.2.2 $ (DEC) $Date: 1994/11/23 20:11:24 $
	$RCSfile: fwrite.c,v $ $Revision: 4.2.9.2 $ (DEC) $Date: 1994/11/23 20:11:38 $
	$RCSfile: __getmbcurmax.c,v $ $Revision: 1.1.7.2 $ (DEC) $Date: 1994/04/05 16:51:10 $
	$RCSfile: wcstombs.c,v $ $Revision: 4.2.7.3 $ (DEC) $Date: 1994/05/31 18:15:14 $
	$RCSfile: wctomb.c,v $ $Revision: 4.2.11.2 $ (DEC) $Date: 1997/07/15 17:35:42 $
	$RCSfile: localeconv.c,v $ $Revision: 4.2.7.3 $ (DEC) $Date: 1994/05/31 18:14:20 $
	$RCSfile: wcslen.c,v $ $Revision: 4.2.9.3 $ (DEC) $Date: 1995/03/09 18:40:34 $
	$RCSfile: strncat.c,v $ $Revision: 4.2.10.2 $ (DEC) $Date: 1996/02/16 21:06:27 $
	$RCSfile: __lc_load.c,v $ $Revision: 1.1.9.2 $ (DEC) $Date: 1994/11/10 14:56:05 $
	$RCSfile: __lc_dlopen.c,v $ $Revision: 1.1.2.6 $ (DEC) $Date: 1995/06/12 20:38:38 $
	$RCSfile: __lc_dlsym.c,v $ $Revision: 1.1.2.5 $ (DEC) $Date: 1995/06/12 20:38:40 $
	$RCSfile: ldr_load.c,v $ $Revision: 1.1.3.5 $ (DEC) $Date: 1995/04/28 14:20:17 $
	$RCSfile: tzset.c,v $ $Revision: 1.1.24.2 $ (DEC) $Date: 1997/08/04 17:11:53 $
	 ldtbread.c: 1.1 1/7/82
/usr/lib/cmplrs/cc/crt0.o:
	$RCSfile: crt0.s,v $ $Revision: 1.1.21.11 $ (DEC) $Date: 1995/09/06 19:54:27 $
cc  (cc)
	Digital UNIX Compiler Driver 3.11




From effbot at telia.com  Mon Oct 23 19:44:49 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Mon, 23 Oct 2000 19:44:49 +0200
Subject: [Python-Dev] FYI: ajuba solutions (formerly scriptics) acquired by interwoven
Message-ID: <003201c03d18$f384a5c0$3c6340d5@hagrid>

looks like Tcl's parent company has ceased to be:

    http://biz.yahoo.com/bw/001020/ca_interwo.html

    "The Ajuba team will be assimilated into Interwoven's
    existing technical staff much as the Neonyoyo team
    was immediately after its acquisition in June. The Ajuba
    product line will be discontinued."

</F>




From guido at python.org  Mon Oct 23 22:12:49 2000
From: guido at python.org (Guido van Rossum)
Date: Mon, 23 Oct 2000 15:12:49 -0500
Subject: [Python-Dev] Starship down ?
In-Reply-To: Your message of "Mon, 23 Oct 2000 15:35:40 +0200."
             <39F43EAC.1A518A27@lemburg.com> 
References: <39F43EAC.1A518A27@lemburg.com> 
Message-ID: <200010232012.PAA12261@cj20424-a.reston1.va.home.com>

> The starship.python.net server seems to be down. Could someone
> with sysadmin access please fix this ?!

Yeah, this is very unfortunate.  It's the same problem that's keeping
pytholabs.com down.  The BeOpen systems staff is working on it, but I
don't know what the problem is or when it will be fixed.

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



From esr at thyrsus.com  Mon Oct 23 21:40:16 2000
From: esr at thyrsus.com (Eric S. Raymond)
Date: Mon, 23 Oct 2000 15:40:16 -0400
Subject: [Python-Dev] FYI: ajuba solutions (formerly scriptics) acquired by interwoven
In-Reply-To: <003201c03d18$f384a5c0$3c6340d5@hagrid>; from effbot@telia.com on Mon, Oct 23, 2000 at 07:44:49PM +0200
References: <003201c03d18$f384a5c0$3c6340d5@hagrid>
Message-ID: <20001023154016.A2722@thyrsus.com>

Fredrik Lundh <effbot at telia.com>:
> looks like Tcl's parent company has ceased to be:

This raises anew a question I've been meaning to bring up for the last
week: is it finally time to move away from Python's dependence on
Tcl/Tk for GUI support?

It seems to me that the Tcl world has been in increasing disarray for
the last two years.  Its growth doesn't seem to have matched Perl's or
Python's; no strong community site analogous to python.org or CPAN has
emerged; and John Osterhout's attempt to commercialize the language
have led to a series of false starts and erratic moves.  And Osterhout
cheerfully acknowledges that on a technical level that Tcl has been
pushed past the natural limits of applicability for its design
approach.  

Tcl's long-term prognosis looks, to me, increasingly poor.  Which suggests
to me that some move toqwards making Python less dependent on Tk would be
a good thing.

I understand that we can't simply drop Tkinter.  But I think it might be worth
another look at alternatives (notably wxPython) to consider bringing one
into the core distribution during 2.x, so that later on we can plan to
move Tk to "unsupported -- legacy".
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

You need only reflect that one of the best ways to get yourself 
a reputation as a dangerous citizen these days is to go about 
repeating the very phrases which our founding fathers used in the 
great struggle for independence.
	-- Attributed to Charles Austin Beard (1874-1948)



From guido at python.org  Mon Oct 23 23:08:13 2000
From: guido at python.org (Guido van Rossum)
Date: Mon, 23 Oct 2000 16:08:13 -0500
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: Your message of "Mon, 23 Oct 2000 15:40:16 -0400."
             <20001023154016.A2722@thyrsus.com> 
References: <003201c03d18$f384a5c0$3c6340d5@hagrid>  
            <20001023154016.A2722@thyrsus.com> 
Message-ID: <200010232108.QAA12524@cj20424-a.reston1.va.home.com>

[ESR]
> This raises anew a question I've been meaning to bring up for the last
> week: is it finally time to move away from Python's dependence on
> Tcl/Tk for GUI support?
> 
> It seems to me that the Tcl world has been in increasing disarray for
> the last two years.  Its growth doesn't seem to have matched Perl's or
> Python's; no strong community site analogous to python.org or CPAN has
> emerged; and John Osterhout's attempt to commercialize the language
> have led to a series of false starts and erratic moves.  And Osterhout
> cheerfully acknowledges that on a technical level that Tcl has been
> pushed past the natural limits of applicability for its design
> approach.  
> 
> Tcl's long-term prognosis looks, to me, increasingly poor.  Which
> suggests to me that some move toqwards making Python less dependent
> on Tk would be a good thing.
> 
> I understand that we can't simply drop Tkinter.  But I think it
> might be worth another look at alternatives (notably wxPython) to
> consider bringing one into the core distribution during 2.x, so that
> later on we can plan to move Tk to "unsupported -- legacy".

Yes, it may be time to have this discussion again.

Of course, Tcl/Tk still has a much larger following than wxWindows,
and it is more stable too.  (For example, it's easy to cause crashes
-- not just exceptions -- by leaving out an initialization call in
wxPython.)

Plus, Tk has two very high quality widgets: the Canvas and Text
widgets are unsurpassed in functionality and robustness by other
widget sets.  You can draw more lines or characters per second in most
toolkits, but few toolkits offer the convenience of marks and tags,
not having to deal with refresh events, being able to group objects,
move them around, change attributes, etc., etc., etc.

The Scintilla text widget comes close (and surpasses Tkinter in some
respects, while coming short in others), but I know of no widget in a
popular widget set that offers anything close to the Canvas widget.

There are other choices too, all of which have Python support already:
gtk, qt, and the Mozilla toolkit (whose name I forget -- maybe David
Ascher can fill me in).

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



From akuchlin at mems-exchange.org  Mon Oct 23 22:21:18 2000
From: akuchlin at mems-exchange.org (Andrew Kuchling)
Date: Mon, 23 Oct 2000 16:21:18 -0400
Subject: [Python-Dev] FYI: ajuba solutions (formerly scriptics) acquired by interwoven
In-Reply-To: <20001023154016.A2722@thyrsus.com>; from esr@thyrsus.com on Mon, Oct 23, 2000 at 03:40:16PM -0400
References: <003201c03d18$f384a5c0$3c6340d5@hagrid> <20001023154016.A2722@thyrsus.com>
Message-ID: <20001023162118.B18005@kronos.cnri.reston.va.us>

Fredrik Lundh <effbot at telia.com> wrote:
> looks like Tcl's parent company has ceased to be:

I checked out comp.lang.tcl after hearing about this.  Ousterhout
posted to say that an official statement will be coming out today or
tomorrow, so I wouldn't conclude that Tcl is dead just yet; we'll see
what he says the core team is going to do...

On Mon, Oct 23, 2000 at 03:40:16PM -0400, Eric S. Raymond wrote:
>This raises anew a question I've been meaning to bring up for the last
>week: is it finally time to move away from Python's dependence on
>Tcl/Tk for GUI support?

It seems to me that supporting MacOS is the big problem for
cross-platform GUIs.  There are several different systems such as Qt
that aim for portability across Windows and Unix, but add in the MacOS
and the options really decrease.  How good is wxWindows support for
MacOS?

Or will MacOS X fix the problem?  I know MacOS X uses a BSD-based
underlying kernel, but don't know if it will support X Windows out of
the box.  If people can only use MacOS-specific GUI APIs, then
software such as Tk would still need to be ported specially to MacOS X.

--amk



From akuchlin at mems-exchange.org  Mon Oct 23 22:30:11 2000
From: akuchlin at mems-exchange.org (Andrew Kuchling)
Date: Mon, 23 Oct 2000 16:30:11 -0400
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: <200010232108.QAA12524@cj20424-a.reston1.va.home.com>; from guido@python.org on Mon, Oct 23, 2000 at 04:08:13PM -0500
References: <003201c03d18$f384a5c0$3c6340d5@hagrid> <20001023154016.A2722@thyrsus.com> <200010232108.QAA12524@cj20424-a.reston1.va.home.com>
Message-ID: <20001023163011.C18005@kronos.cnri.reston.va.us>

On Mon, Oct 23, 2000 at 04:08:13PM -0500, Guido van Rossum wrote:
>The Scintilla text widget comes close (and surpasses Tkinter in some
>respects, while coming short in others), but I know of no widget in a
>popular widget set that offers anything close to the Canvas widget.

I believe the GNOME (not GTk's, but GNOME's) canvas widget began as a
fork of the Tk widget that was then substantially enhanced to be a
general-purpose display engine, with antialiasing, alpha compositing,
more attention to performance, and other fancy features.  I don't know
if the corresponding text widget (which is Pango, www.pango.org, I
think) is equally featureful.

--amk



From gvwilson at nevex.com  Mon Oct 23 22:33:48 2000
From: gvwilson at nevex.com (Greg Wilson)
Date: Mon, 23 Oct 2000 16:33:48 -0400 (EDT)
Subject: [Python-Dev] Re: ajuba solutions (formerly scriptics) acquired by interwoven
In-Reply-To: <20001023154016.A2722@thyrsus.com>
Message-ID: <Pine.LNX.4.10.10010231624060.31805-100000@akbar.nevex.com>

> Fredrik Lundh <effbot at telia.com>:
> > looks like Tcl's parent company has ceased to be:

> Eric Raymond:
> This raises anew a question I've been meaning to bring up for the last week:
> is it finally time to move away from Python's dependence on Tcl/Tk for GUI
> support?

Yes please.

> It seems to me that the Tcl world has been in increasing disarray for the
> last two years.  Its growth doesn't seem to have matched Perl's or Python's;
> no strong community site analogous to python.org or CPAN has emerged;

I have been told by two different publishers that they can't even give Tcl books
away any longer.  It's also interesting that the new Ruby book from Hunt and
Thomas clearly positions Ruby as an alternative to Python, rather than Tcl or
Perl (I saw three mentions in the first ten minutes of the fact that Ruby is
more widely used in Japan than Python).  Also interesting that the Ruby GUI
toolkit they describe is Tk-based...

> I understand that we can't simply drop Tkinter.  But I think it might be
> worth another look at alternatives (notably wxPython) to consider bringing
> one into the core distribution during 2.x, so that later on we can plan to
> move Tk to "unsupported -- legacy".

I thought about using wxPython in the most recent run of my Python course, but
decided to stick to Tkinter because:

- There isn't a wxWindows/wxPython book (matters a lot when organizations are
  trying to decide what to adopt for long-term use).

- Tkinter came packaged with the 1.5.2 installer, wxPython didn't.

- There aren't as many tools on top of wxPython as there are on top of Tkinter.
  In particular, I think that a vector drawing package on top of wxPython that
  did what Sketch does, but on Windows as well as Linux, would make a great
  subject for a book on Python, non-trivial OO, and HCI (hint, hint...)

Thanks,
Greg




From effbot at telia.com  Mon Oct 23 23:02:58 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Mon, 23 Oct 2000 23:02:58 +0200
Subject: [Python-Dev] FYI: ajuba solutions (formerly scriptics) acquired by interwoven
References: <003201c03d18$f384a5c0$3c6340d5@hagrid> <20001023154016.A2722@thyrsus.com> <20001023162118.B18005@kronos.cnri.reston.va.us>
Message-ID: <001e01c03d34$d11bd5f0$3c6340d5@hagrid>

andrew wrote:
> I checked out comp.lang.tcl after hearing about this.  Ousterhout
> posted to say that an official statement will be coming out today or
> tomorrow, so I wouldn't conclude that Tcl is dead just yet; we'll see
> what he says the core team is going to do...

from an open-source perspective, Tcl might be more alive
than ever:

http://sourceforge.net/projects/tcl
http://sourceforge.net/projects/tktoolkit

and trust me, the Python 2.0/Tk8.4/Tkinter3000 combo
will rock ;-)

</F>




From esr at thyrsus.com  Mon Oct 23 23:15:03 2000
From: esr at thyrsus.com (Eric S. Raymond)
Date: Mon, 23 Oct 2000 17:15:03 -0400
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: <200010232108.QAA12524@cj20424-a.reston1.va.home.com>; from guido@python.org on Mon, Oct 23, 2000 at 04:08:13PM -0500
References: <003201c03d18$f384a5c0$3c6340d5@hagrid> <20001023154016.A2722@thyrsus.com> <200010232108.QAA12524@cj20424-a.reston1.va.home.com>
Message-ID: <20001023171503.B2889@thyrsus.com>

Guido van Rossum <guido at python.org>:
> There are other choices too, all of which have Python support already:
> gtk, qt, and the Mozilla toolkit (whose name I forget -- maybe David
> Ascher can fill me in).

I'm glad you brought up GTK+.  Of all the alternatives you mentioned,
it seems to me the most likely to attract long-term cross-platform
support by lots of developers (GNOME, Nautilus and Sun Microsystems
seem like a tough trio to beat on this score).  Thus, GTK+ may be be
the safest alternative in terms of being least likely to strand us N
years down the road.

The GTK+ API seems like a nice clean design, and there is already a Python
binding.  Any comment from anybody on how stable it is?  Are the text and
canvas widgets anywhere near competitive with Tk's?  There are hints
of a wxWindows-based port to Windows on the GTK+ site; is there a Mac port?
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

.. a government and its agents are under no general duty to 
provide public services, such as police protection, to any 
particular individual citizen...
        -- Warren v. District of Columbia, 444 A.2d 1 (D.C. App.181)



From trentm at ActiveState.com  Mon Oct 23 23:06:41 2000
From: trentm at ActiveState.com (Trent Mick)
Date: Mon, 23 Oct 2000 14:06:41 -0700
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: <200010232108.QAA12524@cj20424-a.reston1.va.home.com>; from guido@python.org on Mon, Oct 23, 2000 at 04:08:13PM -0500
References: <003201c03d18$f384a5c0$3c6340d5@hagrid> <20001023154016.A2722@thyrsus.com> <200010232108.QAA12524@cj20424-a.reston1.va.home.com>
Message-ID: <20001023140641.A3899@ActiveState.com>

On Mon, Oct 23, 2000 at 04:08:13PM -0500, Guido van Rossum wrote:
> There are other choices too, all of which have Python support already:
...
> and the Mozilla toolkit (whose name I forget -- maybe David
> Ascher can fill me in).

XUL. Though slappin' a GUI together in XUL is not all the same as for
the other toolkits. Layout with XML, functionality with JavaScript and Python
(and/or Perl of C++).


Trent


-- 
Trent Mick
TrentM at ActiveState.com



From effbot at telia.com  Mon Oct 23 23:33:02 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Mon, 23 Oct 2000 23:33:02 +0200
Subject: [Python-Dev] FYI: ajuba solutions (formerly scriptics) acquired by interwoven
References: <003201c03d18$f384a5c0$3c6340d5@hagrid> <20001023154016.A2722@thyrsus.com> <20001023162118.B18005@kronos.cnri.reston.va.us>
Message-ID: <004201c03d38$d4836e20$3c6340d5@hagrid>

andrew wrote:
> I checked out comp.lang.tcl after hearing about this.  Ousterhout
> posted to say that an official statement will be coming out today or
> tomorrow, so I wouldn't conclude that Tcl is dead just yet; we'll see
> what he says the core team is going to do...

they just updated their site:

http://www.ajubasolutions.com/company/whatsnew.html

    "Tcl is not a core technology at Interwoven, and
    Interwoven will not invest in the development of
    Tcl. However, Ajuba has transferred responsibility
    for Tcl core development to the newly formed Tcl
    Core Team /.../ We expect the Tcl Core Team to
    evolve Tcl at a much faster rate than any single
    organization could achieve by itself. 

    "Over the next few weeks Ajuba will release in open-
    source form many of the Tcl packages that we deve-
    loped for our products. Stay tuned for more info...

</F>




From akuchlin at mems-exchange.org  Mon Oct 23 23:26:18 2000
From: akuchlin at mems-exchange.org (Andrew Kuchling)
Date: Mon, 23 Oct 2000 17:26:18 -0400
Subject: [Python-Dev] Re: ajuba acquired by interwoven
In-Reply-To: <Pine.LNX.4.10.10010231624060.31805-100000@akbar.nevex.com>; from gvwilson@nevex.com on Mon, Oct 23, 2000 at 04:33:48PM -0400
References: <20001023154016.A2722@thyrsus.com> <Pine.LNX.4.10.10010231624060.31805-100000@akbar.nevex.com>
Message-ID: <20001023172618.A23898@kronos.cnri.reston.va.us>

Some details begin to emerge at 
http://www.ajubasolutions.com/company/whatsnew.html

It looks like some of their proprietary code will be released as open
source, possibly including the TclPro development environment.  The
new company will not be funding Tcl/Tk development, and instead it's
up to the 14 members of the recently-formed Tcl core team.  I don't
know if any of those people are being paid to work on Tcl, but
probably at least some of them are.  I expect this will cause a good
deal disruption, perhaps even a fatal amount, particularly if core
developers such as Jeffrey Hobbs no longer work on Tcl full-time.

--amk



From esr at thyrsus.com  Mon Oct 23 23:58:20 2000
From: esr at thyrsus.com (Eric S. Raymond)
Date: Mon, 23 Oct 2000 17:58:20 -0400
Subject: [Python-Dev] Re: ajuba acquired by interwoven
In-Reply-To: <20001023172618.A23898@kronos.cnri.reston.va.us>; from akuchlin@mems-exchange.org on Mon, Oct 23, 2000 at 05:26:18PM -0400
References: <20001023154016.A2722@thyrsus.com> <Pine.LNX.4.10.10010231624060.31805-100000@akbar.nevex.com> <20001023172618.A23898@kronos.cnri.reston.va.us>
Message-ID: <20001023175820.A3117@thyrsus.com>

Andrew Kuchling <akuchlin at mems-exchange.org>:
> Some details begin to emerge at 
> http://www.ajubasolutions.com/company/whatsnew.html
> 
> It looks like some of their proprietary code will be released as open
> source, possibly including the TclPro development environment.  The
> new company will not be funding Tcl/Tk development, and instead it's
> up to the 14 members of the recently-formed Tcl core team.  I don't
> know if any of those people are being paid to work on Tcl, but
> probably at least some of them are.  I expect this will cause a good
> deal disruption, perhaps even a fatal amount, particularly if core
> developers such as Jeffrey Hobbs no longer work on Tcl full-time.

Not necessarily...

Good for Tcl: they *have* a core team now

Bad for Tcl: at 14 it's too big, unless there's some inner core of no
	more than three or four architects.

Good for Tcl: Much of the proprietary code will go open.

Bad for Tcl: Not clear whether the two Ajuba employees "replaced" are
		on the new core team. Not clear whether their time 
		available will increase or decrease.

Good for Tcl: Osterhout's rather lame attempts to develop under a mixed 
		model have almost certainly come to an end in favor of
		an Apache-like model funded by big Tcl users.

With good leadership, they could manage the transition to something
resembling the Apache Software Foundation's organization.  If so, Tcl
might actually improve.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Rifles, muskets, long-bows and hand-grenades are inherently democratic
weapons.  A complex weapon makes the strong stronger, while a simple
weapon -- so long as there is no answer to it -- gives claws to the
weak.
        -- George Orwell, "You and the Atom Bomb", 1945



From robin at alldunn.com  Tue Oct 24 01:03:44 2000
From: robin at alldunn.com (Robin Dunn)
Date: Mon, 23 Oct 2000 16:03:44 -0700
Subject: [Python-Dev] Re: ajuba solutions (formerly scriptics) acquired by interwoven
References: <Pine.LNX.4.10.10010231624060.31805-100000@akbar.nevex.com>
Message-ID: <036501c03d45$81aefae0$3225d2d1@ARES>

I'm not on python-dev so please be sure to copy me on replies.


"Greg Wilson" <gvwilson at nevex.com> wrote:
>
> I thought about using wxPython in the most recent run of my Python course,
but
> decided to stick to Tkinter because:
>
> - There isn't a wxWindows/wxPython book (matters a lot when organizations
are
>   trying to decide what to adopt for long-term use).
>

This is something I am hoping to change in the near future.  I have a lot of
ideas, have been putting an outline together, and have a phone conference
with a potential publisher tomorrow.

> - Tkinter came packaged with the 1.5.2 installer, wxPython didn't.
>
> - There aren't as many tools on top of wxPython as there are on top of
Tkinter.
>   In particular, I think that a vector drawing package on top of wxPython
that
>   did what Sketch does, but on Windows as well as Linux, would make a
great
>   subject for a book on Python, non-trivial OO, and HCI (hint, hint...)

Hint received and understood...


"Andrew Kuchling" akuchlin at mems-exchange.org wrote:
>
> It seems to me that supporting MacOS is the big problem for
> cross-platform GUIs.  There are several different systems such as Qt
> that aim for portability across Windows and Unix, but add in the MacOS
> and the options really decrease.  How good is wxWindows support for
> MacOS?

My understanding is that the version in CVS is nearly up to date with the
features in the MSW and GTK versions, though I haven't had a chance to use
it myself.  It's in use in at least a few commercial applications around the
world.

The next step I guess is getting it wrapped up in wxPython, which should
just be a matter of porting some of the low level startup and helper code,
and putting some ifdef's in the SWIG interface files for things that may be
different in the Mac version of wxWindows.  Unfortunately, given the current
state of the amount of my spare time and relative Mac-illiterate-ness, it's
either going to require someone else to work on it and be wxPython-Mac's
champion, or somebody needs to fund my ramp-up and development time so I can
cut back on other things.  The good news is that I have been loaned a Mac
and CodeWarior and such to play with, I just haven't found the time to play
much lately.



"Guido van Rossum" guido at python.org wrote:
> Plus, Tk has two very high quality widgets: the Canvas and Text
> widgets are unsurpassed in functionality and robustness by other
> widget sets.  You can draw more lines or characters per second in most
> toolkits, but few toolkits offer the convenience of marks and tags,
> not having to deal with refresh events, being able to group objects,
> move them around, change attributes, etc., etc., etc.
>
> The Scintilla text widget comes close (and surpasses Tkinter in some
> respects, while coming short in others),

Just in case anybody didn't know already, wxWindows/wxPython has a wrapper
around Scintilla available called wxStyledTextCtrl.

> but I know of no widget in a
> popular widget set that offers anything close to the Canvas widget.

wxWindows has a canvas widget in development right now.  I've been trying to
nudge the developers working on it towards features found in the tk canvas
and the GNOME canvas widget.  I have high hopes for it but I'm not sure how
long it will be before it gets to the same level as the others.


--
Robin Dunn
Software Craftsman
robin at AllDunn.com
http://wxPython.org     Java give you jitters?
http://wxPROs.com        Relax with wxPython!





From esr at thyrsus.com  Tue Oct 24 01:29:54 2000
From: esr at thyrsus.com (Eric S. Raymond)
Date: Mon, 23 Oct 2000 19:29:54 -0400
Subject: [Python-Dev] Re: ajuba solutions (formerly scriptics) acquired by interwoven
In-Reply-To: <036501c03d45$81aefae0$3225d2d1@ARES>; from robin@alldunn.com on Mon, Oct 23, 2000 at 04:03:44PM -0700
References: <Pine.LNX.4.10.10010231624060.31805-100000@akbar.nevex.com> <036501c03d45$81aefae0$3225d2d1@ARES>
Message-ID: <20001023192954.A3313@thyrsus.com>

Robin Dunn <robin at alldunn.com>:
>                                      Unfortunately, given the current
> state of the amount of my spare time and relative Mac-illiterate-ness, it's
> either going to require someone else to work on it and be wxPython-Mac's
> champion, or somebody needs to fund my ramp-up and development time so I can
> cut back on other things.

This is exactly what CoSource and SourceXchange are for.  Post your Mac port
as a project there and see who ponies up money.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

  "...quemadmodum gladius neminem occidit, occidentis telum est."
[...a sword never kills anybody; it's a tool in the killer's hand.]
        -- (Lucius Annaeus) Seneca "the Younger" (ca. 4 BC-65 AD),



From MarkH at ActiveState.com  Tue Oct 24 01:19:33 2000
From: MarkH at ActiveState.com (Mark Hammond)
Date: Tue, 24 Oct 2000 10:19:33 +1100
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: <20001023140641.A3899@ActiveState.com>
Message-ID: <ECEPKNMJLHAPFFJHDOJBMEJGDOAA.MarkH@ActiveState.com>

Trimmed all CCs

[Guido]
> and the Mozilla toolkit (whose name I forget -- maybe David
> Ascher can fill me in).

[Trent "David Ascher" Mick responds]
> XUL. Though slappin' a GUI together in XUL is not all the same as for
> the other toolkits. Layout with XML, functionality with
> JavaScript and Python (and/or Perl of C++).

As a fairly irrelevant (at this point in time) observation:

Something about the Mozilla XUL engine seems "right".  It is large and
complex, but their XML based layout engine, and powerful "code-less" widget
creation has a lot of potential IMO.

It is very very new and rough.  It is very tightly bound with Mozilla
itself and javascript, although efforts are underway to separate it from
both.  It is huge, and constantly changing.  It has been designed for
tomorrow, and struggles along today.  But it may well turn out to be and
expressive and compelling model for the future.

So, if we can just continue to disagree for the next 2 or 3 years, it may
well become something worth considering ;-)

Mark.




From robin at alldunn.com  Tue Oct 24 01:56:59 2000
From: robin at alldunn.com (Robin Dunn)
Date: Mon, 23 Oct 2000 16:56:59 -0700
Subject: [Python-Dev] Re: ajuba solutions (formerly scriptics) acquired by interwoven
References: <Pine.LNX.4.10.10010231624060.31805-100000@akbar.nevex.com> <036501c03d45$81aefae0$3225d2d1@ARES> <20001023192954.A3313@thyrsus.com>
Message-ID: <038601c03d4c$ef14f1f0$3225d2d1@ARES>

>
> This is exactly what CoSource and SourceXchange are for.  Post your Mac
port
> as a project there and see who ponies up money.

Now why didn't I think of that???  Thanks for the idea!

--
Robin Dunn
Software Craftsman
robin at AllDunn.com
http://wxPython.org     Java give you jitters?
http://wxPROs.com        Relax with wxPython!





From DavidA at ActiveState.com  Tue Oct 24 06:00:51 2000
From: DavidA at ActiveState.com (David Ascher)
Date: Mon, 23 Oct 2000 21:00:51 -0700 (Pacific Daylight Time)
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: <200010232108.QAA12524@cj20424-a.reston1.va.home.com>
Message-ID: <Pine.WNT.4.21.0010231545180.1476-100000@loom>

> The Scintilla text widget comes close (and surpasses Tkinter in some
> respects, while coming short in others), but I know of no widget in a
> popular widget set that offers anything close to the Canvas widget.
> 
> There are other choices too, all of which have Python support already:
> gtk, qt, and the Mozilla toolkit (whose name I forget -- maybe David
> Ascher can fill me in).

The mozilla toolkits has more names than I care to remember.  =)  The most
generic name is XPFE, although there are some parts of it with nicer names
like XUL (pronounced Zool) and XBL.  It also heavily uses XML, DTDs, CSS,
etc.

Mozilla is definitely a long-term investment in our part.  For example,
currently it's not possible to have Python code inline in the XUL
(XML) code, and JavaScript is the only option there.  We'll be working w/
the Netscape and Mozilla crowds to fix that, but it's not there yet.

That said, Mozilla does have a fairly strong vision for the future, allows
some of the benefits of the web technologies to transfer to the GUI world
(designers, not coders, can do the UI work).

In terms of the closest equivalent to the Canvas widget, apart from XUL
itself, which is very hierarchical, there is the promise of SVG support,
which will give you a lot more than the Canvas.  That, too, is not quite
ready for prime time yet.

Hope this is helpful,

--david





From cgw at fnal.gov  Tue Oct 24 06:32:04 2000
From: cgw at fnal.gov (Charles G Waldman)
Date: Mon, 23 Oct 2000 23:32:04 -0500 (CDT)
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: <Pine.WNT.4.21.0010231545180.1476-100000@loom>
References: <200010232108.QAA12524@cj20424-a.reston1.va.home.com>
	<Pine.WNT.4.21.0010231545180.1476-100000@loom>
Message-ID: <14837.4292.807070.848419@buffalo.fnal.gov>

David Ascher writes:
 > 
 > That said, Mozilla does have a fairly strong vision for the future, allows
 > some of the benefits of the web technologies to transfer to the GUI world
 > (designers, not coders, can do the UI work).

Sounds great for the future, but I want to inject a few of my
unsolicated, opinionated observations - today, in 2000, the Mozilla
stuff is *far* from usable.  If you want to produce nice, professional
looking GUI apps which fit nicely with the desktop (rather that having
their own completely different look-and-feel) it's hard to beat Gtk+
or Tkinter.  Tkinter is still quite viable, especially if
cross-plaform support is important.  Some of the examples in Grayson's
book are quite beautiful.  It will be a long time until
XPFE/XUL/whatchamacallit gets to this level of viability.

Also consider that Sun (and HP?) now ship Gnome by default, rather
than CDE (or so I hear, anyway).  I predict that Gnome compatibility
will become more and more of a desirable feature.

Evidence of the above is the "Galeon" project.  It's widely perceived
that Mozilla has a nice rendering engine (Gecko) wrapped up in a
dreadful GUI (XPFE).  So the Galeon project places the Gecko engine
inside a Gtk+/Gnome GUI, which provides a much more pleasant user
experience.

There's also a (preliminary) port of Gtk+ to Win32:
http://www.gimp.org/~tml/gimp/win32/

And, finally, IMO, the work being done on PyGtk is of high quality.
I'm using it currently in production code.



From DavidA at ActiveState.com  Tue Oct 24 07:12:14 2000
From: DavidA at ActiveState.com (David Ascher)
Date: Mon, 23 Oct 2000 22:12:14 -0700 (Pacific Daylight Time)
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: <14837.4292.807070.848419@buffalo.fnal.gov>
Message-ID: <Pine.WNT.4.21.0010232209570.612-100000@cr469175-a>

> There's also a (preliminary) port of Gtk+ to Win32:
> http://www.gimp.org/~tml/gimp/win32/

FWIW, the last time I checked, this was useless.  I'd be glad to be wrong,
but I'm not holding my breath.  Not surprisingly, the GTK crowd, which is
rooted in Linux tradition (!), has little interest in Win32 ports, and
even less experience in that world.  Until that happens, a lot of
platform-agnostic projects and vendors will have a hard time w/ GTK.

I don't mean to diss GTK, just pointing out that cross-platform solutions
are important to a whole lot of communities (Python included).

--david




From tim_one at email.msn.com  Tue Oct 24 07:20:07 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Tue, 24 Oct 2000 01:20:07 -0400
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: <200010232108.QAA12524@cj20424-a.reston1.va.home.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCEEIAHMAA.tim_one@email.msn.com>

[ESR]
> ...
> and John Osterhout's attempt to commercialize the language have led to
> a series of false starts and erratic moves.

We don't want to criticize anyone for that:  PythonLabs' attempts *not* to
commercialize Python may yet make Tcl's path look as straight and true as a
laser beam <blink>.

obliquely y'rs  - tim





From tim_one at email.msn.com  Tue Oct 24 07:31:07 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Tue, 24 Oct 2000 01:31:07 -0400
Subject: [Python-Dev] Starship down ?
In-Reply-To: <200010232012.PAA12261@cj20424-a.reston1.va.home.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCAEIBHMAA.tim_one@email.msn.com>

[MAL]
> The starship.python.net server seems to be down. Could someone
> with sysadmin access please fix this ?!

[GvR]
> Yeah, this is very unfortunate.  It's the same problem that's keeping
> pytholabs.com down.  The BeOpen systems staff is working on it, but I
> don't know what the problem is or when it will be fixed.

FYI, pythonlabs.com is up again, but Starship is still down.  We only said
it's the same problem because we didn't know what either problem was.  And,
we still don't!

long-distance-ly y'rs  - tim





From cgw at fnal.gov  Tue Oct 24 07:34:23 2000
From: cgw at fnal.gov (Charles G Waldman)
Date: Tue, 24 Oct 2000 00:34:23 -0500 (CDT)
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: <Pine.WNT.4.21.0010232209570.612-100000@cr469175-a>
References: <14837.4292.807070.848419@buffalo.fnal.gov>
	<Pine.WNT.4.21.0010232209570.612-100000@cr469175-a>
Message-ID: <14837.8031.342286.639052@buffalo.fnal.gov>

David Ascher writes:

 >cgw> There's also a (preliminary) port of Gtk+ to Win32:
 >cgw> http://www.gimp.org/~tml/gimp/win32/
 > 
 > FWIW, the last time I checked, this was useless.

That's what I meant by "preliminary" ;-)

 > I don't mean to diss GTK, just pointing out that cross-platform solutions
 > are important to a whole lot of communities (Python included).

Right.  Cross-platform is very important, but so is native
look-and-feel, and this is where (IMO) XPFE falls flat on its face.
Something like WxWindows, which uses Gtk+ on *nix and MFC (?) on Win,
seems like it could be a real winner.  If the x-platform GUI doesn't
use native dialog boxes and filechoosers, users REALLY notice this and
they will just hate it.  (Yes, this is based on observations of actual
paying customers).

I have a little bit of experience with cross-platform development -
having used a lot of these tools - at my last job, after evaluating
just about everything, we bought into (against my advice!) a doomed
commercial product called Visix Galaxy (for which I immediately
created a set of Python bindings).  The problem with all of these
things, of course, is that the more cross-platform they are, the more
"lowest-common-denominator" they are forced to become.

Tkinter, with widgets like Canvas, was really pretty amazing - for its
day - feature-rich *and x-platform.  But even this broke down if you
started using fancy features like drawing with dashed lines - works on
X, not on Windows (last time I checked, anyway) - the more you start
pushing the limits of the toolkit, the more the portability breaks
down.

Tkinter-is-dead-long-live-Tkinter'ly yrs, 
				     -C



From MarkH at ActiveState.com  Tue Oct 24 07:48:34 2000
From: MarkH at ActiveState.com (Mark Hammond)
Date: Tue, 24 Oct 2000 16:48:34 +1100
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: <14837.8031.342286.639052@buffalo.fnal.gov>
Message-ID: <ECEPKNMJLHAPFFJHDOJBEEKEDOAA.MarkH@ActiveState.com>

> Right.  Cross-platform is very important, but so is native
> look-and-feel, and this is where (IMO) XPFE falls flat on its face.

Actually, my experience with XPFE from a look-and-feel POV has been pretty
positive.  It is true they have re-implemented most widgets rather than use
native ones, and also true that you can make these widgets look nothing
like native LAF - but generally, my experience with Mozilla and the
"classic" skin is that it is close enough that it is very hard to tell.  It
looks more like "subtle enhancements", in the same way IE provides "subtle
enhancements"

> seems like it could be a real winner.  If the x-platform GUI doesn't
> use native dialog boxes and filechoosers, users REALLY notice this and

Agreed.  However, XPFE works fine here IMO.

Again, I do not want to propose XPFE as viable today, and I agree it may
never be viable.  Most other critisisms posted are valid, but I don't think
that LAF is one such problem with XPFE.

Mark.




From paul at prescod.net  Tue Oct 24 08:29:42 2000
From: paul at prescod.net (Paul Prescod)
Date: Mon, 23 Oct 2000 23:29:42 -0700
Subject: [Python-Dev] FYI: ajuba solutions (formerly scriptics) acquired by 
 interwoven
References: <003201c03d18$f384a5c0$3c6340d5@hagrid> <20001023154016.A2722@thyrsus.com> <20001023162118.B18005@kronos.cnri.reston.va.us> <001e01c03d34$d11bd5f0$3c6340d5@hagrid>
Message-ID: <39F52C56.214B28A1@prescod.net>

Fredrik Lundh wrote:
> 
>...
> 
> http://sourceforge.net/projects/tcl
> http://sourceforge.net/projects/tktoolkit
> 
> and trust me, the Python 2.0/Tk8.4/Tkinter3000 combo
> will rock ;-)

Perhaps this could be an opportunity to split Tcl and Tk more cleanly.
People like Fredrick and his Perl/Ruby/... equivalents could get more
deeply involved in setting direction. It would be interesting to
contrast the number of Tcl versus Tk users right now.
-- 
 Paul Prescod - Not encumbered by corporate consensus
Simplicity does not precede complexity, but follows it. 
	- http://www.cs.yale.edu/homes/perlis-alan/quotes.html



From paul at prescod.net  Tue Oct 24 08:40:49 2000
From: paul at prescod.net (Paul Prescod)
Date: Mon, 23 Oct 2000 23:40:49 -0700
Subject: [Python-Dev] Gradual migration
Message-ID: <39F52EF1.A201C6D9@prescod.net>

Python 3K. It is the repository for our hopes and dreams. We tend to
invoke it in three different situations:

 1. in delaying discussions of gee-whiz features (e.g. static type
checking)

 2. in delaying hairy implementation re-factoring that we don't
want to undertake right now.

 3. in delaying painful backwards-compatibility breakage

I think it is somewhat debatable whether we really need to or should do
these three things all at once but that's a separate discussion for
another day. (the other experiment may inform our decision)

I want to focus on "3" -- breakage. Rather than delaying painful
backwards-compatibility breakage I thing we should make it less painful.
We should decide where we are going long before we ask our users to move
there. I think we should start including alternatives to syntaxes and
features that we know are broken. Once people move to the alternatives
we can "reassign" or remove the original syntax with much less pain.

In other words, rather than telling people "here's a new version, your
code is broken, sorry." We should tell them: "we're going to break code.
Here's an alternative syntax that you can use that will be interpreted
the same in the old and new versions -- please move to this new syntax
as quickly as possible."

I'll outline some examples of the strategy. You may or may not like
details of the particular proposals but you might still agree with the
strategy. Also, I don't claim that all of the proposals are fully
fleshed-out...again, it's the strategy I'm most interested in. I don't
even agree with every feature change I describe below -- they are just
some I've heard of for Python 3000. In other words ** this is not a
design document for Python 3000! **

Separating byte arrays from strings:

 1. immediately introduce two new functions:

   binopen("foo").read() -> byte array
   stropen("foo","UTF-8".read() -> u"...."

 2. warn about string literals that have embedded non-Unicode characters

 3. deprecate extension modules that return "old fashioned" string
arrays

 4. after a period where all strings have been restricted to
Unicode-compatibility, merge the Unicode and string types.

 5. deprecate the special Unicode u"" syntax as an imperialist
anachronism



Reclaiming the division operator from truncating integer division:

 1. immediately introduce new functions: div() that does division as we
wish it was.

 2. add a warning mode to Python (long overdue)

 3. with the warning mode on, old-fashioned division triggers a
deprecation warning.

 4. after three years as a warning situation we expect all in-use Python
scripts to have been upgraded to use the new operations and to
explicitly truncate integer division when that is what is wanted.

 5. at that point we can re-assign the division operator to be a
floating point division if we wish.




Case insensitivity:

 1. Warn whenever a module or class has two __dict__ entries that differ
only by case

 2. Eventually, disallow that form of name-clash altogether

 3. After a period, allow case variations to be equivalent.



Unifying types and classes (more vague):

 1. Add something like extension class to make type subclassing easier.

 2. Informally deprecate modules that do not incorporate it.

 3. Replace or fix details of the language and implementation that
behave differently for types and classes. (e.g. the type() operator)




-- 
 Paul Prescod - Not encumbered by ActiveState consensus
Simplicity does not precede complexity, but follows it. 
	- http://www.cs.yale.edu/homes/perlis-alan/quotes.html



From pf at artcom-gmbh.de  Tue Oct 24 09:47:03 2000
From: pf at artcom-gmbh.de (Peter Funk)
Date: Tue, 24 Oct 2000 09:47:03 +0200 (MEST)
Subject: Integer division revisited (was Re: [Python-Dev] Gradual migration)
In-Reply-To: <39F52EF1.A201C6D9@prescod.net> from Paul Prescod at "Oct 23, 2000 11:40:49 pm"
Message-ID: <m13nynX-000Dm8C@artcom0.artcom-gmbh.de>

Hi,

Paul Prescod wrote on python-dev at python.org:
[...]
> Reclaiming the division operator from truncating integer division:
[...]

Bruce Sherwood and David Scherer suggested a IMHO very clever solution to
this particular problem in March/April this year.  This thread was first 
posted to idle-dev and afterwards X-posted to python-dev:

http://www.python.org/pipermail/idle-dev/2000-April/000138.html
http://www.python.org/pipermail/idle-dev/2000-April/000140.html
http://www.python.org/pipermail/python-dev/2000-April/010029.html

Unfortunately I'm no native english speaker and have not enough time 
to make a Python-2.1 PEP from it.  May be somebody else wants to go for it?

I still believe, this was a very clever Python enhancement, which should
be officially proposed.

Regards, Peter
-- 
Peter Funk, Oldenburger Str.86, D-27777 Ganderkesee, Germany, Fax:+49 4222950260
office: +49 421 20419-0 (ArtCom GmbH, Grazer Str.8, D-28359 Bremen)



From mal at lemburg.com  Tue Oct 24 10:45:03 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Tue, 24 Oct 2000 10:45:03 +0200
Subject: [Python-Dev] Gradual migration
References: <39F52EF1.A201C6D9@prescod.net>
Message-ID: <39F54C0F.25798309@lemburg.com>

Paul Prescod wrote:
> 
> Python 3K. It is the repository for our hopes and dreams. We tend to
> invoke it in three different situations:
> 
>  1. in delaying discussions of gee-whiz features (e.g. static type
> checking)
> 
>  2. in delaying hairy implementation re-factoring that we don't
> want to undertake right now.
> 
>  3. in delaying painful backwards-compatibility breakage
> 
> I think it is somewhat debatable whether we really need to or should do
> these three things all at once but that's a separate discussion for
> another day. (the other experiment may inform our decision)

I think will simply be a consequence of doing a complete rewrite
of the interpreter for Py3K. AFAIR, the only truely feasable
solution would be doing the rewrite in a widely portable
subset of C++ and then managing classes at that level.
 
Moving to a common and very low-level strategy for classes
will allows us to put even the most basic types (strings and
numbers) into an inheritence tree. 

Differences like the
ones between Unicode and 8-bit strings would then flesh
out as two different subclasses of a generic string type which
again is based on a generic sequence type.

The same could be done for dictionaries: special ones for
just string keys, case insensitive lookups, etc. could all
be subclasses of a generic mapping class.

Dito for numbers (and division strategies).

By following this principle there won't be all that much
breakage, since the old functionality will still be around,
only the defaults will have changed.

Add to this pluggable compilers and ceval loops, plus a nice
way of configuring the lot on a per-module basis and you're
set. (Ok, it's a fluffy clouds image, but you get the picture ;-)

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From guido at python.org  Tue Oct 24 17:57:43 2000
From: guido at python.org (Guido van Rossum)
Date: Tue, 24 Oct 2000 10:57:43 -0500
Subject: [Python-Dev] Gradual migration
In-Reply-To: Your message of "Tue, 24 Oct 2000 10:45:03 +0200."
             <39F54C0F.25798309@lemburg.com> 
References: <39F52EF1.A201C6D9@prescod.net>  
            <39F54C0F.25798309@lemburg.com> 
Message-ID: <200010241557.KAA15629@cj20424-a.reston1.va.home.com>

> Paul Prescod wrote:
> > 
> > Python 3K. It is the repository for our hopes and dreams. We tend to
> > invoke it in three different situations:
> > 
> >  1. in delaying discussions of gee-whiz features (e.g. static type
> > checking)
> > 
> >  2. in delaying hairy implementation re-factoring that we don't
> > want to undertake right now.
> > 
> >  3. in delaying painful backwards-compatibility breakage
> > 
> > I think it is somewhat debatable whether we really need to or should do
> > these three things all at once but that's a separate discussion for
> > another day. (the other experiment may inform our decision)

Marc-Andre Lemburg replied:

> I think will simply be a consequence of doing a complete rewrite
> of the interpreter for Py3K. AFAIR, the only truely feasable
> solution would be doing the rewrite in a widely portable
> subset of C++ and then managing classes at that level.
>  
> Moving to a common and very low-level strategy for classes
> will allows us to put even the most basic types (strings and
> numbers) into an inheritence tree. 
> 
> Differences like the
> ones between Unicode and 8-bit strings would then flesh
> out as two different subclasses of a generic string type which
> again is based on a generic sequence type.
> 
> The same could be done for dictionaries: special ones for
> just string keys, case insensitive lookups, etc. could all
> be subclasses of a generic mapping class.
> 
> Dito for numbers (and division strategies).
> 
> By following this principle there won't be all that much
> breakage, since the old functionality will still be around,
> only the defaults will have changed.
> 
> Add to this pluggable compilers and ceval loops, plus a nice
> way of configuring the lot on a per-module basis and you're
> set. (Ok, it's a fluffy clouds image, but you get the picture ;-)

Good job in channeling me, Marc-Andre!  I'm sure that's not exactly
how it's going to be, but on the face of it, this sure sounds like a
reasonable possible route.  Do you want to be the author for PEP-3000?

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



From guido at python.org  Tue Oct 24 18:13:37 2000
From: guido at python.org (Guido van Rossum)
Date: Tue, 24 Oct 2000 11:13:37 -0500
Subject: [Python-Dev] Gradual migration
In-Reply-To: Your message of "Mon, 23 Oct 2000 23:40:49 MST."
             <39F52EF1.A201C6D9@prescod.net> 
References: <39F52EF1.A201C6D9@prescod.net> 
Message-ID: <200010241613.LAA15769@cj20424-a.reston1.va.home.com>

> I want to focus on "3" -- breakage. Rather than delaying painful
> backwards-compatibility breakage I thing we should make it less painful.
> We should decide where we are going long before we ask our users to move
> there. I think we should start including alternatives to syntaxes and
> features that we know are broken. Once people move to the alternatives
> we can "reassign" or remove the original syntax with much less pain.

Absolutely.  Whenever possible, we should try to plan for migration in
Python 2.x.

> In other words, rather than telling people "here's a new version, your
> code is broken, sorry." We should tell them: "we're going to break code.
> Here's an alternative syntax that you can use that will be interpreted
> the same in the old and new versions -- please move to this new syntax
> as quickly as possible."

It would also help if we could produce automatic translation tools
that will convert the old syntax into the new.  This desire may
restrict our choices however: the translation tools don't have runtime
information to go by.  It's easy enough to change obsolete syntax into
new syntax, but it's hard to decide whether a particular "/" operator
should be changed into an integer divide ("//") or left alone.

> I'll outline some examples of the strategy. You may or may not like
> details of the particular proposals but you might still agree with the
> strategy. Also, I don't claim that all of the proposals are fully
> fleshed-out...again, it's the strategy I'm most interested in. I don't
> even agree with every feature change I describe below -- they are just
> some I've heard of for Python 3000. In other words ** this is not a
> design document for Python 3000! **

I think the proper approach is to start a separate migration process
for each of these proposed changes.  Each should be paced separately
(the pace may depend on how hard to swallow the change is for users as
well as how hard it is to implement the new functionality) and for
each, a separate PEP in the 3000 series should be started.  I can even
see that several PEPs will be needed in some cases (e.g. one to
describe the new syntax, one to to flesh out the implementation, and
one to decide on the migration steps).

I won't comment on Paul's examples, that's for the various PEP
processes.

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



From cgw at fnal.gov  Tue Oct 24 17:21:45 2000
From: cgw at fnal.gov (Charles G Waldman)
Date: Tue, 24 Oct 2000 10:21:45 -0500 (CDT)
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: <ECEPKNMJLHAPFFJHDOJBKEKIDOAA.MarkH@ActiveState.com>
References: <14837.14407.954185.466011@buffalo.fnal.gov>
	<ECEPKNMJLHAPFFJHDOJBKEKIDOAA.MarkH@ActiveState.com>
Message-ID: <14837.43273.24692.93965@buffalo.fnal.gov>

Mark Hammond writes:
 > >  > Agreed.  However, XPFE works fine here IMO.
 > >
 > cgw> "Here" means on MS-Win, right?   Maybe that's why our perceptions are
 > cgw> so different.
 > 
 > Correct.  Although I have run it under Linux a few times, I wouldnt really
 > know LAF issues if I tripped over them there ;-)
 > 
 > Mark.

It's certainly true that the lack of a consistent look and feel for
Linux apps has been somewhat of a problem historically.  However, with
the emergence of Gnome, it seems that there is finally some
convergence.  (Althought people in the KDE/Qt camp will certainly not
agree!)  Gnome is gathering momentum, especially now that Sun has
joined the Gnome Foundation.  With outfits like Eazel, Helix Code,
etc, turning out high-quality products, things are moving fast in the
Gnome/Gtk+ world and it seems clear to me that this will be the major
desktop platform for Unix machines in the upcoming decade.

Back in my former life, when I was still worrying about Windows, the
company I worked for bought into a commerical x-platform GUI toolkit
called Galaxy (I mentioned this earlier).  Galaxy re-implemented all
the native widgets, kind of like XPFE does.  One issue with this was
that MS seemed to change something about the widgets in every release
- e.g. the Galaxy filechooser looked like Windows 3.1, then Win95 came
out and Galaxy had to play catch-up.  Once Galaxy had the Win95 LAF,
Win98 came out.  Now I hear there's something called Windows ME.  Have
they changed the look-and-feel again?  Seems to me like all the
widget-reimplementors are doomed to playing eternal catch-up.

OK, enough off-topic rambling (for now),
	   
	   -C






From akuchlin at mems-exchange.org  Tue Oct 24 17:43:26 2000
From: akuchlin at mems-exchange.org (Andrew Kuchling)
Date: Tue, 24 Oct 2000 11:43:26 -0400
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: <14837.43273.24692.93965@buffalo.fnal.gov>; from cgw@fnal.gov on Tue, Oct 24, 2000 at 10:21:45AM -0500
References: <14837.14407.954185.466011@buffalo.fnal.gov> <ECEPKNMJLHAPFFJHDOJBKEKIDOAA.MarkH@ActiveState.com> <14837.43273.24692.93965@buffalo.fnal.gov>
Message-ID: <20001024114326.E13957@kronos.cnri.reston.va.us>

On Tue, Oct 24, 2000 at 10:21:45AM -0500, Charles G Waldman wrote:
>It's certainly true that the lack of a consistent look and feel for
>Linux apps has been somewhat of a problem historically.  However, with
>the emergence of Gnome, it seems that there is finally some
>convergence.  (Althought people in the KDE/Qt camp will certainly not

Careful... while people may try to port GTk+ to Windows, porting GNOME
is a different kettle of wax, because GNOME needs GTk+ but also
entails gnome-libs and gnome-vfs and Bonobo and esound and lots of
other things, which provide services such as object embedding that
wouldn't be required -- or would be very different -- on Windows.  I
don't know if anyone is trying to tease apart GNOME into a
Windows-suitable subset; it seems like it would be a difficult task.

Qt is at least a toolkit that aims at cross-platform portability,
though there again, the KDE environment built on top of it is not
going to be portable to anything that isn't Unix.  Both the Qt and
GTk+ toolkits ignore the Mac, leaving Tk and wxWindows as the only
real possibilities.  This is why, every time this debate comes up, we
end up sticking with Tk; it may suck, but all the other systems don't
support everything...

Maybe the best approach is to follow /F's lead with Tkinter3000, and
reimplement the Tkinter API on top of MFC / GTk+ / Qt.  (Er... that
*is* what Tkinter3000 is, right?)  What's the problem we're trying to solve here?

     * Is it that the problem that the Tkinter module is a bad API for
       GUI programming?

     * Or is it that the Tk implementation is slow or bulky?

     * Or do we just dislike having to require Tcl as well as Tk?

Can someone articulate why Tk should be replaced?

--amk



From gvwilson at nevex.com  Tue Oct 24 17:52:00 2000
From: gvwilson at nevex.com (Greg Wilson)
Date: Tue, 24 Oct 2000 11:52:00 -0400 (EDT)
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: <20001024114326.E13957@kronos.cnri.reston.va.us>
Message-ID: <Pine.LNX.4.10.10010241146450.6622-100000@akbar.nevex.com>

> Andrew Kuchling wrote:
> What's the problem we're trying to solve here?
> 
> * Is it that the problem that the Tkinter module is a bad API for
>   GUI programming?
> 
> * Or is it that the Tk implementation is slow or bulky?
> 
> * Or do we just dislike having to require Tcl as well as Tk?
> 
> Can someone articulate why Tk should be replaced?

I can articulate why I'm unhappy with the current set-up:

1. Requiring Tcl is fragile.  Un-gumming installation on machines at Los
   Alamos before my first Python course cost me several hours, and I had
   to do it again two months' later.  I've run into similar problems with
   multiple Tcl installations on Windows machines (personal use).

2. (Lack of) native look and feel.  This is a complete show-stopper for
   many of the outfits I've dealt with (and not just with Python).

Performance doesn't really matter --- I've never had students complain about
speed, although I've never asked them to build something large enough that
refresh would be an issue.

I don't have experience teaching wxPython, so I can't comment on the
relative teachability of its API vs. Tk's.

Hope this helps,
Greg





From paul at prescod.net  Tue Oct 24 18:12:12 2000
From: paul at prescod.net (Paul Prescod)
Date: Tue, 24 Oct 2000 09:12:12 -0700
Subject: [Python-Dev] Gradual migration
References: <39F52EF1.A201C6D9@prescod.net> <39F54C0F.25798309@lemburg.com>
Message-ID: <39F5B4DC.C226D8F6@prescod.net>

"M.-A. Lemburg" wrote:
> 
>...
> 
> I think will simply be a consequence of doing a complete rewrite
> of the interpreter for Py3K. AFAIR, the only truely feasable
> solution would be doing the rewrite in a widely portable
> subset of C++ and then managing classes at that level.

I disagree for a variety of reasons:

 * implementation language and Python inheritance semantics are almost
completely distinct. After all, we have Python implementations in a
variety of languages with minor incompatibilities. Python could have a
proper type/class merging even if it were written in assembly language.
So let's leave implementation language aside.

 * there is a hell of a lot we can do to make the type/class split less
visible without a major rewrite. For instance, lists could have a
__getitem__ method so that they "act like" instances. Instances could
return their methods in a dir() so that they "act like" built-in
objects. So there is no reason to wait for a complete rewrite to start
on this path.

 * It may even be the case that we can get from here to complete merged
type/class semantics WITHOUT a rewrite. If a mad genious had not written
stackless Python I would have sworn up and down that stackless Python
would require a Python rewrite. It didn't. If another slightly less mad
genious had not integrated ints and longs I would never have believed it
possible without another rewrite. Someone needs to do an analysis of
what it takes to merge types and classes and *demonstrate* that it
requires a rewrite rather than *asserting* that it requires a rewrite.

In other words, let's stop sprinkling the "major rewrite" pixie dust on
hard problems and instead decide where we want to go and how we want to
get there!

> Moving to a common and very low-level strategy for classes
> will allows us to put even the most basic types (strings and
> numbers) into an inheritence tree.

I don't know what you mean by a "low-level strategy" for classes. It's
not like we can somehow use C++ vtables without giving up Python's
dynamicity. Python's class handling is about as low-level as it can get
in my humble opinion.

> Differences like the
> ones between Unicode and 8-bit strings would then flesh
> out as two different subclasses of a generic string type which
> again is based on a generic sequence type.

Of course that's where we want to go but it doesn't avoid the backwards
compatibility problems. We can do this today using proxying.

> The same could be done for dictionaries: special ones for
> just string keys, case insensitive lookups, etc. could all
> be subclasses of a generic mapping class.

We can easily do this today.

> Dito for numbers (and division strategies).

There's no way I'm going to let you get away with that little sleight of
hand. How is inheritance holy water going to allow us to change the
semantics of:

5/2

without breaking code??

The same goes for

a.b = 5

versus

a.B = 5

C++ does not help. Inheritance does not help. Pluggable compilers do not
help. We *will* break code. We just need to decide whether to do it in a
thoughtful way that gives people a chance to migrate or put off
decisions until the last possible moment and then spring it on them with
no between-version upgrade path.

> By following this principle there won't be all that much
> breakage, since the old functionality will still be around,
> only the defaults will have changed.

When you change defaults you break code. Keeping the old functionality
around is barely helpful.  Nobody has EVER proposed a change to Python
where something that was previously possible is now made impossible. So
whatever our strategy, the PROBLEM is changing defaults. The solution is
telling people what defaults are changing in what timeline and
discouraging them from depending on the old defaults.

> Add to this pluggable compilers and ceval loops, plus a nice
> way of configuring the lot on a per-module basis and you're
> set. (Ok, it's a fluffy clouds image, but you get the picture ;-)

Sounds mythical. I'm trying to take it out of the realm of fluffy clouds
and bring it into the world that people can plan their businesses and
coding strategies around.
-- 
 Paul Prescod - Not encumbered by corporate consensus
Simplicity does not precede complexity, but follows it. 
	- http://www.cs.yale.edu/homes/perlis-alan/quotes.html



From paul at prescod.net  Tue Oct 24 18:30:17 2000
From: paul at prescod.net (Paul Prescod)
Date: Tue, 24 Oct 2000 09:30:17 -0700
Subject: [Python-Dev] Gradual migration
References: <39F52EF1.A201C6D9@prescod.net> <200010241613.LAA15769@cj20424-a.reston1.va.home.com>
Message-ID: <39F5B919.4B80A526@prescod.net>

Guido van Rossum wrote:
> 
> ...
> 
> I think the proper approach is to start a separate migration process
> for each of these proposed changes.  

I agree.

As a more concrete extension to my last email, I propose the following
doctrine:

"""
No major documented feature should be removed or have changed semantics
in Python 3000 or any other new version of Python until users have had a
year (preferably MORE!) of upgrade time. Upgrade time entails the
following parts:

    1. the released Python version has a new recommended way to
accomplish the task in a manner that will remain available in the
"breakage version" e.g. a div() function that people can use for a few
years while the semantics of "/" are in transition.

    2. the mechanism/syntax that will be removed is formally deprecated.
The documentation would say, e.g. "You should not use '/' for now. It is
changing semantics in the future."

    3. the released Python version sports a runtime warning to tell
users that the mechanism/syntax is going away. "CompatibilityError:
Future versions of Python will have different semantics for the '/'
operator. Please use div() instead."

The actual "right" amount of upgrade time depends on the extent of the
breakage and its ease of detection.
"""

I can PEP this if people agree. I think that the user community would
appreciate our effort to promise not to break code suddenly and
capriciously.
-- 
 Paul Prescod - Not encumbered by corporate consensus
Simplicity does not precede complexity, but follows it. 
	- http://www.cs.yale.edu/homes/perlis-alan/quotes.html



From barry at wooz.org  Tue Oct 24 18:26:13 2000
From: barry at wooz.org (Barry A. Warsaw)
Date: Tue, 24 Oct 2000 12:26:13 -0400 (EDT)
Subject: [Python-Dev] What to choose to replace Tkinter?
References: <20001024114326.E13957@kronos.cnri.reston.va.us>
	<Pine.LNX.4.10.10010241146450.6622-100000@akbar.nevex.com>
Message-ID: <14837.47141.817450.488896@anthem.concentric.net>

>>>>> "GW" == Greg Wilson <gvwilson at nevex.com> writes:

    GW> 2. (Lack of) native look and feel.  This is a complete
    GW> show-stopper for many of the outfits I've dealt with (and not
    GW> just with Python).

On the other hand, it's incredibly easy to whip together a GUI in Tk
for simple applications.  Yes, Tk gets painful as applications grow,
but I'd hate to abandon such a simple, well-known toolkit for a
complicated, hard-to-learn but powerful native look-and-feel one.  You
don't /always/ care about strict native LAF.

Or to restate: I'd hate to have to make that choice.  If we can't
satisfy both requirements (mandatory-native-LAF and rapid prototyping
friendliness), we may need to continue to support multiple toolkits.

the-delicious-aroma-of-the-first-GUI-bakeoff-still-in-the-air-ly y'rs,
-Barry



From guido at python.org  Tue Oct 24 19:39:38 2000
From: guido at python.org (Guido van Rossum)
Date: Tue, 24 Oct 2000 12:39:38 -0500
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: Your message of "Tue, 24 Oct 2000 11:52:00 -0400."
             <Pine.LNX.4.10.10010241146450.6622-100000@akbar.nevex.com> 
References: <Pine.LNX.4.10.10010241146450.6622-100000@akbar.nevex.com> 
Message-ID: <200010241739.MAA16414@cj20424-a.reston1.va.home.com>

> I can articulate why I'm unhappy with the current set-up:
> 
> 1. Requiring Tcl is fragile.  Un-gumming installation on machines at Los
>    Alamos before my first Python course cost me several hours, and I had
>    to do it again two months' later.  I've run into similar problems with
>    multiple Tcl installations on Windows machines (personal use).

For Windows, this problem has gone away in 1.6 and 2.0 -- we
distribute and install our own Tcl/Tk binaries, in a place that
doesn't affect or require existing Tcl/Tk installations.

Maybe we can do the same for Unix binary distributions?  I believe
Jeremy has already had to create a separate RPM for _tkinter because
there are too many different versions of Tcl/Tk out there -- it
shouldn't be hard to install our own altogether.

> 2. (Lack of) native look and feel.  This is a complete show-stopper for
>    many of the outfits I've dealt with (and not just with Python).

Really?  Are you sure that's not just general resistence against new
things?  To me, and I suspect may others, the app I use most often on
Windows is Netscape -- talk about lack of native look-and-feel!  It's
never bothered me all that much.

Or are you saying that IDLE isn't designed as a typical Microsoft app?
That's quite a separate issue from the widget look-and-feel!

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



From barry at wooz.org  Tue Oct 24 18:40:50 2000
From: barry at wooz.org (Barry A. Warsaw)
Date: Tue, 24 Oct 2000 12:40:50 -0400 (EDT)
Subject: [Python-Dev] Gradual migration
References: <39F52EF1.A201C6D9@prescod.net>
	<39F54C0F.25798309@lemburg.com>
	<39F5B4DC.C226D8F6@prescod.net>
Message-ID: <14837.48018.547379.464959@anthem.concentric.net>

>>>>> "PP" == Paul Prescod <paul at prescod.net> writes:

    PP>  * implementation language and Python inheritance semantics
    PP> are almost completely distinct. After all, we have Python
    PP> implementations in a variety of languages with minor
    PP> incompatibilities. Python could have a proper type/class
    PP> merging even if it were written in assembly language.  So
    PP> let's leave implementation language aside.

Jython experience backs this up.  It would be incredibly convenient if
we could just map Java classes to Python classes, so that for example,
we'd have in Java a PyException class that is exceptions.Exception
with minimal or no Java wrappings.  And Finn nearly did this.

The problem that we ran into with Java is that it allows only single
inheritance.  So you couldn't create a Python exception that multiply
inherited from two or more other Python exceptions.  Doesn't happen
often, but it does happen, so is that an acceptable tradeoff?

C++ might be better in this particular respect, but there will be
other issues, because as soon as you start transparently showing the
implementation's classes into Python, you inherit their semantics and
restrictions as well.

Just saying that it's tricky.
-Barry



From guido at python.org  Tue Oct 24 19:54:39 2000
From: guido at python.org (Guido van Rossum)
Date: Tue, 24 Oct 2000 12:54:39 -0500
Subject: [Python-Dev] Gradual migration
In-Reply-To: Your message of "Tue, 24 Oct 2000 09:30:17 MST."
             <39F5B919.4B80A526@prescod.net> 
References: <39F52EF1.A201C6D9@prescod.net> <200010241613.LAA15769@cj20424-a.reston1.va.home.com>  
            <39F5B919.4B80A526@prescod.net> 
Message-ID: <200010241754.MAA16520@cj20424-a.reston1.va.home.com>

> As a more concrete extension to my last email, I propose the following
> doctrine:
> 
> """
> No major documented feature should be removed or have changed semantics
> in Python 3000 or any other new version of Python until users have had a
> year (preferably MORE!) of upgrade time. Upgrade time entails the
> following parts:
> 
>     1. the released Python version has a new recommended way to
> accomplish the task in a manner that will remain available in the
> "breakage version" e.g. a div() function that people can use for a few
> years while the semantics of "/" are in transition.
> 
>     2. the mechanism/syntax that will be removed is formally deprecated.
> The documentation would say, e.g. "You should not use '/' for now. It is
> changing semantics in the future."
> 
>     3. the released Python version sports a runtime warning to tell
> users that the mechanism/syntax is going away. "CompatibilityError:
> Future versions of Python will have different semantics for the '/'
> operator. Please use div() instead."
> 
> The actual "right" amount of upgrade time depends on the extent of the
> breakage and its ease of detection.
> """
> 
> I can PEP this if people agree. I think that the user community would
> appreciate our effort to promise not to break code suddenly and
> capriciously.

Go for it.  I have little bandwidth to think about this deeply, but
what you're proposing here sounds like a good approach.  Certainly it
will make it easier if I can point to this PEP when I get the next FUD
email about "should I bother to learn Python 2.0 when Py3K is going to
be all different?"...

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



From effbot at telia.com  Tue Oct 24 19:07:12 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Tue, 24 Oct 2000 19:07:12 +0200
Subject: [Python-Dev] FYI: ajuba solutions (formerly scriptics) acquired by interwoven
References: <003201c03d18$f384a5c0$3c6340d5@hagrid> <20001023154016.A2722@thyrsus.com> <20001023162118.B18005@kronos.cnri.reston.va.us> <001e01c03d34$d11bd5f0$3c6340d5@hagrid> <39F52C56.214B28A1@prescod.net>
Message-ID: <006001c03ddc$dda85570$3c6340d5@hagrid>

paul wrote:
> Perhaps this could be an opportunity to split Tcl and Tk more cleanly.
> People like Fredrick and his Perl/Ruby/... equivalents could get more
> deeply involved in setting direction.

I'm waiting for the Tcl/Tk developers to grow up -- they still
fear that any attempt to make it easier to use Tk from other
languages would be to "give up the crown jewels" :-(

</F>




From effbot at telia.com  Tue Oct 24 18:59:23 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Tue, 24 Oct 2000 18:59:23 +0200
Subject: [Python-Dev] What to choose to replace Tkinter?
References: <14837.14407.954185.466011@buffalo.fnal.gov> <ECEPKNMJLHAPFFJHDOJBKEKIDOAA.MarkH@ActiveState.com> <14837.43273.24692.93965@buffalo.fnal.gov> <20001024114326.E13957@kronos.cnri.reston.va.us>
Message-ID: <005f01c03ddc$dd52bb60$3c6340d5@hagrid>

andrew wrote:
> Maybe the best approach is to follow /F's lead with Tkinter3000, and
> reimplement the Tkinter API on top of MFC / GTk+ / Qt.  (Er... that
> *is* what Tkinter3000 is, right?)

nope -- at least not initially.  the first two steps are a new
Tk glue layer, and an extension API that allows you to write
new widgets in pure Python.  also see:

    http://w1.132.telia.com/~u13208596/tkinter/index.htm

:::

I have plans for how to take the Tkinter API *and* the new
extension API beyond Tk, but let's save that for another day...

:::

> Can someone articulate why Tk should be replaced?

beats me ;-)

</F>




From cgw at fnal.gov  Tue Oct 24 18:54:35 2000
From: cgw at fnal.gov (Charles G Waldman)
Date: Tue, 24 Oct 2000 11:54:35 -0500 (CDT)
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: <20001024114326.E13957@kronos.cnri.reston.va.us>
References: <14837.14407.954185.466011@buffalo.fnal.gov>
	<ECEPKNMJLHAPFFJHDOJBKEKIDOAA.MarkH@ActiveState.com>
	<14837.43273.24692.93965@buffalo.fnal.gov>
	<20001024114326.E13957@kronos.cnri.reston.va.us>
Message-ID: <14837.48843.889458.137903@buffalo.fnal.gov>

Andrew Kuchling writes:
 > 
 > Careful... while people may try to port GTk+ to Windows, porting GNOME
 > is a different kettle of wax, because GNOME needs GTk+ but also
 > entails gnome-libs

But I was never seriously advocating Gtk+ on Windows.  This was just a
footnote.  I shouldn't have even mentioned the Windows Gtk+ port
because it just muddied the water.

The major point I was trying to make is that toolkits like Tkinter and
WxWindows, which try to delegate to the native widget sets whenever
possible, will succeed, and toolkits like Galaxy/AWT/Swing/XPFE, which
reimpliment all the widgets from scratch, are doomed to fail.  (IMO,
of course).

What I believe we need is a suitable abstraction which uses MFC on
MS-Win platforms and Gtk+ on Unix.  And which also doesn't, due to the
abstraction, take away too many features.  I don't know that much
about MFC, but for a simple example - Gtk+ offers an option for its
canvas widget to do all drawing in antialised mode (by the way, this
is slow but produces very nice looking results).  It would be a shame
if the abstraction layer didn't allow for things like this to be used.

 > This is why, every time this debate comes up, we
 > end up sticking with Tk; it may suck, but all the other systems don't
 > support everything...

Right.  FWIW, in my day-to-day work, if it has to run on MS-Win I use
Tkinter, and if MS-Win is not an issue I use PyGtk.  Fermilab will be
showing some network monitoring software at the Supercomputing 2000
conference next month, and it's mostly all stuff I whipped up a few
days using Tkinter.



From gmcm at hypernet.com  Tue Oct 24 19:14:42 2000
From: gmcm at hypernet.com (Gordon McMillan)
Date: Tue, 24 Oct 2000 13:14:42 -0400
Subject: [Python-Dev] Gradual migration
In-Reply-To: <39F5B4DC.C226D8F6@prescod.net>
Message-ID: <39F58B42.26855.490B8F73@localhost>

Paul Prescod wrote:
...
> .... It's
> not like we can somehow use C++ vtables without giving up Python's
> dynamicity. 

But that's exactly what COM does.

not-to-be-taken-as-an-endorsement-ly y'rs

- Gordon



From akuchlin at mems-exchange.org  Tue Oct 24 19:15:14 2000
From: akuchlin at mems-exchange.org (Andrew Kuchling)
Date: Tue, 24 Oct 2000 13:15:14 -0400
Subject: [Python-Dev] FYI: ajuba solutions (formerly scriptics) acquired by interwoven
In-Reply-To: <006001c03ddc$dda85570$3c6340d5@hagrid>; from effbot@telia.com on Tue, Oct 24, 2000 at 07:07:12PM +0200
References: <003201c03d18$f384a5c0$3c6340d5@hagrid> <20001023154016.A2722@thyrsus.com> <20001023162118.B18005@kronos.cnri.reston.va.us> <001e01c03d34$d11bd5f0$3c6340d5@hagrid> <39F52C56.214B28A1@prescod.net> <006001c03ddc$dda85570$3c6340d5@hagrid>
Message-ID: <20001024131514.B25025@kronos.cnri.reston.va.us>

On Tue, Oct 24, 2000 at 07:07:12PM +0200, Fredrik Lundh wrote:
>I'm waiting for the Tcl/Tk developers to grow up -- they still
>fear that any attempt to make it easier to use Tk from other
>languages would be to "give up the crown jewels" :-(

In the long run this has probably harmed Tk seriously.  If Tk was just
a widget set divorced from Tcl, then it might have been chosen as the
underlying widget set for GNOME or KDE, and then have benefited from
the development work done for those projects, such as the GNOME canvas
enhancements, which now can't be absorbed back into Tk without a lot
of effort to merge the two sets of code.  

--amk



From gvwilson at nevex.com  Tue Oct 24 19:58:59 2000
From: gvwilson at nevex.com (Greg Wilson)
Date: Tue, 24 Oct 2000 13:58:59 -0400 (EDT)
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: <200010241739.MAA16414@cj20424-a.reston1.va.home.com>
Message-ID: <Pine.LNX.4.10.10010241355360.6622-100000@akbar.nevex.com>

> > Greg Wilson:
> > I can articulate why I'm unhappy with the current set-up:
> > 1. Requiring Tcl is fragile.

> Guido van Rossum:
> For Windows, this problem has gone away in 1.6 and 2.0 -- we distribute and
> install our own Tcl/Tk binaries

OK.

> > Greg Wilson:
> > 2. (Lack of) native look and feel.  This is a complete show-stopper for
> >    many of the outfits I've dealt with (and not just with Python).

> Guido van Rossum:
> Really?  Are you sure that's not just general resistence against new things?

Well, my students' resistance to novelty is low enough that they're willing to
take a Python course :-).  This comes up every time I teach; no idea whether it
has any impact on the usability of completed applications, but I believe it
makes people less likely to choose Tkinter when starting development.

Thanks,
Greg




From guido at python.org  Tue Oct 24 21:04:55 2000
From: guido at python.org (Guido van Rossum)
Date: Tue, 24 Oct 2000 14:04:55 -0500
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: Your message of "Tue, 24 Oct 2000 13:58:59 -0400."
             <Pine.LNX.4.10.10010241355360.6622-100000@akbar.nevex.com> 
References: <Pine.LNX.4.10.10010241355360.6622-100000@akbar.nevex.com> 
Message-ID: <200010241904.OAA19165@cj20424-a.reston1.va.home.com>

> Well, my students' resistance to novelty is low enough that they're
> willing to take a Python course :-).  This comes up every time I
> teach; no idea whether it has any impact on the usability of
> completed applications, but I believe it makes people less likely to
> choose Tkinter when starting development.

Can you elaborate on the line of argument that you typically hear?
What do you say to dispel it?

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



From nas at arctrix.com  Tue Oct 24 13:56:11 2000
From: nas at arctrix.com (Neil Schemenauer)
Date: Tue, 24 Oct 2000 04:56:11 -0700
Subject: [Python-Dev] A small step to removing the type/class split
Message-ID: <20001024045611.B9993@glacier.fnational.com>

I've run into a problem with ExtensionClass which I believe can
only be fixed by modifying Python.  I will try to explain.

I have an ExtensionClass which defines __cmp__.  Depending on the
objects being compared, the __cmp__ method may never be called.
This is due to code in object.c that looks like this:

    if (PyInstance_Check(v) || PyInstance_Check(w)) {
        try to use use __cmp__ method
    }
    else {
        try number coerce and fall back on type name comparison
    }

Extension classes can never pass the PyInstance_Check predicate.
I've searched for all occurances of PyInstance_Check in the 2.0
source.  In many places that PyInstance_Check occurs a more
general "is this an instance-like type" check would seem to be
more suitable.

Here is my proposal:

  * Define a new type flag Py_TPFLAGS_INSTANCE.
  * Create a new predicate Py_IsInstance which checks for this
    flag.
  * Set this flag on PyInstance_Type.
  * Replace most occurances of PyInstance_Check with
    Py_IsInstance.

Extension types (like ExtensionClass) can then define the type
flag Py_TPLAGS_INSTANCE and be treated as an instance type by the
Python interpreter.  This should make it quite a bit easier to make
extension types behave like "real" classes.

Comments?

  Neil



From mal at lemburg.com  Tue Oct 24 21:37:30 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Tue, 24 Oct 2000 21:37:30 +0200
Subject: [Python-Dev] Gradual migration
References: <39F52EF1.A201C6D9@prescod.net> <39F54C0F.25798309@lemburg.com> <39F5B4DC.C226D8F6@prescod.net>
Message-ID: <39F5E4FA.9FD6D35@lemburg.com>

Paul Prescod wrote:
> 
> "M.-A. Lemburg" wrote:
> >
> >...
> >
> > I think will simply be a consequence of doing a complete rewrite
> > of the interpreter for Py3K. AFAIR, the only truely feasable
> > solution would be doing the rewrite in a widely portable
> > subset of C++ and then managing classes at that level.
> 
> I disagree for a variety of reasons:
> 
>  * implementation language and Python inheritance semantics are almost
> completely distinct. After all, we have Python implementations in a
> variety of languages with minor incompatibilities. Python could have a
> proper type/class merging even if it were written in assembly language.
> So let's leave implementation language aside.

Hey, think of it as opportunity: we can reuse much of C++'s 
optimizations and the integration of Python and C++ applications
will get *much* easier.
 
A rewrite shouldn't scare anyone away -- much of the existing
code can be reused since only the Python C APIs of the various
types will have to be rewritten, not the logic behind the types.

Besides, Py3K will be a project which runs in parallel to the
2.x development (at least that's what I've read on some BeOpen
webpage), so there's really not much to worry about wrt to
breakage, etc. People will be able to test-drive Py3K while
using the 2.x series.

>  * there is a hell of a lot we can do to make the type/class split less
> visible without a major rewrite. For instance, lists could have a
> __getitem__ method so that they "act like" instances. Instances could
> return their methods in a dir() so that they "act like" built-in
> objects. So there is no reason to wait for a complete rewrite to start
> on this path.

Right. I didn't want to say that things cannot be done prior
to the rewrite, only that a rewrite will give us much more
options that we currently have.

>  * It may even be the case that we can get from here to complete merged
> type/class semantics WITHOUT a rewrite. If a mad genious had not written
> stackless Python I would have sworn up and down that stackless Python
> would require a Python rewrite. It didn't. If another slightly less mad
> genious had not integrated ints and longs I would never have believed it
> possible without another rewrite. Someone needs to do an analysis of
> what it takes to merge types and classes and *demonstrate* that it
> requires a rewrite rather than *asserting* that it requires a rewrite.
>
> In other words, let's stop sprinkling the "major rewrite" pixie dust on
> hard problems and instead decide where we want to go and how we want to
> get there!

See above.
 
> > Moving to a common and very low-level strategy for classes
> > will allows us to put even the most basic types (strings and
> > numbers) into an inheritence tree.
> 
> I don't know what you mean by a "low-level strategy" for classes. It's
> not like we can somehow use C++ vtables without giving up Python's
> dynamicity. Python's class handling is about as low-level as it can get
> in my humble opinion.

With "low-level" I meant trying to build Python classes and
instances on top of a very thin layer on top of C++ classes,
e.g. all slots could be implemented using true C++ methods with
additional logic to override them using dynamically bound
Python method objects.

> > Differences like the
> > ones between Unicode and 8-bit strings would then flesh
> > out as two different subclasses of a generic string type which
> > again is based on a generic sequence type.
> 
> Of course that's where we want to go but it doesn't avoid the backwards
> compatibility problems.

Huh ? I was talking about clear design... not ways to avoid
b/w compatibility. Merging Unicode and strings will hurt one
way or another. This is simply a consequence of using strings
as binary containers where Unicode is meant for text only use.

> We can do this today using proxying.

Could you explain this ?
 
> > The same could be done for dictionaries: special ones for
> > just string keys, case insensitive lookups, etc. could all
> > be subclasses of a generic mapping class.
> 
> We can easily do this today.

No we can't: Python's use of pointer compares to find out
which type it is dealing with prevent this.
 
> > Dito for numbers (and division strategies).
> 
> There's no way I'm going to let you get away with that little sleight of
> hand. How is inheritance holy water going to allow us to change the
> semantics of:
> 
> 5/2
> 
> without breaking code??
> 
> The same goes for
> 
> a.b = 5
> 
> versus
> 
> a.B = 5
> 
> C++ does not help. Inheritance does not help. Pluggable compilers do not
> help. We *will* break code. We just need to decide whether to do it in a
> thoughtful way that gives people a chance to migrate or put off
> decisions until the last possible moment and then spring it on them with
> no between-version upgrade path.

Just tell Python to use the correct class for what the
code was written for (and this could be done by plugging in
a 2.0 compiler). The instances of those classes would still work
together with other semantics by virtue of exposing the same
interface, yet the internals would work differently, e.g.
a module using case insensitive lookup would be compiled using
case insensitive dictionaries as namespaces.

> > By following this principle there won't be all that much
> > breakage, since the old functionality will still be around,
> > only the defaults will have changed.
> 
> When you change defaults you break code. Keeping the old functionality
> around is barely helpful.  Nobody has EVER proposed a change to Python
> where something that was previously possible is now made impossible. So
> whatever our strategy, the PROBLEM is changing defaults. The solution is
> telling people what defaults are changing in what timeline and
> discouraging them from depending on the old defaults.

All true. I was just referring to the possibility of keeping
the old semantics around in case some module relies on them.
In this ideal world, a simple "define pythonlevel=2.0"
would suffice to make the old module work with Py3k.
 
> > Add to this pluggable compilers and ceval loops, plus a nice
> > way of configuring the lot on a per-module basis and you're
> > set. (Ok, it's a fluffy clouds image, but you get the picture ;-)
> 
> Sounds mythical. I'm trying to take it out of the realm of fluffy clouds
> and bring it into the world that people can plan their businesses and
> coding strategies around.

Hmm, wasn't Py3k meant as sandbox for new experiments ? 
The 2.x series is for doing business with, IMHO at least. 

At the current dev speed we'll have plenty of time to get Py3k
rock solid. Then we can add all the backward compatibility layers
we want to it. If the design is a good, adding these layers
won't pose much of a problem.

Why spoil all the fun when we haven't even started thinking
about all the possibilities we could use to make Py3k a
success ?

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From mal at lemburg.com  Tue Oct 24 21:54:39 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Tue, 24 Oct 2000 21:54:39 +0200
Subject: [Python-Dev] A small step to removing the type/class split
References: <20001024045611.B9993@glacier.fnational.com>
Message-ID: <39F5E8FF.5F18C71E@lemburg.com>

Neil Schemenauer wrote:
> 
> I've run into a problem with ExtensionClass which I believe can
> only be fixed by modifying Python.  I will try to explain.
> 
> I have an ExtensionClass which defines __cmp__.  Depending on the
> objects being compared, the __cmp__ method may never be called.
> This is due to code in object.c that looks like this:
> 
>     if (PyInstance_Check(v) || PyInstance_Check(w)) {
>         try to use use __cmp__ method
>     }
>     else {
>         try number coerce and fall back on type name comparison
>     }
> 
> Extension classes can never pass the PyInstance_Check predicate.
> I've searched for all occurances of PyInstance_Check in the 2.0
> source.  In many places that PyInstance_Check occurs a more
> general "is this an instance-like type" check would seem to be
> more suitable.
> 
> Here is my proposal:
> 
>   * Define a new type flag Py_TPFLAGS_INSTANCE.
>   * Create a new predicate Py_IsInstance which checks for this
>     flag.
>   * Set this flag on PyInstance_Type.
>   * Replace most occurances of PyInstance_Check with
>     Py_IsInstance.
> 
> Extension types (like ExtensionClass) can then define the type
> flag Py_TPLAGS_INSTANCE and be treated as an instance type by the
> Python interpreter.  This should make it quite a bit easier to make
> extension types behave like "real" classes.
> 
> Comments?

Sounds fine, except that the "isinstance()" behaviour would
have to be defined somewhere / somehow... a mapping of slots
to __special_methods__ would be a good start.

BTW, mxProxy does some of this mapping already... you may want to 
have a look.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From gmcm at hypernet.com  Tue Oct 24 22:01:25 2000
From: gmcm at hypernet.com (Gordon McMillan)
Date: Tue, 24 Oct 2000 16:01:25 -0400
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: <Pine.LNX.4.10.10010241355360.6622-100000@akbar.nevex.com>
References: <200010241739.MAA16414@cj20424-a.reston1.va.home.com>
Message-ID: <39F5B255.22108.49A43169@localhost>

Greg Wilson:
> > > 2. (Lack of) native look and feel.  This is a complete show-stopper for
> > >    many of the outfits I've dealt with (and not just with Python).
> 
> > Guido van Rossum:
> > Really?  Are you sure that's not just general resistence against new things?
> 
> Well, my students' resistance to novelty is low enough that they're willing to
> take a Python course :-).  This comes up every time I teach; no idea whether it
> has any impact on the usability of completed applications, but I believe it
> makes people less likely to choose Tkinter when starting development.

As I see it, Tk, like SQL, has the property that it's dead easy 
to get something crappy running, but it takes a real expert 
(like /F) to make it good. With wxPython, though, it's easy (if 
somewhat tedious) to get something good - at least as far as 
normal "forms" style GUIs.

I'm not taking sides - I dabble in both and will never be an 
expert at either. But for clients using Windows, I use 
wxPython because it's indistinguishable from native Win32.

(BTW, MFC is lagging further and further behind native Win32 -
 I believe MS considers it "legacy".)

- Gordon



From barry at wooz.org  Tue Oct 24 22:06:23 2000
From: barry at wooz.org (Barry A. Warsaw)
Date: Tue, 24 Oct 2000 16:06:23 -0400 (EDT)
Subject: [Python-Dev] A small step to removing the type/class split
References: <20001024045611.B9993@glacier.fnational.com>
Message-ID: <14837.60351.887533.801888@anthem.concentric.net>

>>>>> "NS" == Neil Schemenauer <nas at arctrix.com> writes:

    NS> I've run into a problem with ExtensionClass which I believe
    NS> can only be fixed by modifying Python.  I will try to explain.

    NS> I have an ExtensionClass which defines __cmp__.  Depending on
    NS> the objects being compared, the __cmp__ method may never be
    NS> called.  This is due to code in object.c that looks like this:

    |     if (PyInstance_Check(v) || PyInstance_Check(w)) {
    |         try to use use __cmp__ method
    |     }
    |     else {
    |         try number coerce and fall back on type name comparison
    |     }

I hit a similar wall when I tried (a long time ago) to take a boolean
class I'd written in Python and make it a built-in type.  The problem
was that in Python I could compare a Boolean instance against any
other object for truth equivalence, but because of this hack, I
couldn't do the same with the built-in type.

    |   * Define a new type flag Py_TPFLAGS_INSTANCE.
    |   * Create a new predicate Py_IsInstance which checks for this
    |     flag.
    |   * Set this flag on PyInstance_Type.
    |   * Replace most occurances of PyInstance_Check with
    |     Py_IsInstance.

    NS> Extension types (like ExtensionClass) can then define the type
    NS> flag Py_TPLAGS_INSTANCE and be treated as an instance type by
    NS> the Python interpreter.  This should make it quite a bit
    NS> easier to make extension types behave like "real" classes.

I'm not sure how well this addresses what I ran into.  Would
PyBooleanObject then have to have it's Py_TPFLAGS_INSTANCE flag set?
Does that actually make sense?  How does this interact with the rich
comparisons idea?  Seems like this is a hack that doesn't quite get at
the heart of the matter, worthwhile as it may be given the current
implementation.

-Barry



From barry at wooz.org  Tue Oct 24 22:11:54 2000
From: barry at wooz.org (Barry A. Warsaw)
Date: Tue, 24 Oct 2000 16:11:54 -0400 (EDT)
Subject: [Python-Dev] getting at the current frame
Message-ID: <14837.60682.437334.797392@anthem.concentric.net>

I've been playing around with ideas for internationalizing Mailman,
which naturally <wink> leads to string interpolation.  To see why,
think about making the following code translatable:

    def trade(yours, mine):
	print 'if you give me %s, i will give you %s' % (yours, mine)

Because the order of the interpolated values may change in the
translated string, you really have to do something like:

    def trade(yours, mine):
	print 'if you give me %(yours)s, i will give you %(mine)s' % {
	    'yours': yours,
	    'mine' : mine,
	    }

which actually will look something like this in real code:

    def trade(yours, mine):
	print _('if you give me %(yours)s, i will give you %(mine)s') % {
	    'yours': yours,
	    'mine' : mine,
	    }

The string wrapped in _() is what gets translated here.

Okay, we all know that's a pain, right?  Lots of people have proposed
solutions.  I've looked briefly at !?ng's Itpl.py, but I think it
probably does too much by adding evaluation.

I can define _() to make the problem somewhat more convenient:

    def _(s):
	try:
	    raise Exception
	except Exception:
	    frame = sys.exc_info()[2].tb_frame.f_back
	d = frame.f_globals.copy()
	d.update(frame.f_locals())
	return the_translation_of(s) % d

Now I can write the code like this:

    def trade(yours, mine):
	print _('if you give me %(yours)s, i will give you %(mine)s')

All well and good and doable in Python today, except getting the
current frame with the exception raising trick is slooow.  A simple
proposed addition to the sys module can improve the performance by
about 8x:

    def _(s):
        frame = sys.getcaller(1)
	d = frame.f_globals.copy()
	d.update(frame.f_locals())
	return the_translation_of(s) % d

The implementation of sys.getcaller() is given in the below patch.
Comments?  I think this particular addition is too small for a PEP,
although ?!ng still owns PEP 215 (which needs filling in).

-Barry

-------------------- snip snip --------------------
Index: sysmodule.c
===================================================================
RCS file: /cvsroot/python/python/dist/src/Python/sysmodule.c,v
retrieving revision 2.78
diff -u -r2.78 sysmodule.c
--- sysmodule.c	2000/09/01 23:29:28	2.78
+++ sysmodule.c	2000/10/24 17:50:30
@@ -15,6 +15,8 @@
 */
 
 #include "Python.h"
+#include "compile.h"
+#include "frameobject.h"
 
 #include "osdefs.h"
 
@@ -284,6 +286,38 @@
 }
 #endif
 
+static char getcaller_doc[] =
+"getcaller([depth]) -> frameobject\n\
+\n\
+By default, return the frame object at the top of the call stack.  If an\n\
+integer depth is given, return the frame object that many calls below the\n\
+top of the stack.  If that is deeper than the call stack, a ValueError is\n\
+raised.";
+
+
+static PyObject *
+sys_getcaller(PyObject *self, PyObject *args)
+{
+	PyFrameObject *f = PyThreadState_Get()->frame;
+	int depth = -1;
+
+	if (!PyArg_ParseTuple(args, "|i:getcaller", &depth))
+		return NULL;
+
+	while (depth > 0 && f != NULL) {
+		f = f->f_back;
+		--depth;
+	}
+	if (f == NULL) {
+		PyErr_SetString(PyExc_ValueError,
+				"call stack is not deep enough");
+		return NULL;
+	}
+	Py_INCREF(f);
+	return (PyObject*)f;
+}
+
+
 #ifdef Py_TRACE_REFS
 /* Defined in objects.c because it uses static globals if that file */
 extern PyObject *_Py_GetObjects(PyObject *, PyObject *);
@@ -313,6 +347,7 @@
 	{"getrefcount",	sys_getrefcount, 1, getrefcount_doc},
 	{"getrecursionlimit", sys_getrecursionlimit, 1,
 	 getrecursionlimit_doc},
+	{"getcaller", sys_getcaller, 1, getcaller_doc},
 #ifdef USE_MALLOPT
 	{"mdebug",	sys_mdebug, 1},
 #endif



From nas at arctrix.com  Tue Oct 24 15:45:35 2000
From: nas at arctrix.com (Neil Schemenauer)
Date: Tue, 24 Oct 2000 06:45:35 -0700
Subject: [Python-Dev] A small step to removing the type/class split
In-Reply-To: <14837.60351.887533.801888@anthem.concentric.net>; from barry@wooz.org on Tue, Oct 24, 2000 at 04:06:23PM -0400
References: <20001024045611.B9993@glacier.fnational.com> <14837.60351.887533.801888@anthem.concentric.net>
Message-ID: <20001024064535.A10253@glacier.fnational.com>

On Tue, Oct 24, 2000 at 04:06:23PM -0400, Barry A. Warsaw wrote:

[on Py_TPLAGS_INSTANCE]
> I'm not sure how well this addresses what I ran into [with a
> boolean extension type].  Would PyBooleanObject then have to
> have it's Py_TPFLAGS_INSTANCE flag set?  Does that actually
> make sense?

I think it would address your problem but I don't know if the
name of the flag makes sense.  Code around PyInstance_Check()
usually looks like this:

    if (PyInstance_Check(obj)) {
        PyObject *foo = PyObject_GetAttrString(obj, "__foo__");
        ...
    }
    else {
        ...
    }

There is not a lot of code that assumes (obj->ob_type ==
PyInstance_Type) after a PyInstance_Check().  That's encouraging.

> How does this interact with the rich comparisons idea?

I don't know.  I think I am trying to a address a deeper problem
here.

> Seems like this is a hack that doesn't quite get at the heart
> of the matter, worthwhile as it may be given the current
> implementation.

Yes, I have that feeling as well.  More deep thinking is probably
required. :)

  Neil




From mal at lemburg.com  Tue Oct 24 22:45:28 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Tue, 24 Oct 2000 22:45:28 +0200
Subject: [Python-Dev] getting at the current frame
References: <14837.60682.437334.797392@anthem.concentric.net>
Message-ID: <39F5F4E8.1188E1E0@lemburg.com>

"Barry A. Warsaw" wrote:
> [...]
> All well and good and doable in Python today, except getting the
> current frame with the exception raising trick is slooow.  A simple
> proposed addition to the sys module can improve the performance by
> about 8x:
> 
>     def _(s):
>         frame = sys.getcaller(1)
>         d = frame.f_globals.copy()
>         d.update(frame.f_locals())
>         return the_translation_of(s) % d
> 
> The implementation of sys.getcaller() is given in the below patch.
> Comments?  I think this particular addition is too small for a PEP,
> although ?!ng still owns PEP 215 (which needs filling in).

+1. 

I have a similar function in mxTools. I would use a different
name though... something like "sys.getframe()".

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From guido at python.org  Tue Oct 24 23:50:32 2000
From: guido at python.org (Guido van Rossum)
Date: Tue, 24 Oct 2000 16:50:32 -0500
Subject: [Python-Dev] A small step to removing the type/class split
In-Reply-To: Your message of "Tue, 24 Oct 2000 04:56:11 MST."
             <20001024045611.B9993@glacier.fnational.com> 
References: <20001024045611.B9993@glacier.fnational.com> 
Message-ID: <200010242150.QAA19518@cj20424-a.reston1.va.home.com>

> I've run into a problem with ExtensionClass which I believe can
> only be fixed by modifying Python.  I will try to explain.
> 
> I have an ExtensionClass which defines __cmp__.  Depending on the
> objects being compared, the __cmp__ method may never be called.
> This is due to code in object.c that looks like this:
> 
>     if (PyInstance_Check(v) || PyInstance_Check(w)) {
>         try to use use __cmp__ method
>     }
>     else {
>         try number coerce and fall back on type name comparison
>     }
> 
> Extension classes can never pass the PyInstance_Check predicate.
> I've searched for all occurances of PyInstance_Check in the 2.0
> source.  In many places that PyInstance_Check occurs a more
> general "is this an instance-like type" check would seem to be
> more suitable.
> 
> Here is my proposal:
> 
>   * Define a new type flag Py_TPFLAGS_INSTANCE.
>   * Create a new predicate Py_IsInstance which checks for this
>     flag.
>   * Set this flag on PyInstance_Type.
>   * Replace most occurances of PyInstance_Check with
>     Py_IsInstance.
> 
> Extension types (like ExtensionClass) can then define the type
> flag Py_TPLAGS_INSTANCE and be treated as an instance type by the
> Python interpreter.  This should make it quite a bit easier to make
> extension types behave like "real" classes.
> 
> Comments?

Good analysis of a problem -- but I disagree on the solution.

Rather than formalizing the exceptions made for instances, we should
work on eradicating the differences between classes and types.  I
believe that the plans for rich comparisons would or could also take
care of this.  I hope I'll have more time soon to explore this.

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



From barry at wooz.org  Tue Oct 24 22:49:04 2000
From: barry at wooz.org (barry at wooz.org)
Date: Tue, 24 Oct 2000 16:49:04 -0400 (EDT)
Subject: [Python-Dev] getting at the current frame
References: <14837.60682.437334.797392@anthem.concentric.net>
	<39F5F4E8.1188E1E0@lemburg.com>
Message-ID: <14837.62912.897422.392307@anthem.concentric.net>

>>>>> "M" == M  <mal at lemburg.com> writes:

    M> I have a similar function in mxTools. I would use a different
    M> name though... something like "sys.getframe()".

Works for me.

Thanks,
-Barry



From guido at python.org  Wed Oct 25 00:16:00 2000
From: guido at python.org (Guido van Rossum)
Date: Tue, 24 Oct 2000 17:16:00 -0500
Subject: [Python-Dev] Re: getting at the current frame
In-Reply-To: Your message of "Tue, 24 Oct 2000 17:04:11 -0400."
             <14837.63819.667508.794728@anthem.concentric.net> 
References: <14837.52425.84457.36757@anthem.concentric.net> <14837.53353.79747.421223@cj42289-a.reston1.va.home.com> <14837.60401.939234.320786@anthem.concentric.net> <200010242155.QAA19570@cj20424-a.reston1.va.home.com>  
            <14837.63819.667508.794728@anthem.concentric.net> 
Message-ID: <200010242216.RAA19692@cj20424-a.reston1.va.home.com>

>     GvR> Agreed.  I think it's good to have the functionality
>     GvR> available, but it's also good to make it *real* clear not to
>     GvR> mess with it unless you really know what you're doing.  Maybe
>     GvR> it should be in a separate module or at least have a leading
>     GvR> _underscore.
> 
> I think you're fairly safe from mischief since the only writable
> attributes of a frame object are f_trace, f_exc_type, f_exc_value, and
> f_exc_traceback.  The same caveats about f_globals and f_locals apply
> as with the dicts returned by locals() and globals().

It's not so much that it's easy to do damage with.  I have a
philosophical problem with making this a feature that people can use
whenever they feel like.  It's a messy feature and its use should
limited as an implementation aid for language features like variable
substitution.

The other, perhaps more major, problem with this it is that you can't
easily wrap functions that use it in other functions.  Normally, if
there's a function foo(arg) that does something, I can write a
function wrapfoo(arg) that does something else, then calls foo(arg),
and then does another thing.  But if foo() uses getframe(), that's not
so easy: the call to foo() in wrapfoo() will access wrapfoo()'s frame.

A way around this would be to implement foo as a call to (e.g.)
_foo(arg, frame), and define foo(arg) as _foo(arg, sys.getframe()).
Then _wrapfoo(arg, frame) could be defined as a wrapper around
_foo(arg, frame) and wrapfoo(arg) as _wrapfoo(arg, sys.getframe()).

This is another reason to be very selective in the use of getframe().

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



From nas at arctrix.com  Tue Oct 24 16:37:12 2000
From: nas at arctrix.com (Neil Schemenauer)
Date: Tue, 24 Oct 2000 07:37:12 -0700
Subject: [Python-Dev] A small step to removing the type/class split
In-Reply-To: <200010242150.QAA19518@cj20424-a.reston1.va.home.com>; from guido@python.org on Tue, Oct 24, 2000 at 04:50:32PM -0500
References: <20001024045611.B9993@glacier.fnational.com> <200010242150.QAA19518@cj20424-a.reston1.va.home.com>
Message-ID: <20001024073712.A10539@glacier.fnational.com>

On Tue, Oct 24, 2000 at 04:50:32PM -0500, Guido van Rossum wrote:
> Rather than formalizing the exceptions made for instances, we
> should work on eradicating the differences between classes and
> types.

Yes, I see this now.  Those PyInstance_Check() calls should
really go away.  Instead, the type should be responsible for
providing different behavior.

> I believe that the plans for rich comparisons would or could
> also take care of this.

I've just briefly looked at the proposal.  It consists of two
parts.  One is splitting __cmp__ into __gt__, __lt__, etc.  That
is a separate issue to the one we are dicussing.  The other part
is directly related.  In order for types to define their own
comparison behavior, it proposes that types have an optional
pointer to a rich comparison function in the type structure.  I
think this is the right idea but it doesn't go far enough.  Every
operation should be implementable by the type.  Code like:

    if (PyString_Check(obj)) {
        something
    }
    else if (PyInstance_Check(obj)) {
        something else
    }
    ...

should disappear unless it is need for performance reasons.  I
think we are close to achieving this goal.  I'll try to come up
with a proposal.

  Neil



From barry at wooz.org  Tue Oct 24 23:34:54 2000
From: barry at wooz.org (barry at wooz.org)
Date: Tue, 24 Oct 2000 17:34:54 -0400 (EDT)
Subject: [Python-Dev] Re: getting at the current frame
References: <14837.52425.84457.36757@anthem.concentric.net>
	<14837.53353.79747.421223@cj42289-a.reston1.va.home.com>
	<14837.60401.939234.320786@anthem.concentric.net>
	<200010242155.QAA19570@cj20424-a.reston1.va.home.com>
	<14837.63819.667508.794728@anthem.concentric.net>
	<200010242216.RAA19692@cj20424-a.reston1.va.home.com>
Message-ID: <14838.126.77589.541148@anthem.concentric.net>

>>>>> "GvR" == Guido van Rossum <guido at python.org> writes:

    GvR> The other, perhaps more major, problem with this it is that
    GvR> you can't easily wrap functions that use it in other
    GvR> functions.  Normally, if there's a function foo(arg) that
    GvR> does something, I can write a function wrapfoo(arg) that does
    GvR> something else, then calls foo(arg), and then does another
    GvR> thing.  But if foo() uses getframe(), that's not so easy: the
    GvR> call to foo() in wrapfoo() will access wrapfoo()'s frame.

    GvR> A way around this would be to implement foo as a call to
    GvR> (e.g.)  _foo(arg, frame), and define foo(arg) as _foo(arg,
    GvR> sys.getframe()).  Then _wrapfoo(arg, frame) could be defined
    GvR> as a wrapper around _foo(arg, frame) and wrapfoo(arg) as
    GvR> _wrapfoo(arg, sys.getframe()).

Darn good point.  So where could we put it?  It's a useful
introspection device.  If it goes in a separate module, should that
perhaps be called `reflection'?  Or maybe `runtime'?  Or maybe
"sys._getframe()" is good enough.

-Barry



From guido at python.org  Wed Oct 25 01:13:43 2000
From: guido at python.org (Guido van Rossum)
Date: Tue, 24 Oct 2000 18:13:43 -0500
Subject: [Python-Dev] Re: getting at the current frame
In-Reply-To: Your message of "Tue, 24 Oct 2000 17:34:54 -0400."
             <14838.126.77589.541148@anthem.concentric.net> 
References: <14837.52425.84457.36757@anthem.concentric.net> <14837.53353.79747.421223@cj42289-a.reston1.va.home.com> <14837.60401.939234.320786@anthem.concentric.net> <200010242155.QAA19570@cj20424-a.reston1.va.home.com> <14837.63819.667508.794728@anthem.concentric.net> <200010242216.RAA19692@cj20424-a.reston1.va.home.com>  
            <14838.126.77589.541148@anthem.concentric.net> 
Message-ID: <200010242313.SAA19938@cj20424-a.reston1.va.home.com>

> Darn good point.  So where could we put it?  It's a useful
> introspection device.  If it goes in a separate module, should that
> perhaps be called `reflection'?  Or maybe `runtime'?  Or maybe
> "sys._getframe()" is good enough.

sys._getframe() is good enough.

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



From DavidA at ActiveState.com  Wed Oct 25 01:08:28 2000
From: DavidA at ActiveState.com (David Ascher)
Date: Tue, 24 Oct 2000 16:08:28 -0700 (Pacific Daylight Time)
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: <14837.43273.24692.93965@buffalo.fnal.gov>
Message-ID: <Pine.WNT.4.21.0010241517480.1584-100000@loom>

> Back in my former life, when I was still worrying about Windows, the
> company I worked for bought into a commerical x-platform GUI toolkit
> called Galaxy (I mentioned this earlier).  Galaxy re-implemented all
> the native widgets, kind of like XPFE does.  One issue with this was
> that MS seemed to change something about the widgets in every release
> - e.g. the Galaxy filechooser looked like Windows 3.1, then Win95 came
> out and Galaxy had to play catch-up.  Once Galaxy had the Win95 LAF,
> Win98 came out.  Now I hear there's something called Windows ME.  Have
> they changed the look-and-feel again?  Seems to me like all the
> widget-reimplementors are doomed to playing eternal catch-up.

Back in a former life of _mine_, I was one of two people who understood
the architecture of Neuron Data's Open Interface Toolkit.  It used the
same strategy.  Not sure what that has to do with Python, though it was
a very fun project.  It was also fun to turn on the Mac 'theme' on a
Decwindows box (we're talking 1989 or so =).

The funniest story about that job involves Cray and black and white
monitors, but that's a story for another time, another place.

--da




From greg at cosc.canterbury.ac.nz  Wed Oct 25 01:18:59 2000
From: greg at cosc.canterbury.ac.nz (Greg Ewing)
Date: Wed, 25 Oct 2000 12:18:59 +1300 (NZDT)
Subject: [Python-Dev] Why not revive stdwin?
In-Reply-To: <20001023162118.B18005@kronos.cnri.reston.va.us>
Message-ID: <200010242318.MAA28238@s454.cosc.canterbury.ac.nz>

Andrew Kuchling <akuchlin at mems-exchange.org>:

> It seems to me that supporting MacOS is the big problem for
> cross-platform GUIs.

It appears that we can't rely on anyone else to provide and
support a GUI properly across all three platforms. If we
want one, it looks like we'll have to do it ourselves.

How about reviving and building upon stdwin? I quite liked
stdwin, despite its limitations, because it was small and simple,
and it worked on both Mac and Unix.

Greg Ewing, Computer Science Dept, +--------------------------------------+
University of Canterbury,	   | A citizen of NewZealandCorp, a	  |
Christchurch, New Zealand	   | wholly-owned subsidiary of USA Inc.  |
greg at cosc.canterbury.ac.nz	   +--------------------------------------+



From est at hyperreal.org  Tue Oct 24 23:58:43 2000
From: est at hyperreal.org (est at hyperreal.org)
Date: Tue, 24 Oct 2000 14:58:43 -0700 (PDT)
Subject: [Python-Dev] Re: getting at the current frame
In-Reply-To: <14838.126.77589.541148@anthem.concentric.net> from "barry@wooz.org"
 at "Oct 24, 2000 05:34:54 pm"
Message-ID: <20001024215843.7507.qmail@hyperreal.org>

barry at wooz.org discourseth:
> 
> Darn good point.  So where could we put it?  It's a useful
> introspection device.  If it goes in a separate module, should that
> perhaps be called `reflection'?  Or maybe `runtime'?  Or maybe
> "sys._getframe()" is good enough.

Hmm..I'd think `reification' instead of `reflection'.  My
understanding was that reification involves taking an implicit
language entity and making it an expressed value (e.g., getframe() or
call_with_current_continuation()) while reflection goes in the
opposite direction (e.g., eval()).

pedantically,

e



From greg at cosc.canterbury.ac.nz  Wed Oct 25 03:14:52 2000
From: greg at cosc.canterbury.ac.nz (Greg Ewing)
Date: Wed, 25 Oct 2000 14:14:52 +1300 (NZDT)
Subject: [Python-Dev] A small step to removing the type/class split
In-Reply-To: <20001024073712.A10539@glacier.fnational.com>
Message-ID: <200010250114.OAA28255@s454.cosc.canterbury.ac.nz>

Neil Schemenauer <nas at arctrix.com>:

> Those PyInstance_Check() calls should really go away. Instead, the
> type should be responsible for providing different behavior.

Yes, that's the crux of the problem, I think.

Another place where this is a nuisance is where it
assumes that if x has any tp_as_sequence slots and y
has any tp_as_number slots, then x*y is a sequence
replication operation.

Greg Ewing, Computer Science Dept, +--------------------------------------+
University of Canterbury,	   | A citizen of NewZealandCorp, a	  |
Christchurch, New Zealand	   | wholly-owned subsidiary of USA Inc.  |
greg at cosc.canterbury.ac.nz	   +--------------------------------------+




From esr at thyrsus.com  Wed Oct 25 06:56:27 2000
From: esr at thyrsus.com (Eric S. Raymond)
Date: Tue, 24 Oct 2000 21:56:27 -0700
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: <005f01c03ddc$dd52bb60$3c6340d5@hagrid>; from effbot@telia.com on Tue, Oct 24, 2000 at 06:59:23PM +0200
References: <14837.14407.954185.466011@buffalo.fnal.gov> <ECEPKNMJLHAPFFJHDOJBKEKIDOAA.MarkH@ActiveState.com> <14837.43273.24692.93965@buffalo.fnal.gov> <20001024114326.E13957@kronos.cnri.reston.va.us> <005f01c03ddc$dd52bb60$3c6340d5@hagrid>
Message-ID: <20001024215627.B1147@thyrsus.com>

Fredrik Lundh <effbot at telia.com>:
> > Can someone articulate why Tk should be replaced?
> 
> beats me ;-)

My main reason is that Tcl is in trouble, and I fear Tcl/Tk may become
effectively unmaintained in the foreseeable future.
-- 
		<a href="http:///~esr/">Eric S. Raymond</a>

Rapists just *love* unarmed women.  And the politicians who disarm them.



From esr at thyrsus.com  Wed Oct 25 07:29:17 2000
From: esr at thyrsus.com (Eric S. Raymond)
Date: Tue, 24 Oct 2000 22:29:17 -0700
Subject: [Python-Dev] Why not revive stdwin?
In-Reply-To: <200010242318.MAA28238@s454.cosc.canterbury.ac.nz>; from greg@cosc.canterbury.ac.nz on Wed, Oct 25, 2000 at 12:18:59PM +1300
References: <20001023162118.B18005@kronos.cnri.reston.va.us> <200010242318.MAA28238@s454.cosc.canterbury.ac.nz>
Message-ID: <20001024222917.I1147@thyrsus.com>

Greg Ewing <greg at cosc.canterbury.ac.nz>:
> It appears that we can't rely on anyone else to provide and
> support a GUI properly across all three platforms. If we
> want one, it looks like we'll have to do it ourselves.

I fear this is much too big a job to be practical -- not just in the
additional code but the downstream maintainance.
-- 
		<a href="http:///~esr/">Eric S. Raymond</a>

"I hold it, that a little rebellion, now and then, is a good thing, and as 
necessary in the political world as storms in the physical."
	-- Thomas Jefferson, Letter to James Madison, January 30, 1787



From barry at wooz.org  Wed Oct 25 05:11:54 2000
From: barry at wooz.org (Barry A. Warsaw)
Date: Tue, 24 Oct 2000 23:11:54 -0400 (EDT)
Subject: [Python-Dev] Re: getting at the current frame
References: <14837.52425.84457.36757@anthem.concentric.net>
	<14837.53353.79747.421223@cj42289-a.reston1.va.home.com>
	<14837.60401.939234.320786@anthem.concentric.net>
	<200010242155.QAA19570@cj20424-a.reston1.va.home.com>
	<14837.63819.667508.794728@anthem.concentric.net>
	<200010242216.RAA19692@cj20424-a.reston1.va.home.com>
	<14838.126.77589.541148@anthem.concentric.net>
	<200010242313.SAA19938@cj20424-a.reston1.va.home.com>
Message-ID: <14838.20346.451094.231019@anthem.concentric.net>

>>>>> "GvR" == Guido van Rossum <guido at python.org> writes:

    GvR> sys._getframe() is good enough.

Cool, I'll upload the patch to SF.

-Barry



From barry at wooz.org  Wed Oct 25 05:44:10 2000
From: barry at wooz.org (Barry A. Warsaw)
Date: Tue, 24 Oct 2000 23:44:10 -0400 (EDT)
Subject: [Python-Dev] Re: getting at the current frame
References: <14837.52425.84457.36757@anthem.concentric.net>
	<14837.53353.79747.421223@cj42289-a.reston1.va.home.com>
	<14837.60401.939234.320786@anthem.concentric.net>
	<200010242155.QAA19570@cj20424-a.reston1.va.home.com>
	<14837.63819.667508.794728@anthem.concentric.net>
	<200010242216.RAA19692@cj20424-a.reston1.va.home.com>
	<14838.126.77589.541148@anthem.concentric.net>
	<200010242313.SAA19938@cj20424-a.reston1.va.home.com>
	<14838.20346.451094.231019@anthem.concentric.net>
Message-ID: <14838.22282.676715.200546@anthem.concentric.net>

>>>>> "BAW" == Barry A Warsaw <barry at wooz.org> writes:

>>>>> "GvR" == Guido van Rossum <guido at python.org> writes:

    GvR> sys._getframe() is good enough.

    BAW> Cool, I'll upload the patch to SF.

Patch #102106

http://sourceforge.net/patch/?func=detailpatch&patch_id=102106&group_id=5470

(includes doc patch)

-Barry



From tim_one at email.msn.com  Wed Oct 25 09:10:36 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Wed, 25 Oct 2000 03:10:36 -0400
Subject: [Python-Dev] Gradual migration
In-Reply-To: <39F54C0F.25798309@lemburg.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCMELHHMAA.tim_one@email.msn.com>

[MAL]
> ...
> I think will simply be a consequence of doing a complete rewrite
> of the interpreter for Py3K.

Not just to be my usual self <wink>, but I do see a from-scratch rewrite as
being less likely as the years go by.  There's nothing I know of in Guido's
plans that can't be done incrementally instead -- and if he doesn't either,
selling a total- rewrite project to an employer is probably impossible.

The most successful projects I've seen and been on *did* rewrite all the
code routinely, but one subsystem at a time.  This happens when you're
tempted to add a hack, realize it wouldn't be needed if an entire area were
reworked, and mgmt is bright enough to realize that hacks compound in fatal
ways over time.  The "ain't broke, don't fix" philosophy is a good guide
here, provided you've got a very low threshold for insisting "it's broke"
<0.4 wink>.

if-you-would-have-liked-to-do-the-whole-differently-then-by-all-means-
    *do*-the-whole-thing-differently-that-works-in-c-too-ly y'rs  - tim





From moshez at math.huji.ac.il  Wed Oct 25 09:49:21 2000
From: moshez at math.huji.ac.il (Moshe Zadka)
Date: Wed, 25 Oct 2000 09:49:21 +0200 (IST)
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: <200010241739.MAA16414@cj20424-a.reston1.va.home.com>
Message-ID: <Pine.GSO.4.10.10010250923490.9960-100000@sundial>

On Tue, 24 Oct 2000, Guido van Rossum wrote:

> Maybe we can do the same for Unix binary distributions?

I don't know what you mean by "UNIX" binary distributions: each UNIX
has its own sets of horrors in the distribution arena. Personally, I
don't care what we do about RPMs, since I'm not a Red Hat user. However,
this should probably be more Red Hat's job then ours. Debian, on the
other hand, would probably do this much better then Python-Dev can,
without gratutitous Tcl/Tk installations. For other unices, most people
install from sources anyway, which mostly means I should get off my butt
and start working on the Sumo interpreter.

> Really?  Are you sure that's not just general resistence against new
> things?  To me, and I suspect may others, the app I use most often on
> Windows is Netscape -- talk about lack of native look-and-feel!  It's
> never bothered me all that much.

I don't know how to break this to you, but you're not the average computer
user <wink>.

--
Moshe Zadka <moshez at math.huji.ac.il>
There is no IGLU cabal.
http://advogato.org/person/moshez




From mal at lemburg.com  Wed Oct 25 10:10:46 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Wed, 25 Oct 2000 10:10:46 +0200
Subject: [Python-Dev] Gradual migration
References: <LNBBLJKPBEHFEDALKOLCMELHHMAA.tim_one@email.msn.com>
Message-ID: <39F69586.E017DA7E@lemburg.com>

Tim Peters wrote:
> 
> [MAL]
> > ...
> > I think this will simply be a consequence of doing a complete rewrite
> > of the interpreter for Py3K.
> 
> Not just to be my usual self <wink>, but I do see a from-scratch rewrite as
> being less likely as the years go by.  There's nothing I know of in Guido's
> plans that can't be done incrementally instead -- and if he doesn't either,
> selling a total- rewrite project to an employer is probably impossible.
>
> The most successful projects I've seen and been on *did* rewrite all the
> code routinely, but one subsystem at a time.  This happens when you're
> tempted to add a hack, realize it wouldn't be needed if an entire area were
> reworked, and mgmt is bright enough to realize that hacks compound in fatal
> ways over time.  The "ain't broke, don't fix" philosophy is a good guide
> here, provided you've got a very low threshold for insisting "it's broke"
> <0.4 wink>.

As I mentioned in the posting, the idea was from the "fluffy clouds"
area. The rewrite would only involve the core type system and perhaps
the core interpreter layout (parser, compiler, etc. all wrapped in
classes) -- most of the existing code would be reusable. 

The idea behind this is somewhat like what you do when starting out a
project based on a few simple functions and then reorganizing the
code into a class-based approach. There's no need to rewrite all 
the type internals, just the type interfaces. 

Python has long reached a level of complexity that is counter-
productive when it comes to adding new extension types. Just
think of all the problems people have with coercion, the integration
of user defined and internal types, the missing links between
types and classes, etc. etc.  

BTW, why all the talk about "employers" ? Much of Python's code
base was written without any employer knowing about it ;-)

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From jim at interet.com  Wed Oct 25 12:40:56 2000
From: jim at interet.com (James C. Ahlstrom)
Date: Wed, 25 Oct 2000 06:40:56 -0400
Subject: [Python-Dev] What to choose to replace Tkinter?
References: <14837.14407.954185.466011@buffalo.fnal.gov> <ECEPKNMJLHAPFFJHDOJBKEKIDOAA.MarkH@ActiveState.com> <14837.43273.24692.93965@buffalo.fnal.gov> <20001024114326.E13957@kronos.cnri.reston.va.us>
Message-ID: <39F6B8B8.E3242929@interet.com>

Andrew Kuchling wrote:

> Can someone articulate why Tk should be replaced?

I don't know whether Tk should replaced, but I
can explain why I don't use it for our commercial
Python application.

It is just too big and complicated.  Windows comes
with a built-in GUI, and I hesitate to install
another scripting language (Tcl) and its libraries,
and then install a big system which has frequently been
out of phase with Python releases just to access the
Windows GUI.

What if a user calls with a problem?  Why should I
have to debug their Tcl library path problems?  No
thanks.

JimA



From jim at interet.com  Wed Oct 25 12:47:05 2000
From: jim at interet.com (James C. Ahlstrom)
Date: Wed, 25 Oct 2000 06:47:05 -0400
Subject: [Python-Dev] What to choose to replace Tkinter?
References: <Pine.LNX.4.10.10010241146450.6622-100000@akbar.nevex.com> <200010241739.MAA16414@cj20424-a.reston1.va.home.com>
Message-ID: <39F6BA29.3CAB4C0E@interet.com>

Guido van Rossum wrote:

> > 2. (Lack of) native look and feel.  This is a complete show-stopper for
> >    many of the outfits I've dealt with (and not just with Python).
> 
> Really?  Are you sure that's not just general resistence against new
> things?  To me, and I suspect may others, the app I use most often on
> Windows is Netscape -- talk about lack of native look-and-feel!  It's
> never bothered me all that much.

In the past I have resolutely demanded native Windows look
and feel in my apps.  In fact, I have been tiresome on the topic.

Now I am changing my mind.  Lots of prominent Windows apps now
depart from Microsoft LAF, and I have the impression that users
are getting used to it.  I still think the usual File menu
items and file open/save dialogs should be standard, but I
am less concerned about other controls.  For a look
at how to really do controls, check out software for
kids.  Just my 1.e-2$.

JimA



From guido at python.org  Wed Oct 25 14:11:35 2000
From: guido at python.org (Guido van Rossum)
Date: Wed, 25 Oct 2000 07:11:35 -0500
Subject: [Python-Dev] Why not revive stdwin?
In-Reply-To: Your message of "Tue, 24 Oct 2000 22:29:17 MST."
             <20001024222917.I1147@thyrsus.com> 
References: <20001023162118.B18005@kronos.cnri.reston.va.us> <200010242318.MAA28238@s454.cosc.canterbury.ac.nz>  
            <20001024222917.I1147@thyrsus.com> 
Message-ID: <200010251211.HAA22128@cj20424-a.reston1.va.home.com>

> Greg Ewing <greg at cosc.canterbury.ac.nz>:
> > It appears that we can't rely on anyone else to provide and
> > support a GUI properly across all three platforms. If we
> > want one, it looks like we'll have to do it ourselves.

Eric Raymond:
> I fear this is much too big a job to be practical -- not just in the
> additional code but the downstream maintainance.

Well said.  The "roll your own" approach has been attempted before,
but simply isn't worth the time and effort.  After all, Python is a
glue language!

(And stdwin would really look pathetic in this time.)

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



From guido at python.org  Wed Oct 25 14:25:29 2000
From: guido at python.org (Guido van Rossum)
Date: Wed, 25 Oct 2000 07:25:29 -0500
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: Your message of "Wed, 25 Oct 2000 06:40:56 -0400."
             <39F6B8B8.E3242929@interet.com> 
References: <14837.14407.954185.466011@buffalo.fnal.gov> <ECEPKNMJLHAPFFJHDOJBKEKIDOAA.MarkH@ActiveState.com> <14837.43273.24692.93965@buffalo.fnal.gov> <20001024114326.E13957@kronos.cnri.reston.va.us>  
            <39F6B8B8.E3242929@interet.com> 
Message-ID: <200010251225.HAA22242@cj20424-a.reston1.va.home.com>

> Andrew Kuchling wrote:
> 
> > Can someone articulate why Tk should be replaced?

Jim Ahlstrom replied:

> I don't know whether Tk should replaced, but I
> can explain why I don't use it for our commercial
> Python application.
> 
> It is just too big and complicated.  Windows comes
> with a built-in GUI, and I hesitate to install
> another scripting language (Tcl) and its libraries,
> and then install a big system which has frequently been
> out of phase with Python releases just to access the
> Windows GUI.

To me this all sounds like FUD.  Since Python 1.6 and 2.0, you don't
have to install Tcl/Tk or its libraries -- it is installed
*transparently* by the Python Windows installer.  That's different --
and better -- than what happened in 1.5.2, where a separate Tcl/Tk
installer was optionally run.  The version issues are also resolved
this way: you are guaranteed to get exactly the Tcl/Tk version that
was tested by the developers.

> What if a user calls with a problem?  Why should I
> have to debug their Tcl library path problems?  No
> thanks.

The Tcl library paths are all taken care of by the new installer
strategy.

Really, give it a try.  It Just Works! (SM)

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



From guido at python.org  Wed Oct 25 14:27:28 2000
From: guido at python.org (Guido van Rossum)
Date: Wed, 25 Oct 2000 07:27:28 -0500
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: Your message of "Wed, 25 Oct 2000 06:47:05 -0400."
             <39F6BA29.3CAB4C0E@interet.com> 
References: <Pine.LNX.4.10.10010241146450.6622-100000@akbar.nevex.com> <200010241739.MAA16414@cj20424-a.reston1.va.home.com>  
            <39F6BA29.3CAB4C0E@interet.com> 
Message-ID: <200010251227.HAA22256@cj20424-a.reston1.va.home.com>

> In the past I have resolutely demanded native Windows look
> and feel in my apps.  In fact, I have been tiresome on the topic.
> 
> Now I am changing my mind.  Lots of prominent Windows apps now
> depart from Microsoft LAF, and I have the impression that users
> are getting used to it.  I still think the usual File menu
> items and file open/save dialogs should be standard, but I
> am less concerned about other controls.  For a look
> at how to really do controls, check out software for
> kids.  Just my 1.e-2$.

Even Microsoft is violating its own (boring) style guide, when they
think it appeals to a specific audience.  Have you seen their Media
Player?

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



From jim at digicool.com  Wed Oct 25 14:21:41 2000
From: jim at digicool.com (Jim Fulton)
Date: Wed, 25 Oct 2000 08:21:41 -0400
Subject: [Python-Dev] A small step to removing the type/class split
References: <20001024045611.B9993@glacier.fnational.com> <200010242150.QAA19518@cj20424-a.reston1.va.home.com>
Message-ID: <39F6D055.584C4FEA@digicool.com>

Guido van Rossum wrote:
> 
(snip)
> Rather than formalizing the exceptions made for instances, we should
> work on eradicating the differences between classes and types. 

Yee ha! I couldn't agree more. :)

> I believe that the plans for rich comparisons would or could also take
> care of this. 

I assume that rich comparison's have new slots with signatures
that don't assume objects of the same type.

> I hope I'll have more time soon to explore this.

Me too.

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 jim at digicool.com  Wed Oct 25 14:25:53 2000
From: jim at digicool.com (Jim Fulton)
Date: Wed, 25 Oct 2000 08:25:53 -0400
Subject: [Python-Dev] A small step to removing the type/class split
References: <20001024045611.B9993@glacier.fnational.com>
Message-ID: <39F6D151.70F47CFF@digicool.com>

Neil Schemenauer wrote:
> 
> I've run into a problem with ExtensionClass which I believe can
> only be fixed by modifying Python.  I will try to explain.
> 
> I have an ExtensionClass which defines __cmp__.  Depending on the
> objects being compared, the __cmp__ method may never be called.
> This is due to code in object.c that looks like this:
> 
>     if (PyInstance_Check(v) || PyInstance_Check(w)) {
>         try to use use __cmp__ method
>     }
>     else {
>         try number coerce and fall back on type name comparison
>     }
> 
> Extension classes can never pass the PyInstance_Check predicate.
> I've searched for all occurances of PyInstance_Check in the 2.0
> source.  In many places that PyInstance_Check occurs a more
> general "is this an instance-like type" check would seem to be
> more suitable.
> 
> Here is my proposal:

(snip)

I think you got some good answers later in the thread.

I'll point out that a work around is to make your ExtensionClass
a numeric type.  Numeric types have different comparison 
semantics that allow you to get around this limitation.
I did this a few months back for acquisition wrappers.

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 gvwilson at nevex.com  Wed Oct 25 14:38:12 2000
From: gvwilson at nevex.com (Greg Wilson)
Date: Wed, 25 Oct 2000 08:38:12 -0400 (EDT)
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: <200010241904.OAA19165@cj20424-a.reston1.va.home.com>
Message-ID: <Pine.LNX.4.10.10010250820030.2415-100000@akbar.nevex.com>

> Guido van Rossum:
> Can you elaborate on the line of argument that you typically hear
> [objections to Tkinter]? What do you say to dispel it?


From guido at python.org  Wed Oct 25 15:53:48 2000
From: guido at python.org (Guido van Rossum)
Date: Wed, 25 Oct 2000 08:53:48 -0500
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: Your message of "Wed, 25 Oct 2000 08:38:12 -0400."
             <Pine.LNX.4.10.10010250820030.2415-100000@akbar.nevex.com> 
References: <Pine.LNX.4.10.10010250820030.2415-100000@akbar.nevex.com> 
Message-ID: <200010251353.IAA28190@cj20424-a.reston1.va.home.com>

> From some feedback forms from old runs of my Python course (with spelling
> corrections :-)
> 
> 1. "My users don't care what programs are written in.  They just care
>    if they're easy to use.  They won't care if Python programs have
>    the same look and feel on different computers, because they won't
>    ever think of [name of program] as a Python program.  To them, it
>    will be a Windows program that looks funny."
> 
> 2. "You said three times in the intro lecture this morning that the
>    most important thing in a GUI was consistency.  Then you told us to
>    write GUIs that look different from everything else on the desktop."
> 
> 3. "I'm confused: I didn't realize that Python was a library on top of
>    TCL."
> 
> I spent a minute drawing blob diagrams to answer #3; I think most students
> understood, but the person who asked the question was clearly still confused.
> 
> I didn't try to dispel #1 or #2, because I agree with them: my
> experience is that consistent look and feel are crucial for making
> non-programmers less afraid of pressing the wrong button or making
> the program "do weird things".  Other people with more experience
> creating end-user applications may have different views.

This is helpful.  Can you elaborate on what elements of the Windows
look-and-feel are missing in Tkinter?  As far as I know, the menu
bars, file selection dialogs, scroll bars, dialog boxes and so on have
a thoroughly native look-and-feel, since Tk implements these as
wrappers around the native widgets.  IDLE doesn't look very different
from Notepad!

So what's missing?  A toolbar with icons?  That would be easy to add
using existing Tk controls (Pmw has it too).  The multiple document
interface?  It sucks -- and even Word 2000 has gone away from that!

What kind of GUIs did you teach them exactly?  If you started with
basic Tkinter widgets, sure, it looks different than anything else.
But that depends on the widget layout in the program, not on the
widget library used!

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



From barry at scottb.demon.co.uk  Wed Oct 25 15:55:40 2000
From: barry at scottb.demon.co.uk (Barry Scott)
Date: Wed, 25 Oct 2000 14:55:40 +0100
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: <200010251353.IAA28190@cj20424-a.reston1.va.home.com>
Message-ID: <002301c03e8b$42cbc280$060210ac@private>

I choose to use wxPython over TK because:

1. wxPython has a reasonable event model
2. wxPython allows me build one object hierarchy
3. TK requires I manage two object hierarchies, TK's and my classes
4. Hooking events to TK seems clumsy from Python

As others have said better docs on wxPython would be nice
and its to easy to crash the world from wxPython.

		Barry




From claird at starbase.neosoft.com  Wed Oct 25 16:58:53 2000
From: claird at starbase.neosoft.com (Cameron Laird)
Date: Wed, 25 Oct 2000 09:58:53 -0500 (CDT)
Subject: [Python-Dev] Miscellaneous comments on Tkinter and related matters
Message-ID: <200010251458.JAA77237@starbase.neosoft.com>

I can rarely afford to dip into Python-Dev.  My head is exploding
too much of the time as it is.

Maybe I can help with the recent Tkinter discussions, though.
1.  Tcl's going to be around for a long time.
    Here's the insider scoop on what the Ajuba
    Solutions announcement means:  insiders
    don't know.  That is, *nobody* is sure how
    Tcl will develop.

    It'll survive, though, for quite a while.
    Do NOT worry that it'll suddenly dry up
    and blow away.

    I'm working on a more detailed explanation
    of Tcl processes.  It'll probably take a
    few weeks, though.  In the meantime, just
    ignore the mess, and understand that the
    Tcl Core Team includes bright people who'll
    land on their feet somehow.
2.  I agree that MacOS is the thorny problem for
    the standard Pysolution.  I'd be happy to
    discuss the possibilities (Tkinter?  wxWindows?
    Qt?!? GTK+?!!?!? ...) with a smaller group,
    and, of course, Fredrik, Robin, Guido, ...
    all are quite knowledgeable about these
    matters.

    There are a few things you should know about
    the Tcl side.  The bad is that Tk is barely
    maintained for MacOS.  It's really rather
    miserable.  On the other hand, Jim Ingham is
    now an Apple employee, and things could change
    in a hurry, at any time.

    The good is that Tk starts far ahead of any
    competitor.  It has already solved most of
    the hard problems.  All it needs is a little
    maintenance.
3.  Is there a way to have Tk without contamination
    by Tcl?  More than ever.  This is what makes me
    most cheerful about Tkinter's prospects.  The
    Tcl Core Team has largely given up its hangups
    about co-operating with foreigners (or its
    hangups that barbarians have hangups about co-
    operating with Tcl).  This is a *very* good
    time for someone like Fredrik to establish a
    working relationship, and get CVS access.  I
    really think Tk can be maintained by a different
    group than Tcl.

    Perl, Ruby, ... folks are also receptive to the
    idea (I've talked with them).  For pointers to
    some of what's happening in this area, see
    <URL:http://starbase.neosoft.com/~claird/comp.lang.misc/core_enhancement.html>

    Also, you should know that my favorite enhancement
    to Tk is a remodularization called TkGS.  This
    should improve performance under Win*, make it
    more portable to BeOS, improve access by Python,
    and so on.
4.  Greg's right that some publishers are dumping Tcl.
    Not all, though.  If it matters, we can go into
    details.
5.  Pango is indeed cool, but it's different from
    [text].  The world is probably moving to Pango and
    similar implementations.  The world will be missing
    much of what [text] offers.
6.  ANYONE with an urge to get out a Python-related
    idea should pursue it.  *DDJ*'s a great outlet.
    It's far from the only one.  If people have ideas
    about articles, but are held back by lack of time/
    fluency/contacts/..., *please* get in touch with
    me.  I'll find a way at least to give articles a
    fair chance at being published.

Cameron Laird       <claird at NeoSoft.com>       +1 281 996 8546 FAX
http://starbase.neosoft.com/~claird/misc.writing/publications.html



From cgw at fnal.gov  Wed Oct 25 17:31:38 2000
From: cgw at fnal.gov (Charles G Waldman)
Date: Wed, 25 Oct 2000 10:31:38 -0500 (CDT)
Subject: [Python-Dev] Miscellaneous comments on Tkinter and related matters
In-Reply-To: <200010251458.JAA77237@starbase.neosoft.com>
References: <200010251458.JAA77237@starbase.neosoft.com>
Message-ID: <14838.64730.225260.148853@buffalo.fnal.gov>

Cameron Laird writes:
 > I can rarely afford to dip into Python-Dev.  My head is exploding
 > too much of the time as it is.
 > 
 > Maybe I can help with the recent Tkinter discussions, though.

 > 2.  I agree that MacOS is the thorny problem for
 >     the standard Pysolution. 

What is the impact of the fact that MacOS X will run X?  Doesn't this
open the door to a lot of new possibilities, at least if we don't need
to support Mac OS[6-9].  Or is the installed base of MacOS[6-9] just
way too big to even think about dropping (or deprecating) support for
it?



From tim_one at email.msn.com  Wed Oct 25 18:23:30 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Wed, 25 Oct 2000 12:23:30 -0400
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: <200010251225.HAA22242@cj20424-a.reston1.va.home.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCIEMOHMAA.tim_one@email.msn.com>

[Guido, on finding Tcl/Tk under Windows]
> To me this all sounds like FUD.  Since Python 1.6 and 2.0, you don't
> have to install Tcl/Tk or its libraries -- it is installed
> *transparently* by the Python Windows installer.  That's different --
> and better -- than what happened in 1.5.2, where a separate Tcl/Tk
> installer was optionally run.  The version issues are also resolved
> this way: you are guaranteed to get exactly the Tcl/Tk version that
> was tested by the developers.

Unless you're Fredrik, alas <wink>.  Apparently Tcl still honors library
envars first if they exist, and if some other installation or use of Tcl/Tk
set those, you can still end up w/ a mix. *Much* better than before, though,
and I don't recall ay instance of this happening in real life so far apart
from /F (who had no problem figuring it out, of course).

>> What if a user calls with a problem?  Why should I
>> have to debug their Tcl library path problems?  No
>> thanks.

> The Tcl library paths are all taken care of by the new installer
> strategy.
>
> Really, give it a try.  It Just Works! (SM)

I'll second that!  "Mystery startup errors" from the Python+Tcl+Tk+Windows
combo were at least weekly questions on c.l.py for 1.5.2, often daily.  I've
seen none for 1.6 or 2.0.

and-all-it-took-was-avoiding-ms's-recommended-practices<wink>-ly y'rs  - tim





From guido at python.org  Wed Oct 25 19:46:55 2000
From: guido at python.org (Guido van Rossum)
Date: Wed, 25 Oct 2000 12:46:55 -0500
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: Your message of "Wed, 25 Oct 2000 12:23:30 -0400."
             <LNBBLJKPBEHFEDALKOLCIEMOHMAA.tim_one@email.msn.com> 
References: <LNBBLJKPBEHFEDALKOLCIEMOHMAA.tim_one@email.msn.com> 
Message-ID: <200010251746.MAA30108@cj20424-a.reston1.va.home.com>

> [Guido, on finding Tcl/Tk under Windows]
> > To me this all sounds like FUD.  Since Python 1.6 and 2.0, you don't
> > have to install Tcl/Tk or its libraries -- it is installed
> > *transparently* by the Python Windows installer.  That's different --
> > and better -- than what happened in 1.5.2, where a separate Tcl/Tk
> > installer was optionally run.  The version issues are also resolved
> > this way: you are guaranteed to get exactly the Tcl/Tk version that
> > was tested by the developers.

[Tim]
> Unless you're Fredrik, alas <wink>.  Apparently Tcl still honors library
> envars first if they exist, and if some other installation or use of Tcl/Tk
> set those, you can still end up w/ a mix. *Much* better than before, though,
> and I don't recall ay instance of this happening in real life so far apart
> from /F (who had no problem figuring it out, of course).

Hm...  In FixTk, TCL_LIBRARY is set explicitly.  Perhaps it should set
TK_LIBRARY explicitly too?

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



From trentm at ActiveState.com  Wed Oct 25 19:11:42 2000
From: trentm at ActiveState.com (Trent Mick)
Date: Wed, 25 Oct 2000 10:11:42 -0700
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: <LNBBLJKPBEHFEDALKOLCIEMOHMAA.tim_one@email.msn.com>; from tim_one@email.msn.com on Wed, Oct 25, 2000 at 12:23:30PM -0400
References: <200010251225.HAA22242@cj20424-a.reston1.va.home.com> <LNBBLJKPBEHFEDALKOLCIEMOHMAA.tim_one@email.msn.com>
Message-ID: <20001025101142.B8625@ActiveState.com>

On Wed, Oct 25, 2000 at 12:23:30PM -0400, Tim Peters wrote:
> [Guido, on finding Tcl/Tk under Windows]
> > To me this all sounds like FUD.  Since Python 1.6 and 2.0, you don't
> > have to install Tcl/Tk or its libraries -- it is installed
> > *transparently* by the Python Windows installer.  That's different --
> > and better -- than what happened in 1.5.2, where a separate Tcl/Tk
> > installer was optionally run.  The version issues are also resolved
> > this way: you are guaranteed to get exactly the Tcl/Tk version that
> > was tested by the developers.
> 
> Unless you're Fredrik, alas <wink>.

...Or anybody installing ActivePython for that matter. We give instructions
that the latest version of Tcl/Tk has to be installed separately, but Tk is
*not* bundled with it.


Trent

-- 
Trent Mick
TrentM at ActiveState.com



From pf at artcom-gmbh.de  Wed Oct 25 19:02:45 2000
From: pf at artcom-gmbh.de (Peter Funk)
Date: Wed, 25 Oct 2000 19:02:45 +0200 (MEST)
Subject: GUI-Discussion; MacOS vs. MacOS X (was Re: [Python-Dev] Miscellaneous comments on Tkinter and related...)
In-Reply-To: <14838.64730.225260.148853@buffalo.fnal.gov> from Charles G Waldman at "Oct 25, 2000 10:31:38 am"
Message-ID: <m13oTwr-000Dm8C@artcom0.artcom-gmbh.de>

Hi,

Charles G Waldman:
>  > 2.  I agree that MacOS is the thorny problem for
>  >     the standard Pysolution. 
> 
> What is the impact of the fact that MacOS X will run X?  Doesn't this
> open the door to a lot of new possibilities, at least if we don't need
> to support Mac OS[6-9].  Or is the installed base of MacOS[6-9] just
> way too big to even think about dropping (or deprecating) support for
> it?

It will take years, before MacOS X will find its way onto the desk
of the average Apple Mac user.  The Mac s mostly used in the graphics 
and printing industry (our cutsomers) where people normally don't 
even think about a OS upgrade, if they don't have to.  They usually
run a mix of Photoshop, Quark XPRess, Artwork, illustrator or other 
so called creative software on the version of the OS they had on 
the machine when they bought it.  THese machines are usually used
through a period of at least four years.

So MacOS X might simplify things for software vendors from 2004 on 
and later.

Regards, Peter



From guido at python.org  Wed Oct 25 20:21:58 2000
From: guido at python.org (Guido van Rossum)
Date: Wed, 25 Oct 2000 13:21:58 -0500
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: Your message of "Wed, 25 Oct 2000 10:11:42 MST."
             <20001025101142.B8625@ActiveState.com> 
References: <200010251225.HAA22242@cj20424-a.reston1.va.home.com> <LNBBLJKPBEHFEDALKOLCIEMOHMAA.tim_one@email.msn.com>  
            <20001025101142.B8625@ActiveState.com> 
Message-ID: <200010251821.NAA30247@cj20424-a.reston1.va.home.com>

> ...Or anybody installing ActivePython for that matter. We give instructions
> that the latest version of Tcl/Tk has to be installed separately, but Tk is
> *not* bundled with it.

And that's a shame.  Any chance that will be fixed any time soon?

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



From jeremy at alum.mit.edu  Wed Oct 25 15:36:46 2000
From: jeremy at alum.mit.edu (Jeremy Hylton)
Date: Wed, 25 Oct 2000 09:36:46 -0400 (EDT)
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: <200010251821.NAA30247@cj20424-a.reston1.va.home.com>
References: <200010251225.HAA22242@cj20424-a.reston1.va.home.com>
	<LNBBLJKPBEHFEDALKOLCIEMOHMAA.tim_one@email.msn.com>
	<20001025101142.B8625@ActiveState.com>
	<200010251821.NAA30247@cj20424-a.reston1.va.home.com>
Message-ID: <14838.57838.841831.632628@bitdiddle.concentric.net>

>>>>> "GvR" == Guido van Rossum <guido at python.org> writes:

  >> ...Or anybody installing ActivePython for that matter. We give
  >> instructions that the latest version of Tcl/Tk has to be
  >> installed separately, but Tk is *not* bundled with it.

  GvR> And that's a shame.  Any chance that will be fixed any time
  GvR> soon?

I think a version of Tkinter packaged with a distutils setup script is
the best answer for Unix platforms.  As a Linux user, I do *not* want
to install a second copy of Tcl/Tk.

If we have a distutil-Tkinter, e.g. 
    ftp://ftp.python.org/pub/python/2.0/Tkinter-2.0-8.0.tar.gz
then a user can download it and run "python setup.py install" to build
a Tkinter against their installed version of Tk.  This will be
straightforward on many Linux systems, because they ship with Tk
installed.

Jeremy



From jeremy at alum.mit.edu  Wed Oct 25 15:41:30 2000
From: jeremy at alum.mit.edu (Jeremy Hylton)
Date: Wed, 25 Oct 2000 09:41:30 -0400 (EDT)
Subject: [Python-Dev] build problems under Solaris
Message-ID: <14838.58122.920099.787981@bitdiddle.concentric.net>

There are two bug reports about build problems under Solaris (117508
and 117606).  I don't have access to a Solaris machine, so I can't do
anything to help these users.  Since ActivePython is shipped for
Solaris, I assume that you (or someone else at AS) does have access to
a Solaris machine.  Can you take a look at these problems?  Or assign
them to someone else who can?

Jeremy




From guido at python.org  Wed Oct 25 20:50:07 2000
From: guido at python.org (Guido van Rossum)
Date: Wed, 25 Oct 2000 13:50:07 -0500
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: Your message of "Wed, 25 Oct 2000 09:36:46 -0400."
             <14838.57838.841831.632628@bitdiddle.concentric.net> 
References: <200010251225.HAA22242@cj20424-a.reston1.va.home.com> <LNBBLJKPBEHFEDALKOLCIEMOHMAA.tim_one@email.msn.com> <20001025101142.B8625@ActiveState.com> <200010251821.NAA30247@cj20424-a.reston1.va.home.com>  
            <14838.57838.841831.632628@bitdiddle.concentric.net> 
Message-ID: <200010251850.NAA30475@cj20424-a.reston1.va.home.com>

> I think a version of Tkinter packaged with a distutils setup script is
> the best answer for Unix platforms.  As a Linux user, I do *not* want
> to install a second copy of Tcl/Tk.

Why not?  Because if every app using Tcl/Tk did that there would be
hundreds of copies of Tcl/Tk on your disk?  I don't think that
argument flies; only a few other major languages use Tcl/Tk this was,
so maybe you'd end up with 4 copies of Tcl/Tk: one for Tcl/Tk itself,
one for Python+Tkinter, one for Perl/Tk (that's a separate code base
anyway so you already have this today -- if you install Perl/Tk, that
is), and one for Ruby.  Given modern disk sizes I don't think it's a
problem.  We do the same for Windows, for good reasons: so we can be
independent of whatever Tcl/Tk version is already installed.

> If we have a distutil-Tkinter, e.g. 
>     ftp://ftp.python.org/pub/python/2.0/Tkinter-2.0-8.0.tar.gz
> then a user can download it and run "python setup.py install" to build
> a Tkinter against their installed version of Tk.  This will be
> straightforward on many Linux systems, because they ship with Tk
> installed.

Of course that's easier.  But less robust.  (And why is there an "8.0"
in the filename if it works with other Tcl/Tk versions???)

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



From paul at prescod.net  Wed Oct 25 20:11:34 2000
From: paul at prescod.net (Paul Prescod)
Date: Wed, 25 Oct 2000 11:11:34 -0700
Subject: [Python-Dev] Gradual migration
References: <39F52EF1.A201C6D9@prescod.net> <39F54C0F.25798309@lemburg.com> <39F5B4DC.C226D8F6@prescod.net> <39F5E4FA.9FD6D35@lemburg.com>
Message-ID: <39F72256.C7F93BFB@prescod.net>

"M.-A. Lemburg" wrote:
> 
> ...
>
> >  * implementation language and Python inheritance semantics are almost
> > completely distinct. After all, we have Python implementations in a
> > variety of languages with minor incompatibilities. Python could have a
> > proper type/class merging even if it were written in assembly language.
> > So let's leave implementation language aside.
> 
> Hey, think of it as opportunity: we can reuse much of C++'s
> optimizations and the integration of Python and C++ applications
> will get *much* easier.

We could make integrating C++ and Python easier through CXX or Py_Cpp.
Perhaps we should ship one of those with Python 2.1. Anyhow, integrating
C++ and Python is not really so hard, in my experience.
 
> A rewrite shouldn't scare anyone away -- much of the existing
> code can be reused since only the Python C APIs of the various
> types will have to be rewritten, not the logic behind the types.

I wasn't really addressing the issue of backwards compatibility of
extensions -- I was talking about Python programs. Nevertheless, I can't
resist:

Porting your app to the Python APIs is often the majority of the work in
a particular extension. A lot of Python extensions consist only of API
glue!
 
> Besides, Py3K will be a project which runs in parallel to the
> 2.x development (at least that's what I've read on some BeOpen
> webpage), so there's really not much to worry about wrt to
> breakage, etc. People will be able to test-drive Py3K while
> using the 2.x series.

I don't see how that helps. If you can't write programs that work both
on the old interpreter and the new one then you need to have a "switch
over" day. The whole point of my doctrine is that Python 3K should run
all code that the version of Python immediately before it did. The most
it can do in terms of breakage is to warn about error messages. In that
case it doesn't matter much whether Python 3K is available at the same
time as 2.X or emerges from Guido's head fully formed.

> >  * there is a hell of a lot we can do to make the type/class split less
> > visible without a major rewrite. For instance, lists could have a
> > __getitem__ method so that they "act like" instances. Instances could
> > return their methods in a dir() so that they "act like" built-in
> > objects. So there is no reason to wait for a complete rewrite to start
> > on this path.
> 
> Right. I didn't want to say that things cannot be done prior
> to the rewrite, only that a rewrite will give us much more
> options that we currently have.

Okay, so do you agree with the rule expressed here:

http://www.python.org/pipermail/python-dev/2000-October/016785.html

> > I don't know what you mean by a "low-level strategy" for classes. It's
> > not like we can somehow use C++ vtables without giving up Python's
> > dynamicity. Python's class handling is about as low-level as it can get
> > in my humble opinion.
> 
> With "low-level" I meant trying to build Python classes and
> instances on top of a very thin layer on top of C++ classes,
> e.g. all slots could be implemented using true C++ methods with
> additional logic to override them using dynamically bound
> Python method objects.

I don't think that there is really interesting magic in a C++ compiler.
A vtable is an array of pointers to functions. We've already implemented
the equivalent in ANSI C. C++ exceptions, constructors, destriuctors and
smart pointers are a little more interesting from a code maintenance and
simplicity point of view. But even then I think that we could get to a
C++ implementation through incremental rewrites.

> > > Differences like the
> > > ones between Unicode and 8-bit strings would then flesh
> > > out as two different subclasses of a generic string type which
> > > again is based on a generic sequence type.
> >
> > Of course that's where we want to go but it doesn't avoid the backwards
> > compatibility problems.
> 
> Huh ? I was talking about clear design... not ways to avoid
> b/w compatibility. 

But the whole point of my original article was backwards
compatibility!!! I didn't address an implementation strategy for Py3K at
all.

> Merging Unicode and strings will hurt one
> way or another. This is simply a consequence of using strings
> as binary containers where Unicode is meant for text only use.

The question I wanted to address is how we can *minimize the pain*. 

> ...
> > C++ does not help. Inheritance does not help. Pluggable compilers do not
> > help. We *will* break code. We just need to decide whether to do it in a
> > thoughtful way that gives people a chance to migrate or put off
> > decisions until the last possible moment and then spring it on them with
> > no between-version upgrade path.
> 
> Just tell Python to use the correct class for what the
> code was written for (and this could be done by plugging in
> a 2.0 compiler). The instances of those classes would still work
> together with other semantics by virtue of exposing the same
> interface, yet the internals would work differently, e.g.
> a module using case insensitive lookup would be compiled using
> case insensitive dictionaries as namespaces.

A mode switch solutiion is fraught with dangers. First there is the
issue of the correct default for the mode switch. 

http://www.python.org/pipermail/python-dev/2000-April/010029.html

Second, there are dangers cutting and pasting between modules.

Anyhow, even if we allow a mode switch we need to be able to help people
to upgrade their modules in a reasonable time. That's what the message I
cited advocates.

>...
> Why spoil all the fun when we haven't even started thinking
> about all the possibilities we could use to make Py3k a
> success ?

Asking for a map of where we are going and how we will get here is
"spoiling all of the fun?" I'm not sure what you are reacting to -- I
didn't advise one implementation strategy or another -- I just said that
we should employ a strategy that minimizes sudden and surprising code
breakage.

-- 
 Paul Prescod - Not encumbered by corporate consensus
Simplicity does not precede complexity, but follows it. 
	- http://www.cs.yale.edu/homes/perlis-alan/quotes.html



From fdrake at acm.org  Wed Oct 25 20:06:50 2000
From: fdrake at acm.org (Fred L. Drake, Jr.)
Date: Wed, 25 Oct 2000 14:06:50 -0400 (EDT)
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: <200010251850.NAA30475@cj20424-a.reston1.va.home.com>
References: <200010251225.HAA22242@cj20424-a.reston1.va.home.com>
	<LNBBLJKPBEHFEDALKOLCIEMOHMAA.tim_one@email.msn.com>
	<20001025101142.B8625@ActiveState.com>
	<200010251821.NAA30247@cj20424-a.reston1.va.home.com>
	<14838.57838.841831.632628@bitdiddle.concentric.net>
	<200010251850.NAA30475@cj20424-a.reston1.va.home.com>
Message-ID: <14839.8506.304295.908264@cj42289-a.reston1.va.home.com>

Guido van Rossum writes:
 > Why not?  Because if every app using Tcl/Tk did that there would be
 > hundreds of copies of Tcl/Tk on your disk?  I don't think that
 > argument flies; only a few other major languages use Tcl/Tk this was,

  So should every application written in Python install it's own copy
of Python, since there may be unexpected incompatibilities between
versions?


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at acm.org>
PythonLabs Team Member




From paul at prescod.net  Wed Oct 25 20:18:16 2000
From: paul at prescod.net (Paul Prescod)
Date: Wed, 25 Oct 2000 11:18:16 -0700
Subject: [Python-Dev] Miscellaneous comments on Tkinter and related matters
References: <200010251458.JAA77237@starbase.neosoft.com> <14838.64730.225260.148853@buffalo.fnal.gov>
Message-ID: <39F723E8.2AC6787@prescod.net>

Charles G Waldman wrote:
> 
> ...
> What is the impact of the fact that MacOS X will run X?  Doesn't this
> open the door to a lot of new possibilities, at least if we don't need
> to support Mac OS[6-9].  Or is the installed base of MacOS[6-9] just
> way too big to even think about dropping (or deprecating) support for
> it?

Would Mac users go for: "first install X. Then you can run Python."

-- 
 Paul Prescod - Not encumbered by corporate consensus
Simplicity does not precede complexity, but follows it. 
	- http://www.cs.yale.edu/homes/perlis-alan/quotes.html



From guido at python.org  Wed Oct 25 21:14:57 2000
From: guido at python.org (Guido van Rossum)
Date: Wed, 25 Oct 2000 14:14:57 -0500
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: Your message of "Wed, 25 Oct 2000 14:06:50 -0400."
             <14839.8506.304295.908264@cj42289-a.reston1.va.home.com> 
References: <200010251225.HAA22242@cj20424-a.reston1.va.home.com> <LNBBLJKPBEHFEDALKOLCIEMOHMAA.tim_one@email.msn.com> <20001025101142.B8625@ActiveState.com> <200010251821.NAA30247@cj20424-a.reston1.va.home.com> <14838.57838.841831.632628@bitdiddle.concentric.net> <200010251850.NAA30475@cj20424-a.reston1.va.home.com>  
            <14839.8506.304295.908264@cj42289-a.reston1.va.home.com> 
Message-ID: <200010251914.OAA30720@cj20424-a.reston1.va.home.com>

>  > Why not?  Because if every app using Tcl/Tk did that there would be
>  > hundreds of copies of Tcl/Tk on your disk?  I don't think that
>  > argument flies; only a few other major languages use Tcl/Tk this was,
> 
> So should every application written in Python install it's own copy
> of Python, since there may be unexpected incompatibilities between
> versions?

Of course not, but large and important ones may.  Some already do,
e.g. Alice, Zope, Ultraseek.  I have no problem with this.  (The
saving grace is that none of these needs to recursively include
Tcl. :-)

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



From gvwilson at nevex.com  Wed Oct 25 20:17:24 2000
From: gvwilson at nevex.com (Greg Wilson)
Date: Wed, 25 Oct 2000 14:17:24 -0400 (EDT)
Subject: [Python-Dev] Gradual migration
In-Reply-To: <39F72256.C7F93BFB@prescod.net>
Message-ID: <Pine.LNX.4.10.10010251415580.10577-100000@akbar.nevex.com>

> Paul Prescod:
> Anyhow, integrating C++ and Python is not really so hard, in my experience.

...unless you are using heavily-templated code, e.g. every damn class you've
been asked to wrap up seems to be derived from something in the STL...

Greg




From cgw at fnal.gov  Wed Oct 25 20:18:56 2000
From: cgw at fnal.gov (Charles G Waldman)
Date: Wed, 25 Oct 2000 13:18:56 -0500 (CDT)
Subject: [Python-Dev] Miscellaneous comments on Tkinter and related matters
In-Reply-To: <39F723E8.2AC6787@prescod.net>
References: <200010251458.JAA77237@starbase.neosoft.com>
	<14838.64730.225260.148853@buffalo.fnal.gov>
	<39F723E8.2AC6787@prescod.net>
Message-ID: <14839.9232.950919.629446@buffalo.fnal.gov>

Paul Prescod writes:
 > 
 > Would Mac users go for: "first install X. Then you can run Python."
 > 

I should probably just shut up, because I really don't know enough
about Mac OS X, but what I was wondering is whether OS X will actually
*use* the X Window System.  Of course we don't want to tell users that
they have to go install X on their own.




From tim_one at email.msn.com  Wed Oct 25 20:18:55 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Wed, 25 Oct 2000 14:18:55 -0400
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: <14839.8506.304295.908264@cj42289-a.reston1.va.home.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCGENHHMAA.tim_one@email.msn.com>

[Guido]
> Why not?  Because if every app using Tcl/Tk did that there would be
> hundreds of copies of Tcl/Tk on your disk?  I don't think that
> argument flies; only a few other major languages use Tcl/Tk this was,

[Fred Drake]
>   So should every application written in Python install it's own copy
> of Python, since there may be unexpected incompatibilities between
> versions?

So long as Python doesn't guarantee binary compatibility across releases,
that's the only thing that works.  Play PySol lately <wink>?





From paul at prescod.net  Wed Oct 25 20:27:33 2000
From: paul at prescod.net (Paul Prescod)
Date: Wed, 25 Oct 2000 11:27:33 -0700
Subject: [Python-Dev] Miscellaneous comments on Tkinter and related matters
References: <200010251458.JAA77237@starbase.neosoft.com>
		<14838.64730.225260.148853@buffalo.fnal.gov>
		<39F723E8.2AC6787@prescod.net> <14839.9232.950919.629446@buffalo.fnal.gov>
Message-ID: <39F72615.40B38862@prescod.net>

Charles G Waldman wrote:
> 
>...
> 
> I should probably just shut up, because I really don't know enough
> about Mac OS X, but what I was wondering is whether OS X will actually
> *use* the X Window System.  Of course we don't want to tell users that
> they have to go install X on their own.

And become just another Unix? Then how would they get people to pay the
Macintosh usability premium?

Seriously, maybe someday as a "Linux compatibility mode" but I don't
think it is officially proposed.

-- 
 Paul Prescod - Not encumbered by corporate consensus
Simplicity does not precede complexity, but follows it. 
	- http://www.cs.yale.edu/homes/perlis-alan/quotes.html



From paul at prescod.net  Wed Oct 25 20:30:34 2000
From: paul at prescod.net (Paul Prescod)
Date: Wed, 25 Oct 2000 11:30:34 -0700
Subject: Integer division revisited (was Re: [Python-Dev] Gradual migration)
References: <m13nynX-000Dm8C@artcom0.artcom-gmbh.de>
Message-ID: <39F726CA.9D472E50@prescod.net>

Peter Funk wrote:
> 
> ..
> 
> Bruce Sherwood and David Scherer suggested a IMHO very clever solution to
> this particular problem in March/April this year.  This thread was first
> posted to idle-dev and afterwards X-posted to python-dev:
> 
> http://www.python.org/pipermail/idle-dev/2000-April/000138.html
> http://www.python.org/pipermail/idle-dev/2000-April/000140.html
> http://www.python.org/pipermail/python-dev/2000-April/010029.html
 
Tim's last message on it doesn't sound overwhelmingly positiive to me!
Also, don't forget that Python is also a command line so "version
pragmas" cause additional complexity there.

-- 
 Paul Prescod
Simplicity does not precede complexity, but follows it. 
	- http://www.cs.yale.edu/homes/perlis-alan/quotes.html



From DavidA at ActiveState.com  Wed Oct 25 20:59:35 2000
From: DavidA at ActiveState.com (David Ascher)
Date: Wed, 25 Oct 2000 11:59:35 -0700 (Pacific Daylight Time)
Subject: [Python-Dev] build problems under Solaris
In-Reply-To: <14838.58122.920099.787981@bitdiddle.concentric.net>
Message-ID: <Pine.WNT.4.21.0010251159020.1360-100000@loom>

On Wed, 25 Oct 2000, Jeremy Hylton wrote:

> There are two bug reports about build problems under Solaris (117508
> and 117606).  I don't have access to a Solaris machine, so I can't do
> anything to help these users.  Since ActivePython is shipped for
> Solaris, I assume that you (or someone else at AS) does have access to
> a Solaris machine.  Can you take a look at these problems?  Or assign
> them to someone else who can?

Sure, we'll take a look.  

--david




From akuchlin at mems-exchange.org  Wed Oct 25 23:51:40 2000
From: akuchlin at mems-exchange.org (Andrew Kuchling)
Date: Wed, 25 Oct 2000 17:51:40 -0400
Subject: [Python-Dev] 2.0 articles
Message-ID: <E13oYSS-00071f-00@kronos.cnri.reston.va.us>

I'd like to begin writing an article about 2.0's Unicode support.
Before beginning, has anyone else already begun this task?  If yes,
please let me know...

(Incidentally, did a 2.0 press release ever go out?  Is someone going
to write one?)

--amk



From MarkH at ActiveState.com  Thu Oct 26 00:18:27 2000
From: MarkH at ActiveState.com (Mark Hammond)
Date: Thu, 26 Oct 2000 09:18:27 +1100
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: <200010251821.NAA30247@cj20424-a.reston1.va.home.com>
Message-ID: <ECEPKNMJLHAPFFJHDOJBCEOADOAA.MarkH@ActiveState.com>

[Trent]
> > ...Or anybody installing ActivePython for that matter. We
> > give instructions that the latest version of Tcl/Tk has to
> > be installed separately, but Tk is *not* bundled with it.

[Guido]
> And that's a shame.  Any chance that will be fixed any time soon?

Not presuming to speak for anyone, least of all the ActivePython product
manager :-)

I don't think it will be "fixed", as it is not considered "broken".  It was
an explicit choice to leave out Tcl/Tk.  And my recollection is that the
"feedback" address sees more requests for wxPython than Tcl/Tk.

We make it pretty clear Tcl/Tk is not included - I assume that everyone who
cares about that simply uses BeOpen releases or source tarballs.

[When I say "wont be fixed", I mean it is unlikely to appear in the core
ActivePython release.  It almost certainly will be supported as an add-on,
whatever that turns out to mean exactly ;-]

Mark.




From guido at python.org  Thu Oct 26 02:15:31 2000
From: guido at python.org (Guido van Rossum)
Date: Wed, 25 Oct 2000 19:15:31 -0500
Subject: [Python-Dev] 2.0 articles
In-Reply-To: Your message of "Wed, 25 Oct 2000 17:51:40 -0400."
             <E13oYSS-00071f-00@kronos.cnri.reston.va.us> 
References: <E13oYSS-00071f-00@kronos.cnri.reston.va.us> 
Message-ID: <200010260015.TAA02798@cj20424-a.reston1.va.home.com>

> (Incidentally, did a 2.0 press release ever go out?  Is someone going
> to write one?)

No; and not me...

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



From MarkH at ActiveState.com  Thu Oct 26 01:29:52 2000
From: MarkH at ActiveState.com (Mark Hammond)
Date: Thu, 26 Oct 2000 10:29:52 +1100
Subject: [Python-Dev] sys.__stdout__ - was RE: [Idle-dev] Doc Commentary
In-Reply-To: <200010251513.KAA28803@cj20424-a.reston1.va.home.com>
Message-ID: <ECEPKNMJLHAPFFJHDOJBOEOFDOAA.MarkH@ActiveState.com>

[From a mail in idle-dev - dropped idle-dev and all CCs]

[idle-dev poster]
> > >>> import sys
> > >>> f = open('some-output-file', 'w')
> > >>> sys.stdout = f
> > >>> # do some stuff
> > >>> sys.stdout = sys.__stdout__
> >
> > Because on entry, sys.stdout is already redirected
> > (not reflected in sys.__stdout__)

[Guido]

> Where did you get this idiom?  You should never use sys.__stdout__
> this way!  The proper idiom is
>
>   save_stdout = sys.stdout
>   try:
>       sys.stdout = f
>       # do some stuff
>   finally:
>       sys.stdout = save_stdout
>
> If you know of any places that are promoting direct use of __stdout__,
> please let them know this is wrong.  If you are contemplating to use
> this in code examples you intend to distribute, please don't!

I admit that I first became aware of sys.__stdout__ after seeing this exact
same idiom in other peoples code.  I always assumed that this is _exactly_
what sys.__stdout__ was to be used for!

The following examples exist:

* Tools/unicode/makeunicodedata.py - exactly the idiom you despise.
* Tools/il8n/pygettext.py - ditto
* Tools/idle/PyParse.py - disabled, debugging output function - presumably
to get around sys.stdout redirection - but this sounds suspect as an idiom
to me too!

So what _is_ it intended for?

Mark.




From greg at cosc.canterbury.ac.nz  Thu Oct 26 02:16:02 2000
From: greg at cosc.canterbury.ac.nz (Greg Ewing)
Date: Thu, 26 Oct 2000 13:16:02 +1300 (NZDT)
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: <200010251353.IAA28190@cj20424-a.reston1.va.home.com>
Message-ID: <200010260016.NAA28387@s454.cosc.canterbury.ac.nz>

> If you started with basic Tkinter widgets, sure, it looks different
> than anything else.  But that depends on the widget layout in the
> program, not on the widget library used!

This is one of my main gripes about the Tk API.  The default
behaviours of all its layout managers suck. In order to get a layout
that looks pleasant and/or conforms to some style guide, you have to
set a whole slew of options every time you place a widget.

Greg Ewing, Computer Science Dept, +--------------------------------------+
University of Canterbury,	   | A citizen of NewZealandCorp, a	  |
Christchurch, New Zealand	   | wholly-owned subsidiary of USA Inc.  |
greg at cosc.canterbury.ac.nz	   +--------------------------------------+



From barry at wooz.org  Thu Oct 26 02:17:38 2000
From: barry at wooz.org (Barry A. Warsaw)
Date: Wed, 25 Oct 2000 20:17:38 -0400 (EDT)
Subject: [Python-Dev] sys.__stdout__ - was RE: [Idle-dev] Doc Commentary
References: <200010251513.KAA28803@cj20424-a.reston1.va.home.com>
	<ECEPKNMJLHAPFFJHDOJBOEOFDOAA.MarkH@ActiveState.com>
Message-ID: <14839.30754.217582.20441@anthem.concentric.net>

>>>>> "MH" == Mark Hammond <MarkH at ActiveState.com> writes:

    MH> * Tools/il8n/pygettext.py

That's embarassing. ;)

Here's a patch, but I'm not going to check it in because I think a
/much/ better idiom to adopt is to use extended print instead.  I need
to make some updates to pygettext.py soon, so I'll probably just
2.0-ify it at the same time.

-Barry

-------------------- snip snip --------------------
Index: pygettext.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Tools/i18n/pygettext.py,v
retrieving revision 1.9
diff -u -r1.9 pygettext.py
--- pygettext.py	2000/05/02 19:28:30	1.9
+++ pygettext.py	2000/10/26 00:16:22
@@ -283,6 +283,7 @@
         options = self.__options
         timestamp = time.ctime(time.time())
         # common header
+        stdout = sys.stdout
         try:
             sys.stdout = fp
             # The time stamp in the header doesn't have the same format
@@ -314,7 +315,7 @@
                 print 'msgid', normalize(k)
                 print 'msgstr ""\n'
         finally:
-            sys.stdout = sys.__stdout__
+            sys.stdout = stdout
 
 
 def main():



From gmcm at hypernet.com  Thu Oct 26 02:39:14 2000
From: gmcm at hypernet.com (Gordon McMillan)
Date: Wed, 25 Oct 2000 20:39:14 -0400
Subject: [Python-Dev] sys.__stdout__ - was RE: [Idle-dev] Doc Commentary
In-Reply-To: <ECEPKNMJLHAPFFJHDOJBOEOFDOAA.MarkH@ActiveState.com>
References: <200010251513.KAA28803@cj20424-a.reston1.va.home.com>
Message-ID: <39F744F2.17759.4FC8E6D4@localhost>

> [Guido]
> 
> > Where did you get this idiom?  You should never use sys.__stdout__
> > this way!  The proper idiom is
> >
> >   save_stdout = sys.stdout
> >   try:
> >       sys.stdout = f
> >       # do some stuff
> >   finally:
> >       sys.stdout = save_stdout
[Mark]
> So what _is_ it intended for?

A fail-safe. The recommended idiom might also be called 
"plays well with others"; a barbarian notion that fortunately has 
not infected most import hacks or program exits...

works-for-me-so-buzz-off-ly y'rs

- Gordon



From akuchlin at mems-exchange.org  Thu Oct 26 04:40:03 2000
From: akuchlin at mems-exchange.org (Andrew Kuchling)
Date: Wed, 25 Oct 2000 22:40:03 -0400
Subject: [Python-Dev] 2.0 press release
In-Reply-To: <200010260015.TAA02798@cj20424-a.reston1.va.home.com>; from guido@python.org on Wed, Oct 25, 2000 at 07:15:31PM -0500
References: <E13oYSS-00071f-00@kronos.cnri.reston.va.us> <200010260015.TAA02798@cj20424-a.reston1.va.home.com>
Message-ID: <20001025224003.A27300@kronos.cnri.reston.va.us>

On Wed, Oct 25, 2000 at 07:15:31PM -0500, Guido van Rossum wrote:
>> (Incidentally, did a 2.0 press release ever go out?  Is someone going
>> to write one?)
>No; and not me...

Little-known fact: Guido actually does nothing but sit in his pyjamas
(with feet!)  all day, drinking cocoa, eating Hostess Twinkies and
watching Tiny Toons, while his long-suffering co-workers implement and
debug the fantastically complex algorithms that go into Python.

Here's some rough text: Can someone with a clue about writing a good
press release give this a look?

--amk


Reston, VA, Oct 25 2000: The Python development team today announced
the release of version 2.0 of the Python programming language.
Version 2.0 adds a number of significant new features:

	* Unicode support, in the form of a new Unicode data type,
	library additions for conversion to/from various encodings,
	and support for displaying Unicode strings in Tk widgets.

	* New language features: garbage collection of cycles, list
	comprehensions, augmented assignment, string methods.

	* Distutils, a new system for making Python modules and
	extensions easily available to a wider audience with very
	little overhead for build/release/install mechanics.

	* Improved XML support, including support for the Simple API
	for XML (SAX2), a miniature Document Object Model (DOM), and
	the Expat parser.

	* Many library improvements, including HTTP/1.1 support, an
	enhanced curses module, the ability to read and write
	ZIP-format files, support for the Windows registry, and many
	more minor improvements.

	* Ports to new platforms: 64-bit Windows on the Itanium
	processor, Windows CE, and Darwin/MacOS X.
	
Python is an interpreted, object-oriented, high-level programming
language.  Its high-level built in data structures, combined with
dynamic typing and dynamic binding, make it very attractive for rapid
application development, as well as for use as a scripting or glue
language to connect existing components together.  Python's simple,
easy to learn syntax emphasizes readability and therefore reduces the
cost of program maintenance, and it supports modules and packages,
encouraging program modularity and code reuse.  

Many extension modules for Python have been written to interface 
with other libraries and applications.  Some of the available modules
include:

	* Support for many relational databases (Oracle, Sybase, MySQL)
	* GUI toolkits (Tk, Windows MFC, wxWindows, KDE, GNOME)
	* Internet protocols (LDAP, WebDAV, XML-RPC, SOAP)
	* Mathematics (Numeric Python)

Python is used for many different purposes, particularly
cross-platform rapid development, Web development, and scripting of
scientific applications.  Some of the applications using Python
include:

	* Zope, the leading Open Source web application server
	* The Mailman mailing list manager
	* The Reportlab PDF document generation toolset
	* XXX suggestions?

XXX too darn many lists here?

<Insert 4 or 5 quotations from various people here.  
 Possible people: someone from Digital Creations, PythonWare,
	          Reportlabs, ActiveState/O'Reilly, TheKompany,
	          Infoseek, Red Hat, a developer from some well-known
	          free software project that uses Python>

The Python interpreter and the extensive standard library are
available free of charge and are distributed under an open-source
license.  Ports have been made to all major platforms, such as
Windows, MacOS, and many Unix variants (Linux, Solaris, FreeBSD, etc.)
New versions are developed collaboratively by a core group of over 20
developers.

About BeOpen:
  <get text for this>

About Python:

   More information about Python can be obtained from the official Python
   website, http://www.python.org. 

(XXX Do you include About sections for the companies that provide quotes?)

Press contacts:
XXX whose address?




From guido at python.org  Thu Oct 26 06:02:11 2000
From: guido at python.org (Guido van Rossum)
Date: Wed, 25 Oct 2000 23:02:11 -0500
Subject: [Python-Dev] sys.__stdout__
In-Reply-To: Your message of "Thu, 26 Oct 2000 10:29:52 +1100."
             <ECEPKNMJLHAPFFJHDOJBOEOFDOAA.MarkH@ActiveState.com> 
References: <ECEPKNMJLHAPFFJHDOJBOEOFDOAA.MarkH@ActiveState.com> 
Message-ID: <200010260402.XAA03016@cj20424-a.reston1.va.home.com>

> So what _is_ it intended for?

Example: IDLE redirects sys.stderr so that it gets displayed in the
Python Shell window with a different text color.  But occasionally I
need to debug IDLE and the bug is in the text drawing.  Then it's nice
if I can write to __stderr__, which goes to the console.

Or suppose I'm in a regular interactive session and I've managed to
screw myself by assigning a bogus file object to sys.stdout (it
happens :-).  If I know that, I can type sys.stdout = sys.__stdout__
at the >>> prompt and save myself -- so I don't have to restart the
session and perhaps lose valuable data.

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



From fdrake at acm.org  Thu Oct 26 05:55:13 2000
From: fdrake at acm.org (Fred L. Drake, Jr.)
Date: Wed, 25 Oct 2000 23:55:13 -0400 (EDT)
Subject: [Python-Dev] sys.__stdout__ - was RE: [Idle-dev] Doc Commentary
In-Reply-To: <ECEPKNMJLHAPFFJHDOJBOEOFDOAA.MarkH@ActiveState.com>
References: <200010251513.KAA28803@cj20424-a.reston1.va.home.com>
	<ECEPKNMJLHAPFFJHDOJBOEOFDOAA.MarkH@ActiveState.com>
Message-ID: <14839.43809.850142.50138@cj42289-a.reston1.va.home.com>

Mark Hammond writes:
 > * Tools/unicode/makeunicodedata.py - exactly the idiom you despise.
 > * Tools/il8n/pygettext.py - ditto

  I've just fixed these two; too bad checkin messages aren't getting
sent.  ;(

 > * Tools/idle/PyParse.py - disabled, debugging output function - presumably
 > to get around sys.stdout redirection - but this sounds suspect as an idiom
 > to me too!

  I've left this one for someone with a good idea about what to do
about it.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at acm.org>
PythonLabs Team Member




From fdrake at acm.org  Thu Oct 26 06:31:33 2000
From: fdrake at acm.org (Fred L. Drake, Jr.)
Date: Thu, 26 Oct 2000 00:31:33 -0400 (EDT)
Subject: [Python-Dev] Re: [Bug #117070] README instructions for configuring Setup are not helpful
In-Reply-To: <20001025222406.A8389@snowy.squish.net>
References: <200010251752.KAA02444@sf-web2.i.sourceforge.net>
	<20001025222406.A8389@snowy.squish.net>
Message-ID: <14839.45989.450533.514732@cj42289-a.reston1.va.home.com>

[Moved over from a discussion in the bugs list; this relates to bug:
 http://sourceforge.net/bugs/?func=detailbug&bug_id=117070&group_id=5470
 Please be sure to CC: Jon on all replies.]

Jon Ribbens writes:
 > Why the Setup.in/Setup thing at all? Just copying Setup.in to Setup without
 > changes is unexpected enough to warrant mentioning in a paragraph of its
 > own, completely explicitly. The '.in' suffix is usually used for files which
 > autoconf is going to use to create a new file from - you cannot usually
 > simply copy the file yourself. An experienced admin installing Python is
 > more likely to believe the README is wrong than what it tells them to do
 > is correct. Why does the Setup.in file exist in the first place? Surely it
 > should be named 'Setup.dist' (and an identical file 'Setup' exist right from
 > the start).

  Ok, here's the plan:  Change Setup.in to Setup.dist, and provide a
copy as Setup.  Since this doesn't help if the source and build
directories differ, configure.in can be modified to create Setup if
(and only if!) it doesn't exist, by copying it from $srcdir/Modules/.
  I have the changes to configure.in, configure, Setup*, and
Modules/Makefile.pre.in ready, but I still need to update the
instructions in the README & possibly elsewhere.
  Does this sound agreeable?


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at acm.org>
PythonLabs Team Member




From effbot at telia.com  Thu Oct 26 09:15:45 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Thu, 26 Oct 2000 09:15:45 +0200
Subject: [Python-Dev] sys.__stdout__ - was RE: [Idle-dev] Doc Commentary
References: <ECEPKNMJLHAPFFJHDOJBOEOFDOAA.MarkH@ActiveState.com>
Message-ID: <002f01c03f1c$9d721ef0$3c6340d5@hagrid>

mark wrote:
> > If you know of any places that are promoting direct use of __stdout__,
> > please let them know this is wrong.  If you are contemplating to use
> > this in code examples you intend to distribute, please don't!
> 
> I admit that I first became aware of sys.__stdout__ after seeing this exact
> same idiom in other peoples code.  I always assumed that this is _exactly_
> what sys.__stdout__ was to be used for!
> 
> The following examples exist:

and several examples in the eff-bot guide.

guess I'll have to fix it in the second edition...

</F>




From ping at lfw.org  Thu Oct 26 10:09:44 2000
From: ping at lfw.org (Ka-Ping Yee)
Date: Thu, 26 Oct 2000 01:09:44 -0700 (PDT)
Subject: [Python-Dev] getting at the current frame
In-Reply-To: <14837.60682.437334.797392@anthem.concentric.net>
Message-ID: <Pine.LNX.4.10.10010252356410.7079-100000@skuld.kingmanhall.org>

On Tue, 24 Oct 2000, Barry A. Warsaw wrote:
> 
> Okay, we all know that's a pain, right?  Lots of people have proposed
> solutions.  I've looked briefly at !?ng's Itpl.py, but I think it
> probably does too much by adding evaluation.

Do you think a variant of Itpl that only looked up variable names
would solve your problem?

> I can define _() to make the problem somewhat more convenient:
> 
>     def _(s):
> 	try:
> 	    raise Exception
> 	except Exception:
> 	    frame = sys.exc_info()[2].tb_frame.f_back
> 	d = frame.f_globals.copy()
> 	d.update(frame.f_locals())
> 	return the_translation_of(s) % d

How about this routine to get the current frame: inspect.currentframe().

Could i humbly re-request approval for inspect.py in the standard library?

    http://lfw.org/python/inspect.py

It's been up there for a long time, there's lots of good stuff in it,
and previous feedback on this list has all been fairly positive --
there just hasn't been an explicit approval for inclusion.  This is
probably because we were busy trying to get 2.0 released (even though
inspect.py was proposed here before ascii.py, and ascii.py did get
accepted).

I think the functionality it provides is important to supporting the
language definition.  It abstracts away the special secret attributes
and protects us from future changes in the internals.

If there are changes that need to be made before it can be accepted,
i'd be happy to make them.


-- ?!ng




From effbot at telia.com  Thu Oct 26 10:36:14 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Thu, 26 Oct 2000 10:36:14 +0200
Subject: [Python-Dev] getting at the current frame
References: <Pine.LNX.4.10.10010252356410.7079-100000@skuld.kingmanhall.org>
Message-ID: <014501c03f27$cec2ef10$3c6340d5@hagrid>

> Could i humbly re-request approval for inspect.py in the standard library?
> 
>     http://lfw.org/python/inspect.py
> 
> It's been up there for a long time

hey, you still haven't fixed the *2 bug...

> I think the functionality it provides is important to supporting the
> language definition.  It abstracts away the special secret attributes
> and protects us from future changes in the internals.

agreed.

> inspect.py was proposed here before ascii.py, and ascii.py did get
> accepted

as part of the curses package, yes.

</F>




From ping at lfw.org  Thu Oct 26 10:53:56 2000
From: ping at lfw.org (Ka-Ping Yee)
Date: Thu, 26 Oct 2000 01:53:56 -0700 (PDT)
Subject: [Python-Dev] getting at the current frame
In-Reply-To: <014501c03f27$cec2ef10$3c6340d5@hagrid>
Message-ID: <Pine.LNX.4.10.10010260153110.7079-100000@skuld.kingmanhall.org>

On Thu, 26 Oct 2000, Fredrik Lundh wrote:
> > It's been up there for a long time
> 
> hey, you still haven't fixed the *2 bug...

Sorry -- looks like an older version than the one i have on my local
disk, which did get fixed.  The one on the website is now up to date.

    http://lfw.org/python/inspect.py


-- ?!ng




From jon+sourceforge at unequivocal.co.uk  Thu Oct 26 11:39:01 2000
From: jon+sourceforge at unequivocal.co.uk (Jon Ribbens)
Date: Thu, 26 Oct 2000 10:39:01 +0100
Subject: [Python-Dev] Re: [Bug #117070] README instructions for configuring Setup are not helpful
In-Reply-To: <14839.45989.450533.514732@cj42289-a.reston1.va.home.com>; from fdrake@acm.org on Thu, Oct 26, 2000 at 12:31:33AM -0400
References: <200010251752.KAA02444@sf-web2.i.sourceforge.net> <20001025222406.A8389@snowy.squish.net> <14839.45989.450533.514732@cj42289-a.reston1.va.home.com>
Message-ID: <20001026103901.A11873@snowy.squish.net>

"Fred L. Drake, Jr." <fdrake at acm.org> wrote:
>   Ok, here's the plan:  Change Setup.in to Setup.dist, and provide a
> copy as Setup.  Since this doesn't help if the source and build
> directories differ, configure.in can be modified to create Setup if
> (and only if!) it doesn't exist, by copying it from $srcdir/Modules/.
>   Does this sound agreeable?

Sounds cool. I would mention in the first part of the install instructions
about the Setup file, that you edit it to change the available modules
(this concept is not obvious if you don't know how Python works!),
that you can edit it now but if you have not installed Python before it is
best to try building without editing it first and that there are more
instructions further down the README. You might like to mention 'readline'
here too to head-off newsgroup questions about why up-arrow doesn't work ;-).

Cheers


Jon



From guido at python.org  Thu Oct 26 13:38:34 2000
From: guido at python.org (Guido van Rossum)
Date: Thu, 26 Oct 2000 06:38:34 -0500
Subject: [Python-Dev] sys.__stdout__
In-Reply-To: Your message of "Wed, 25 Oct 2000 23:55:13 -0400."
             <14839.43809.850142.50138@cj42289-a.reston1.va.home.com> 
References: <200010251513.KAA28803@cj20424-a.reston1.va.home.com> <ECEPKNMJLHAPFFJHDOJBOEOFDOAA.MarkH@ActiveState.com>  
            <14839.43809.850142.50138@cj42289-a.reston1.va.home.com> 
Message-ID: <200010261138.GAA04678@cj20424-a.reston1.va.home.com>

>  > * Tools/idle/PyParse.py - disabled, debugging output function - presumably
>  > to get around sys.stdout redirection - but this sounds suspect as an idiom
>  > to me too!
> 
> I've left this one for someone with a good idea about what to do
> about it.

Don't touch it!  This one is needed because at this point sys.stdout
and sys.stderr are redirected to a window where you don't want the
parser debug output to show up.  (I mentioned this example in my
previous post.)

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



From guido at python.org  Thu Oct 26 13:45:49 2000
From: guido at python.org (Guido van Rossum)
Date: Thu, 26 Oct 2000 06:45:49 -0500
Subject: [Python-Dev] Re: [Bug #117070] README instructions for configuring Setup are not helpful
In-Reply-To: Your message of "Thu, 26 Oct 2000 00:31:33 -0400."
             <14839.45989.450533.514732@cj42289-a.reston1.va.home.com> 
References: <200010251752.KAA02444@sf-web2.i.sourceforge.net> <20001025222406.A8389@snowy.squish.net>  
            <14839.45989.450533.514732@cj42289-a.reston1.va.home.com> 
Message-ID: <200010261145.GAA04767@cj20424-a.reston1.va.home.com>

[Fred]
>   Ok, here's the plan:  Change Setup.in to Setup.dist, and provide a
> copy as Setup.  Since this doesn't help if the source and build
> directories differ, configure.in can be modified to create Setup if
> (and only if!) it doesn't exist, by copying it from $srcdir/Modules/.
>   I have the changes to configure.in, configure, Setup*, and
> Modules/Makefile.pre.in ready, but I still need to update the
> instructions in the README & possibly elsewhere.
>   Does this sound agreeable?

Sure, except I'm not comfortable with having two files with identical
contents under CVS control.  How about not checking in Setup, but
creating it in configure if it doesn't exist?

This is necessary also for the following reason: when you build in a
different tree than the source tree, you should get a fresh copy of
Setup in the build tree -- another copy of Setup in the source tree is
useless.

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



From guido at python.org  Thu Oct 26 13:48:20 2000
From: guido at python.org (Guido van Rossum)
Date: Thu, 26 Oct 2000 06:48:20 -0500
Subject: [Python-Dev] getting at the current frame
In-Reply-To: Your message of "Thu, 26 Oct 2000 01:09:44 MST."
             <Pine.LNX.4.10.10010252356410.7079-100000@skuld.kingmanhall.org> 
References: <Pine.LNX.4.10.10010252356410.7079-100000@skuld.kingmanhall.org> 
Message-ID: <200010261148.GAA04780@cj20424-a.reston1.va.home.com>

> Could i humbly re-request approval for inspect.py in the standard library?
> 
>     http://lfw.org/python/inspect.py

To avoid that we forget about this again, and to make sure it gets
proper treatment, could you submit it through the patch manager?  No
need to turn it into a context diff, just upload the entire file.

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



From thomas at xs4all.net  Thu Oct 26 12:21:05 2000
From: thomas at xs4all.net (Thomas Wouters)
Date: Thu, 26 Oct 2000 12:21:05 +0200
Subject: [Python-Dev] A small step to removing the type/class split
In-Reply-To: <200010250114.OAA28255@s454.cosc.canterbury.ac.nz>; from greg@cosc.canterbury.ac.nz on Wed, Oct 25, 2000 at 02:14:52PM +1300
References: <20001024073712.A10539@glacier.fnational.com> <200010250114.OAA28255@s454.cosc.canterbury.ac.nz>
Message-ID: <20001026122105.N12812@xs4all.nl>

On Wed, Oct 25, 2000 at 02:14:52PM +1300, Greg Ewing wrote:
> Neil Schemenauer <nas at arctrix.com>:

> > Those PyInstance_Check() calls should really go away. Instead, the
> > type should be responsible for providing different behavior.

> Yes, that's the crux of the problem, I think.

> Another place where this is a nuisance is where it
> assumes that if x has any tp_as_sequence slots and y
> has any tp_as_number slots, then x*y is a sequence
> replication operation.

This is screwed in more than one way. The logic of which 'type' operation
has precedence isn't even internally consistent. The case of 'x*y' and 'x+y'
check the tp_as_number and tp_as_sequence slots in a *different order*, so
'x*y' can end up a number where 'x+y' ends up a sequence. (Or the other way
'round, I forget. I'm also struggling to catch up on my mail since Apachecon
had little to no connectivity, so I don't feel like checking :)

Brainwashed-into-Apache-2.0-forever-ly y'rs,
-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!



From thomas at xs4all.net  Thu Oct 26 12:51:30 2000
From: thomas at xs4all.net (Thomas Wouters)
Date: Thu, 26 Oct 2000 12:51:30 +0200
Subject: [Python-Dev] ViewCVS on Sourceforge
Message-ID: <20001026125130.O12812@xs4all.nl>

I had a chat with Greg Stein about ViewCVS on the ApacheCon (I think Jon
Travis and Gregory Trubetskoy where there as well, but my memory is a bit
hazy) and since he's probably in some airplane over the atlantic right now,
I'll run away and steal his idea ;) We were kind of reflecting how nice it
would be if we could have ViewCVS, instead of cvsweb, on SourceForge. The
nice thing about ViewCVS is that it's a lot more efficient than cvsweb, and
it doesn't need write access to the repository itself. So how about we run
ViewCVS on python.sourceforge.net ourselves ?

We could do it now, in fact, with the complete CVS snapshot that gets made
every once in a while (that *does* still get made & backupped, right ?)
though it would obviously be a lot more useful if ViewCVS just had direct
access to the repository. I'm not sure how accessible that repository is,
however. Cursory searches on shell.sourceforge.net doesn't show anything,
except that the python-cvs.tgz that's in /home/projects/python is apparently
the one used for the move to sourceforge :-) Can we get access to the
repository directly, even if it's only semi-realtime ? (I wouldn't mind
doing a couple of rsync's in cron to keep it up to date) If anything,
running ViewCVS will show SourceForge how much nicer it is... ;-)

-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!



From jon+sourceforge at unequivocal.co.uk  Thu Oct 26 13:01:27 2000
From: jon+sourceforge at unequivocal.co.uk (Jon Ribbens)
Date: Thu, 26 Oct 2000 12:01:27 +0100
Subject: [Python-Dev] Re: [Bug #117070] README instructions for configuring Setup are not helpful
In-Reply-To: <200010261145.GAA04767@cj20424-a.reston1.va.home.com>; from guido@python.org on Thu, Oct 26, 2000 at 06:45:49AM -0500
References: <200010251752.KAA02444@sf-web2.i.sourceforge.net> <20001025222406.A8389@snowy.squish.net> <14839.45989.450533.514732@cj42289-a.reston1.va.home.com> <200010261145.GAA04767@cj20424-a.reston1.va.home.com>
Message-ID: <20001026120127.B11873@snowy.squish.net>

Guido van Rossum <guido at python.org> wrote:
> Sure, except I'm not comfortable with having two files with identical
> contents under CVS control.  How about not checking in Setup, but
> creating it in configure if it doesn't exist?

I think that would be fine so long as the README file makes it clear that
you edit the Setup file after './configure' but before 'make'.

Cheers


Jon



From mal at lemburg.com  Thu Oct 26 13:23:19 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Thu, 26 Oct 2000 13:23:19 +0200
Subject: [Python-Dev] 2.0 articles
References: <E13oYSS-00071f-00@kronos.cnri.reston.va.us>
Message-ID: <39F81427.FF4223C2@lemburg.com>

Andrew Kuchling wrote:
> 
> I'd like to begin writing an article about 2.0's Unicode support.
> Before beginning, has anyone else already begun this task?  If yes,
> please let me know...

I've already started something in that direction. The plan is to
write down the story of adding Unicode support to Python, the
pifalls, solutions, hacks, etc. I'll probably submit it to DDJ.

A article about *using* Unicode support would of course
be a nice complement to get a feeling of how it's like working
with the implementation :-)
 
> (Incidentally, did a 2.0 press release ever go out?  Is someone going
> to write one?)
> 
> --amk
> 
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://www.python.org/mailman/listinfo/python-dev

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From fdrake at acm.org  Thu Oct 26 14:21:08 2000
From: fdrake at acm.org (Fred L. Drake, Jr.)
Date: Thu, 26 Oct 2000 08:21:08 -0400 (EDT)
Subject: [Python-Dev] sys.__stdout__
In-Reply-To: <200010261138.GAA04678@cj20424-a.reston1.va.home.com>
References: <200010251513.KAA28803@cj20424-a.reston1.va.home.com>
	<ECEPKNMJLHAPFFJHDOJBOEOFDOAA.MarkH@ActiveState.com>
	<14839.43809.850142.50138@cj42289-a.reston1.va.home.com>
	<200010261138.GAA04678@cj20424-a.reston1.va.home.com>
Message-ID: <14840.8628.315347.722506@cj42289-a.reston1.va.home.com>

I wrote:
 > I've left this one for someone with a good idea about what to do
 > about it.

Guido van Rossum replied:
 > Don't touch it!  This one is needed because at this point sys.stdout
 > and sys.stderr are redirected to a window where you don't want the
 > parser debug output to show up.

  See, I knew someone would come up with a better idea!  ;)


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at acm.org>
PythonLabs Team Member




From skip at mojam.com  Thu Oct 26 14:31:36 2000
From: skip at mojam.com (Skip Montanaro)
Date: Thu, 26 Oct 2000 07:31:36 -0500 (CDT)
Subject: [Python-Dev] Re: [Bug #117070] README instructions for configuring Setup are not helpful
In-Reply-To: <14839.45989.450533.514732@cj42289-a.reston1.va.home.com>
References: <200010251752.KAA02444@sf-web2.i.sourceforge.net>
	<20001025222406.A8389@snowy.squish.net>
	<14839.45989.450533.514732@cj42289-a.reston1.va.home.com>
Message-ID: <14840.9256.408848.728486@beluga.mojam.com>

    Fred> Ok, here's the plan: Change Setup.in to Setup.dist, and provide a
    copy as Setup.

I don't like the idea that a file I am supposed to edit (Setup) would be in
the CVS repository where it could conceivably get messed with by a "cvs up"
command.  The current makefile target that emits a warning if Setup.in
(.dist) is newer than Setup should be sufficient to alert users when Setup
needs to be looked at.

-- 
Skip Montanaro (skip at mojam.com)
http://www.mojam.com/
http://www.musi-cal.com/



From skip at mojam.com  Thu Oct 26 14:34:09 2000
From: skip at mojam.com (Skip Montanaro)
Date: Thu, 26 Oct 2000 07:34:09 -0500 (CDT)
Subject: [Python-Dev] getting at the current frame
In-Reply-To: <Pine.LNX.4.10.10010252356410.7079-100000@skuld.kingmanhall.org>
References: <14837.60682.437334.797392@anthem.concentric.net>
	<Pine.LNX.4.10.10010252356410.7079-100000@skuld.kingmanhall.org>
Message-ID: <14840.9409.491061.671168@beluga.mojam.com>

    Ping> Could i humbly re-request approval for inspect.py in the standard
    Ping> library?

    Ping>     http://lfw.org/python/inspect.py

+1.  I've written functions over the years to do some small bits of what
inspect.py does.  I'd much rather have those things in a standard place with
more eyeballs checking them for correctness.

Skip



From akuchlin at mems-exchange.org  Thu Oct 26 14:56:26 2000
From: akuchlin at mems-exchange.org (Andrew Kuchling)
Date: Thu, 26 Oct 2000 08:56:26 -0400
Subject: [Python-Dev] 2.0 articles
In-Reply-To: <39F81427.FF4223C2@lemburg.com>; from mal@lemburg.com on Thu, Oct 26, 2000 at 01:23:19PM +0200
References: <E13oYSS-00071f-00@kronos.cnri.reston.va.us> <39F81427.FF4223C2@lemburg.com>
Message-ID: <20001026085626.A27785@kronos.cnri.reston.va.us>

On Thu, Oct 26, 2000 at 01:23:19PM +0200, M.-A. Lemburg wrote:
>A article about *using* Unicode support would of course
>be a nice complement to get a feeling of how it's like working

And that's what I want to write, so it works out nicely; great!

Finn, your comment has been noted; I'll take note of any differences
with Jython's Unicode support.  A draft will be announced on
python-dev, whenever it actually gets done.

--amk




From mal at lemburg.com  Thu Oct 26 15:07:35 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Thu, 26 Oct 2000 15:07:35 +0200
Subject: [Python-Dev] Gradual migration
References: <39F52EF1.A201C6D9@prescod.net> <39F54C0F.25798309@lemburg.com> <39F5B4DC.C226D8F6@prescod.net> <39F5E4FA.9FD6D35@lemburg.com> <39F72256.C7F93BFB@prescod.net>
Message-ID: <39F82C97.12D04C85@lemburg.com>

Paul Prescod wrote:
> 
> "M.-A. Lemburg" wrote:
> >
> > ...
> >
> > >  * implementation language and Python inheritance semantics are almost
> > > completely distinct. After all, we have Python implementations in a
> > > variety of languages with minor incompatibilities. Python could have a
> > > proper type/class merging even if it were written in assembly language.
> > > So let's leave implementation language aside.
> >
> > Hey, think of it as opportunity: we can reuse much of C++'s
> > optimizations and the integration of Python and C++ applications
> > will get *much* easier.
> 
> We could make integrating C++ and Python easier through CXX or Py_Cpp.
> Perhaps we should ship one of those with Python 2.1. Anyhow, integrating
> C++ and Python is not really so hard, in my experience.

Ok, you can use SWIG to get most of the work done, but the interface
between the C++ object world and the Python object world is one
big mess -- all implementations I've seen use shadow objects
or proxies to interface from one to the other... with lots of
temporary objects used for the linkup.

Having Python itself written in C++ we could do *much* better.

But that's only a nice side-effect. The real argument here is
that we can push the type logic one layer further down. Ideal would
be a level of integration such as the one implemented in JPython
or Jython.
 
> > A rewrite shouldn't scare anyone away -- much of the existing
> > code can be reused since only the Python C APIs of the various
> > types will have to be rewritten, not the logic behind the types.
> 
> I wasn't really addressing the issue of backwards compatibility of
> extensions -- I was talking about Python programs. Nevertheless, I can't
> resist:
> 
> Porting your app to the Python APIs is often the majority of the work in
> a particular extension. A lot of Python extensions consist only of API
> glue!

True, but we're lucky, since we could provide a compatibility
layer on top of the new API.

BTW, I think I now know what your main concern is: the Python
level compatibility. I was talking of what goes on under the
hood and still think that Py3K should be used as a chance to
simplify the Python backend. As simplification often means
generalization, we'll open up new doors for future developments
along the way.

> > > I don't know what you mean by a "low-level strategy" for classes. It's
> > > not like we can somehow use C++ vtables without giving up Python's
> > > dynamicity. Python's class handling is about as low-level as it can get
> > > in my humble opinion.
> >
> > With "low-level" I meant trying to build Python classes and
> > instances on top of a very thin layer on top of C++ classes,
> > e.g. all slots could be implemented using true C++ methods with
> > additional logic to override them using dynamically bound
> > Python method objects.
> 
> I don't think that there is really interesting magic in a C++ compiler.
> A vtable is an array of pointers to functions. We've already implemented
> the equivalent in ANSI C. C++ exceptions, constructors, destriuctors and
> smart pointers are a little more interesting from a code maintenance and
> simplicity point of view. But even then I think that we could get to a
> C++ implementation through incremental rewrites.

Naa, the whole type slot interface is one big mess (sorry, Guido :-).
some slots are packaged, some are not, some are NULL, some are not,
there are oodles of sometimes weird dependencies between the
slots which are not really documented, etc. etc.

The slot design has serious drawbacks and should be replaced by
something more reliable, preferably C++ methods. That way, we'll
get some more "type" safety into Python and its extensions.

Note that porting old extensions won't be all that hard: 
a class reusing the existing slot functions as methods should
suffice in many cases.

> > Why spoil all the fun when we haven't even started thinking
> > about all the possibilities we could use to make Py3k a
> > success ?
> 
> Asking for a map of where we are going and how we will get here is
> "spoiling all of the fun?" I'm not sure what you are reacting to -- I
> didn't advise one implementation strategy or another -- I just said that
> we should employ a strategy that minimizes sudden and surprising code
> breakage.

Ok, we've been talking about different things here: with "spoiling
the fun" I meant putting ropes on possible changes to the C 
backend. 

You are talking about the frontend and I agree with you
that there should be a clear upgrade path from the 2.x series
to Py3K w/r to the Python side of things.

So I guess it's time for some PEPs now... the upgrade path
PEP and the fluffy clouds PEP.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From guido at python.org  Thu Oct 26 16:42:40 2000
From: guido at python.org (Guido van Rossum)
Date: Thu, 26 Oct 2000 09:42:40 -0500
Subject: [Python-Dev] Re: [Bug #117070] README instructions for configuring Setup are not helpful
In-Reply-To: Your message of "Thu, 26 Oct 2000 12:01:27 +0100."
             <20001026120127.B11873@snowy.squish.net> 
References: <200010251752.KAA02444@sf-web2.i.sourceforge.net> <20001025222406.A8389@snowy.squish.net> <14839.45989.450533.514732@cj42289-a.reston1.va.home.com> <200010261145.GAA04767@cj20424-a.reston1.va.home.com>  
            <20001026120127.B11873@snowy.squish.net> 
Message-ID: <200010261442.JAA05046@cj20424-a.reston1.va.home.com>

> I think that would be fine so long as the README file makes it clear that
> you edit the Setup file after './configure' but before 'make'.

One thing -- it's perfectly fine to edit Setup after running Make for
the first time.  You just have to run Make again.  The Makefiles are
designed for this.

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



From paul at prescod.net  Thu Oct 26 15:56:40 2000
From: paul at prescod.net (Paul Prescod)
Date: Thu, 26 Oct 2000 06:56:40 -0700
Subject: [Python-Dev] Gradual migration
References: <39F52EF1.A201C6D9@prescod.net> <39F54C0F.25798309@lemburg.com> <39F5B4DC.C226D8F6@prescod.net> <39F5E4FA.9FD6D35@lemburg.com> <39F72256.C7F93BFB@prescod.net> <39F82C97.12D04C85@lemburg.com>
Message-ID: <39F83818.38EA64AE@prescod.net>

"M.-A. Lemburg" wrote:
> 
> ...
> 
> Having Python itself written in C++ we could do *much* better.

Agree.

> ...
> 
> The slot design has serious drawbacks and should be replaced by
> something more reliable, preferably C++ methods. That way, we'll
> get some more "type" safety into Python and its extensions.

I agree that the slot stuff is broken but my solution would be to junk
it and use the same mechanism for looking up "type methods" and
"instance methods". I can think of two ways to make that perform
reasonably: one is method caching and the other is by building interface
objects where methods are invoked by index -- basically vtables. But if
the same mechanism is going to accelerate Python and C types alike then
it can't really use C++ vtables because how do you generate a vtable at
runtime for a new Python class? (you could also think of it as a COM
interface object)

> So I guess it's time for some PEPs now... the upgrade path
> PEP and the fluffy clouds PEP.

Good timing. I just finished the first draft of the upgrade path PEP.

-- 
 Paul Prescod - Not encumbered by corporate consensus
Simplicity does not precede complexity, but follows it. 
	- http://www.cs.yale.edu/homes/perlis-alan/quotes.html



From barry at wooz.org  Thu Oct 26 15:24:49 2000
From: barry at wooz.org (Barry A. Warsaw)
Date: Thu, 26 Oct 2000 09:24:49 -0400 (EDT)
Subject: [Python-Dev] getting at the current frame
References: <14837.60682.437334.797392@anthem.concentric.net>
	<Pine.LNX.4.10.10010252356410.7079-100000@skuld.kingmanhall.org>
	<14840.9409.491061.671168@beluga.mojam.com>
Message-ID: <14840.12449.241947.715016@anthem.concentric.net>

>>>>> "SM" == Skip Montanaro <skip at mojam.com> writes:

    Ping> Could i humbly re-request approval for inspect.py in the
    Ping> standard library?

    Ping> http://lfw.org/python/inspect.py

    SM> +1.  I've written functions over the years to do some small
    SM> bits of what inspect.py does.  I'd much rather have those
    SM> things in a standard place with more eyeballs checking them
    SM> for correctness.

I've downloaded it, and will take a look.



From jim at interet.com  Thu Oct 26 16:03:43 2000
From: jim at interet.com (James C. Ahlstrom)
Date: Thu, 26 Oct 2000 10:03:43 -0400
Subject: [Python-Dev] What to choose to replace Tkinter?
References: <14837.14407.954185.466011@buffalo.fnal.gov> <ECEPKNMJLHAPFFJHDOJBKEKIDOAA.MarkH@ActiveState.com> <14837.43273.24692.93965@buffalo.fnal.gov> <20001024114326.E13957@kronos.cnri.reston.va.us>  
	            <39F6B8B8.E3242929@interet.com> <200010251225.HAA22242@cj20424-a.reston1.va.home.com>
Message-ID: <39F839BF.DD1B86BF@interet.com>

Guido van Rossum wrote:

> To me this all sounds like FUD.

True, but FUD is real and I have no apologies.

> Since Python 1.6 and 2.0, you don't
> have to install Tcl/Tk or its libraries -- it is installed
> *transparently* by the Python Windows installer.

We don't use the Python Windows installer.  Our app
has to use its own installer, and I would then have to run
two installers, one of which I don't understand.

Sorry to be such an old fuddy-duddy, but you will
get the same reaction from most commercial software
vendors.  Make that nearly ALL vendors.

JimA



From jim at interet.com  Thu Oct 26 16:06:02 2000
From: jim at interet.com (James C. Ahlstrom)
Date: Thu, 26 Oct 2000 10:06:02 -0400
Subject: [Python-Dev] What to choose to replace Tkinter?
References: <Pine.LNX.4.10.10010241146450.6622-100000@akbar.nevex.com> <200010241739.MAA16414@cj20424-a.reston1.va.home.com>  
	            <39F6BA29.3CAB4C0E@interet.com> <200010251227.HAA22256@cj20424-a.reston1.va.home.com>
Message-ID: <39F83A4A.26E543A3@interet.com>

Guido van Rossum wrote:

> Even Microsoft is violating its own (boring) style guide, when they
> think it appeals to a specific audience.  Have you seen their Media
> Player?

Yes, very slick.  My daughter has an app where you click on
doors to access parts of the program.  Nice design.

JimA



From gward at mems-exchange.org  Thu Oct 26 16:18:50 2000
From: gward at mems-exchange.org (Greg Ward)
Date: Thu, 26 Oct 2000 10:18:50 -0400
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: <39F83A4A.26E543A3@interet.com>; from jim@interet.com on Thu, Oct 26, 2000 at 10:06:02AM -0400
References: <Pine.LNX.4.10.10010241146450.6622-100000@akbar.nevex.com> <200010241739.MAA16414@cj20424-a.reston1.va.home.com> <39F6BA29.3CAB4C0E@interet.com> <200010251227.HAA22256@cj20424-a.reston1.va.home.com> <39F83A4A.26E543A3@interet.com>
Message-ID: <20001026101850.A14742@ludwig.cnri.reston.va.us>

On 26 October 2000, James C. Ahlstrom said:
> Guido van Rossum wrote:
> 
> > Even Microsoft is violating its own (boring) style guide, when they
> > think it appeals to a specific audience.  Have you seen their Media
> > Player?
> 
> Yes, very slick.  My daughter has an app where you click on
> doors to access parts of the program.  Nice design.

This is generally considered Bad Form by usability types.  I think it
boils down to this: the computer is not the real world, and trying to
emulate the real world on the computer is cutesy but a dead end.

Go look for "User Interface Hall of Shame" at your friendly
neighbourhood search engine for many enjoyable rants against bad GUI
design, including the "emulate the real world" school of thought.

Anyways, this is not a usability mailing list... back to our regularly
scheduled python-dev...

        Greg
-- 
Greg Ward - software developer                gward at mems-exchange.org
MEMS Exchange / CNRI                           voice: +1-703-262-5376
Reston, Virginia, USA                            fax: +1-703-262-5367



From paul at prescod.net  Thu Oct 26 16:28:12 2000
From: paul at prescod.net (Paul Prescod)
Date: Thu, 26 Oct 2000 07:28:12 -0700
Subject: [Python-Dev] Gradual migration PEP
Message-ID: <39F83F7C.2241158F@prescod.net>

PEP: XXX 
Title: Guidelines for introducing backwards incompatibilities 
Version: $Revision: 1.0 $ 
Author: Paul Prescod <paul at prescod.net,paulp at activestate.com> 
Status: Draft Type: Standards Track 
Python-Version: All
Created: 25-Oct-2000

Abstract

    In the natural evolution of programming languages it is sometimes
    necessary to make changes that modify the behaviour of older
programs.
    This PEP proposes a policy for implementing these changes in a
manner
    respectful of the installed base of Python users.

Implementation Details

    Implementation of this PEP requires the addition of a formal warning
    and deprecation facility that will be described in another proposal.

Scope

    These guidelines apply to future versions of Python that introduce
    backward-incompatible behaviour. Backward incompatible behaviour is
    a major deviation in Python interpretation from an earlier behaviour
    described in the standard Python documentation. Removal of a feature
    also constitutes a change of behaviour.

    This PEP does not replace or preclude other compatibility strategies
    such as dynamic loading of backwards-compatible parsers. On the
    other hand, if execution of "old code" requires a special switch or
    pragma then that is indeed a change of behavior from the point of
    view of the user and that change should be implemented according to
    these guidelines.

    In general, common sense must prevail in the implementation of these
    guidelines. For instance changing "sys.copyright" does not
constitute
    a backwards-incompatible change of behavior!

Steps For Introducting Backwards-Incompatible Features

    1. Propose backwards-incompatible behavior in a PEP. The PEP must
       include a section on backwards compatibility that describes in
       detail a plan to complete the remainder of these steps.

    2. Once the PEP is accepted as a productive direction, implement an
       alternate way to accomplish the task previously provided by the
       feature that is being removed or changed. For instance if the
       addition operator were scheduled for removal, a new version of
       Python could implement an "add()" built-in function.

    3. Formally deprecate the obsolete construct in the Python
       documentation.

    4. Add an an optional warning mode to the parser that will inform
       users when the deprecated construct is used. In other words, all
       programs that will behave differently in the future must trigger
       warnings in this mode. Compile-time warnings are preferable to
       runtime warnings. The warning messages should steer people from
       the deprecated construct to the alternative construct.

    5. There must be at least a one-year transition period between
       the release of the transitional version of Python and the release
       of the backwards incompatible version. Users will have at least
       a year to test their programs and migrate them from use of the
       deprecated construct to the alternative one.


Local Variables: 
mode: indented-text 
indent-tabs-mode: nil 
End:



From paul at prescod.net  Thu Oct 26 16:35:48 2000
From: paul at prescod.net (Paul Prescod)
Date: Thu, 26 Oct 2000 07:35:48 -0700
Subject: [Python-Dev] What to choose to replace Tkinter?
References: <ECEPKNMJLHAPFFJHDOJBCEOADOAA.MarkH@ActiveState.com>
Message-ID: <39F84144.105D1754@prescod.net>

Mark Hammond wrote:
> 
>...
> 
> I don't think it will be "fixed", as it is not considered "broken".  It was
> an explicit choice to leave out Tcl/Tk.  And my recollection is that the
> "feedback" address sees more requests for wxPython than Tcl/Tk.

That's all true. We also make it very easy to find the right version of
Tcl/Tk and will probably go even farther in this direction in the
future. Built-in Tcl/Tk support is not out of the question but there are
various user confusion issues: "Why are there two GUI frameworks in this
development environment? Why are there two development environments in
this development environment? Doesn't ActiveState have yet another GUI
framework and development environment under development?" "Why do I need
Tcl at all? What is its relationship with Python?

There are clear benefits to including Tcl/Tk but there are also costs
and its possible we'll weigh them differently in the future.

BTW: ActivePython does include Tkinter.

-- 
 Paul Prescod
Simplicity does not precede complexity, but follows it. 
	- http://www.cs.yale.edu/homes/perlis-alan/quotes.html



From gmcm at hypernet.com  Thu Oct 26 16:49:20 2000
From: gmcm at hypernet.com (Gordon McMillan)
Date: Thu, 26 Oct 2000 10:49:20 -0400
Subject: [Python-Dev] Gradual migration
In-Reply-To: <39F82C97.12D04C85@lemburg.com>
Message-ID: <39F80C30.5448.52D32F94@localhost>

[Paul]
> > We could make integrating C++ and Python easier through CXX or Py_Cpp.
> > Perhaps we should ship one of those with Python 2.1. Anyhow, integrating
> > C++ and Python is not really so hard, in my experience.

... or a number of others (but SWIG falls very short when it 
comes to things like C++ references)...

[Marc-Andre]
> Ok, you can use SWIG to get most of the work done, but the interface
> between the C++ object world and the Python object world is one
> big mess -- all implementations I've seen use shadow objects
> or proxies to interface from one to the other... with lots of
> temporary objects used for the linkup.

While I agree it's messy, those are not the objectionable 
qualities. Any refcounted C++ system is going to have proxies 
(smart pointers / refcounting stack-safe "reference" objects to 
the real heap-based objects).

And while I think we'd be better off with a C++ implementation, 
I would warn that C++'s notion of inheritence is in conflict with 
Python's. It won't be "as above, so below" (unless we screw 
interpreting and go straight to native code). Assuming that the 
class / type dichotomy actually gets healed, that is.
 
> ... The real argument here is
> that we can push the type logic one layer further down. Ideal would
> be a level of integration such as the one implemented in JPython
> or Jython.

Nope. If you heal the class / type split, there's really only one 
underlying type object. Unless you go the other way, and write 
"native" code (as JPython does).

All of the existing C++ interfaces / helpers deal only with type 
objects (at least, those that I've examined, which is most of 
them). In fact, only ExtensionClass attempts to deal with the 
class / type split, and while it's a masterpiece, I think it's a 
great example of everything to avoid in Py3K.
  


- Gordon



From barry at wooz.org  Thu Oct 26 16:58:23 2000
From: barry at wooz.org (Barry A. Warsaw)
Date: Thu, 26 Oct 2000 10:58:23 -0400 (EDT)
Subject: [Python-Dev] Gradual migration
References: <39F52EF1.A201C6D9@prescod.net>
	<39F54C0F.25798309@lemburg.com>
	<39F5B4DC.C226D8F6@prescod.net>
	<39F5E4FA.9FD6D35@lemburg.com>
	<39F72256.C7F93BFB@prescod.net>
	<39F82C97.12D04C85@lemburg.com>
	<39F83818.38EA64AE@prescod.net>
Message-ID: <14840.18063.152674.534458@anthem.concentric.net>

>>>>> "PP" == Paul Prescod <paul at prescod.net> writes:

    PP> I agree that the slot stuff is broken but my solution would be
    PP> to junk it and use the same mechanism for looking up "type
    PP> methods" and "instance methods". I can think of two ways to
    PP> make that perform reasonably: one is method caching and the
    PP> other is by building interface objects where methods are
    PP> invoked by index -- basically vtables. But if the same
    PP> mechanism is going to accelerate Python and C types alike then
    PP> it can't really use C++ vtables because how do you generate a
    PP> vtable at runtime for a new Python class? (you could also
    PP> think of it as a COM interface object)

Objective-C!

:)



From effbot at telia.com  Thu Oct 26 17:14:28 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Thu, 26 Oct 2000 17:14:28 +0200
Subject: [Python-Dev] What to choose to replace Tkinter?
References: <14837.14407.954185.466011@buffalo.fnal.gov> <ECEPKNMJLHAPFFJHDOJBKEKIDOAA.MarkH@ActiveState.com> <14837.43273.24692.93965@buffalo.fnal.gov> <20001024114326.E13957@kronos.cnri.reston.va.us>              <39F6B8B8.E3242929@interet.com> <200010251225.HAA22242@cj20424-a.reston1.va.home.com> <39F839BF.DD1B86BF@interet.com>
Message-ID: <002a01c03f5f$71ca72f0$3c6340d5@hagrid>

jim wrote:
> Sorry to be such an old fuddy-duddy, but you will
> get the same reaction from most commercial software
> vendors.  Make that nearly ALL vendors.

what reaction?

are you saying that your own installer can install the
Python DLL but not the Tk DLL?

</F>




From gmcm at hypernet.com  Thu Oct 26 17:05:02 2000
From: gmcm at hypernet.com (Gordon McMillan)
Date: Thu, 26 Oct 2000 11:05:02 -0400
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: <20001026101850.A14742@ludwig.cnri.reston.va.us>
References: <39F83A4A.26E543A3@interet.com>; from jim@interet.com on Thu, Oct 26, 2000 at 10:06:02AM -0400
Message-ID: <39F80FDE.6102.52E19102@localhost>

James C. Ahlstrom said:

> > Yes, very slick.  My daughter has an app where you click on
> > doors to access parts of the program.  Nice design.

[Greg Ward] 
> This is generally considered Bad Form by usability types.  I think it
> boils down to this: the computer is not the real world, and trying to
> emulate the real world on the computer is cutesy but a dead end.

I once interviewed with a game designer (sports games - 
popular ones, too). He spent half an hour slamming MS's UI 
(his games run on Windows). Then he pulled up his latest 
(opening to a sports stadium) and said "Now here's a real UI". 
So I said "Show me how it works". 

The bozo ended up clicking on random things on the screen 
until something finally happened.

no-no-the-beer-means-OK--the-bimbo-means-CANCEL-ly y'rs

- Gordon



From barry at wooz.org  Thu Oct 26 17:36:37 2000
From: barry at wooz.org (barry at wooz.org)
Date: Thu, 26 Oct 2000 11:36:37 -0400 (EDT)
Subject: [Python-Dev] getting at the current frame
References: <14837.60682.437334.797392@anthem.concentric.net>
	<Pine.LNX.4.10.10010252356410.7079-100000@skuld.kingmanhall.org>
Message-ID: <14840.20357.734136.911927@anthem.concentric.net>

>>>>> "KY" == Ka-Ping Yee <ping at lfw.org> writes:

    >>  Okay, we all know that's a pain, right?  Lots of people have
    >> proposed solutions.  I've looked briefly at !?ng's Itpl.py, but
    >> I think it probably does too much by adding evaluation.

    KY> Do you think a variant of Itpl that only looked up variable
    KY> names would solve your problem?

I think it would calm my objections, yes.  I'll observe that I think
there may be a middle ground between my approach and Itpl.  I've found
a couple of situations where I want a minimal form of evaluation,
e.g. I want attributes to be expanded (and methods called), but not a
general evaluation facility.  So for example, I'd like to be able to
say:

    print _("The name of the mailing list is %(mlist.listname())s")

What worries me about a general evaluation framework is that we then
have to be really really careful about security and origin of the
strings we're using here.  Maybe we'd need to adopt something like
Perl's taint strings.

    KY> How about this routine to get the current frame:
    KY> inspect.currentframe().

It uses the same intentional-exception trick to get at the current
frame.  It's about 8x faster to do it in C.  I'll note that your
version raises and catches a string exception, while mine uses an
exception instance.  I don't see much difference in speed between the
two.

    KY> If there are changes that need to be made before it can be
    KY> accepted, i'd be happy to make them.

Sent under a separate private response...

-Barry



From gward at mems-exchange.org  Thu Oct 26 18:03:09 2000
From: gward at mems-exchange.org (Greg Ward)
Date: Thu, 26 Oct 2000 12:03:09 -0400
Subject: [Python-Dev] getting at the current frame
In-Reply-To: <14837.60682.437334.797392@anthem.concentric.net>; from barry@wooz.org on Tue, Oct 24, 2000 at 04:11:54PM -0400
References: <14837.60682.437334.797392@anthem.concentric.net>
Message-ID: <20001026120308.B14742@ludwig.cnri.reston.va.us>

On 24 October 2000, Barry A. Warsaw said:
> All well and good and doable in Python today, except getting the
> current frame with the exception raising trick is slooow.  A simple
> proposed addition to the sys module can improve the performance by
> about 8x:
> 
>     def _(s):
>         frame = sys.getcaller(1)
> 	d = frame.f_globals.copy()
> 	d.update(frame.f_locals())
> 	return the_translation_of(s) % d
> 
> The implementation of sys.getcaller() is given in the below patch.
> Comments?  I think this particular addition is too small for a PEP,
> although ?!ng still owns PEP 215 (which needs filling in).

+1.  Not sure if I would call that function 'getcaller()' or
'getframe()'; could go either way.

In my implementation of this (I guess everyone has one!), I also have a
couple of convenience functions:

  def get_caller_env (level=1):
      """get_caller_env(level : int = 1) -> (globals : dict, locals : dict)

      Return the environment of a caller: its dictionaries of global and
      local variables.  'level' has same meaning as for 'caller()'.
      """

  def get_frame_info (frame):
      """get_frame_info(frame)
         -> (filename : string,
             lineno : int,
             function_name : string,
             code_line : string)

      Extracts and returns a tuple of handy information from an execution
      frame.
      """

  def get_caller_info (level=1):
      """get_caller_info(level : int = 1)
         -> (filename : string,
             lineno : int,
             function_name : string,
             code_line : string)

      Extracts and returns a tuple of handy information from some caller's
      execution frame.  'level' is the same as for 'caller()', i.e.  if
      level is 1 (the default), gets this information about the caller of
      the function that is calling 'get_caller_info()'.
      """

These are mainly used by my unit-testing framework (which you'll no
doubt remember, Barry) to report where test failures originate.  Very
handy!

Looks like Ping's inspect.py has something like my 'get_frame_info()',
only it's called 'getframe()'.  Obviously this is the wrong name if
Barry's new function gets added as 'sys.getframe()'.  How 'bout this:

  sys.getframe(n)
    - return stack frame for depth 'n'
  inspect.getframeinfo(frame)
    - return (filename, line number, function name, lines-of-code)

Although I haven't grokked Ping's module enough to know if that rename
really fits his scheme.

        Greg
-- 
Greg Ward - software developer                gward at mems-exchange.org
MEMS Exchange / CNRI                           voice: +1-703-262-5376
Reston, Virginia, USA                            fax: +1-703-262-5367



From jon+sourceforge at unequivocal.co.uk  Thu Oct 26 18:57:01 2000
From: jon+sourceforge at unequivocal.co.uk (Jon Ribbens)
Date: Thu, 26 Oct 2000 17:57:01 +0100
Subject: [Python-Dev] Re: [Bug #117070] README instructions for configuring Setup are not helpful
In-Reply-To: <200010261442.JAA05046@cj20424-a.reston1.va.home.com>; from guido@python.org on Thu, Oct 26, 2000 at 09:42:40AM -0500
References: <200010251752.KAA02444@sf-web2.i.sourceforge.net> <20001025222406.A8389@snowy.squish.net> <14839.45989.450533.514732@cj42289-a.reston1.va.home.com> <200010261145.GAA04767@cj20424-a.reston1.va.home.com> <20001026120127.B11873@snowy.squish.net> <200010261442.JAA05046@cj20424-a.reston1.va.home.com>
Message-ID: <20001026175701.A4983@snowy.squish.net>

Guido van Rossum <guido at python.org> wrote:
> One thing -- it's perfectly fine to edit Setup after running Make for
> the first time.  You just have to run Make again.  The Makefiles are
> designed for this.

Mention this too ;-)



From fdrake at acm.org  Thu Oct 26 19:24:54 2000
From: fdrake at acm.org (Fred L. Drake, Jr.)
Date: Thu, 26 Oct 2000 13:24:54 -0400 (EDT)
Subject: [Python-Dev] Setup changes are checked in
Message-ID: <14840.26854.546598.565061@cj42289-a.reston1.va.home.com>

  I've checked in the changes to the handling of the Modules/Setup
file as we've discussed here.

  - Setup.in is now Setup.dist
  - Setup is created by configure
  - README and other instructions, comments, and documentation has
    been updated to reflect these changes


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at acm.org>
PythonLabs Team Member




From fdrake at acm.org  Thu Oct 26 19:30:22 2000
From: fdrake at acm.org (Fred L. Drake, Jr.)
Date: Thu, 26 Oct 2000 13:30:22 -0400 (EDT)
Subject: [Python-Dev] development version of docs online
Message-ID: <14840.27182.548970.193402@cj42289-a.reston1.va.home.com>

  Do people want to be notified when the development copy of the
documentation is update?  There was a comment from someone that they
didn't know where the online copy was.  I can send the update notice
to python-dev instead of just to myself if everyone wants it, or I can
send it to some other (appropriate) list.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at acm.org>
PythonLabs Team Member




From trentm at ActiveState.com  Thu Oct 26 19:42:30 2000
From: trentm at ActiveState.com (Trent Mick)
Date: Thu, 26 Oct 2000 10:42:30 -0700
Subject: [Python-Dev] development version of docs online
In-Reply-To: <14840.27182.548970.193402@cj42289-a.reston1.va.home.com>; from fdrake@acm.org on Thu, Oct 26, 2000 at 01:30:22PM -0400
References: <14840.27182.548970.193402@cj42289-a.reston1.va.home.com>
Message-ID: <20001026104230.B23283@ActiveState.com>

On Thu, Oct 26, 2000 at 01:30:22PM -0400, Fred L. Drake, Jr. wrote:
> 
>   Do people want to be notified when the development copy of the
> documentation is update?  There was a comment from someone that they

Yes, please.

Trent


-- 
Trent Mick
TrentM at ActiveState.com



From jim at interet.com  Thu Oct 26 21:34:03 2000
From: jim at interet.com (James C. Ahlstrom)
Date: Thu, 26 Oct 2000 15:34:03 -0400
Subject: [Python-Dev] What to choose to replace Tkinter?
References: <14837.14407.954185.466011@buffalo.fnal.gov> <ECEPKNMJLHAPFFJHDOJBKEKIDOAA.MarkH@ActiveState.com> <14837.43273.24692.93965@buffalo.fnal.gov> <20001024114326.E13957@kronos.cnri.reston.va.us>              <39F6B8B8.E3242929@interet.com> <200010251225.HAA22242@cj20424-a.reston1.va.home.com> <39F839BF.DD1B86BF@interet.com> <002a01c03f5f$71ca72f0$3c6340d5@hagrid>
Message-ID: <39F8872B.92D69403@interet.com>

Fredrik Lundh wrote:
> 
> jim wrote:
> > Sorry to be such an old fuddy-duddy, but you will
> > get the same reaction from most commercial software
> > vendors.  Make that nearly ALL vendors.
> 
> what reaction?
> 
> are you saying that your own installer can install the
> Python DLL but not the Tk DLL?

Not exactly.  I am saying I don't want to use the standard
Python Windows installer.  And I am saying I don't want to install
Tk because it is big, complicated, and requires Tcl and its libraries.

My installer does install the Python DLL python15.dll, so
I guess I could study how to install Tk and duplicate the
functionality of the Windows installer, and install Tk too.
But why would I want to?

JimA



From jim at interet.com  Thu Oct 26 21:38:40 2000
From: jim at interet.com (James C. Ahlstrom)
Date: Thu, 26 Oct 2000 15:38:40 -0400
Subject: [Python-Dev] What to choose to replace Tkinter?
References: <Pine.LNX.4.10.10010241146450.6622-100000@akbar.nevex.com> <200010241739.MAA16414@cj20424-a.reston1.va.home.com> <39F6BA29.3CAB4C0E@interet.com> <200010251227.HAA22256@cj20424-a.reston1.va.home.com> <39F83A4A.26E543A3@interet.com> <20001026101850.A14742@ludwig.cnri.reston.va.us>
Message-ID: <39F88840.3F619707@interet.com>

Greg Ward wrote:

> This is generally considered Bad Form by usability types.  I think it
> boils down to this: the computer is not the real world, and trying to
> emulate the real world on the computer is cutesy but a dead end.

I agree up to a point, and my own app doesn't use doors.

But kids like this kind of design, have no trouble
understanding it, and people wouldn't write this if
they didn't think it would sell.

I just meant that people have a larger tolerance for
non-Microsoft GUI design ideas than I thought up to now.

JimA



From skip at mojam.com  Thu Oct 26 22:10:33 2000
From: skip at mojam.com (Skip Montanaro)
Date: Thu, 26 Oct 2000 15:10:33 -0500 (CDT)
Subject: [Python-Dev] A possible bit for a README or FAQ?
Message-ID: <14840.36793.19348.903534@beluga.mojam.com>

Just came across this error while running configure:

    checking for gcc... gcc
    checking whether the C compiler (gcc   ) works... no
    configure: error: installation or configuration problem: C compiler cannot create executables.

The problem was that /tmp was full - sort of.  The system says there's no
space: 

    % cat /etc/termcap > /tmp/termcap
    bash: /tmp/termcap: No space left on device

but df disagrees:

    % df /tmp
    Filesystem           1k-blocks      Used Available Use% Mounted on
    /dev/hda5               153667     88796     56935  61% /

Short term workaround is to run configure with TMPDIR set somewhere else.
Perhaps this is something to put in a gcc-specific or Unix-specific section
of the README file.  I didn't see anything, and the message emitted by
configure gave no hint at the cause of the problem.  I realized what it was
because I've been scratching my head about this problem for a couple weeks.

If this is deemed useful I'll modify README and check it in.  If not, no big
deal.

(I have no idea why the system thinks /tmp is full... sigh ...)

Skip



From cgw at fnal.gov  Thu Oct 26 22:14:53 2000
From: cgw at fnal.gov (Charles G Waldman)
Date: Thu, 26 Oct 2000 15:14:53 -0500 (CDT)
Subject: [Python-Dev] A possible bit for a README or FAQ?
In-Reply-To: <14840.36793.19348.903534@beluga.mojam.com>
References: <14840.36793.19348.903534@beluga.mojam.com>
Message-ID: <14840.37053.829696.379140@buffalo.fnal.gov>

Skip Montanaro writes:
 > 
 > Just came across this error while running configure:
 > 
 >     checking for gcc... gcc
 >     checking whether the C compiler (gcc   ) works... no
 >     configure: error: installation or configuration problem: C compiler cannot create executables.

 > If this is deemed useful I'll modify README and check it in.  If not, no big
 > deal.

Personally,  I don't think this is useful.  I don't think the Python
README is the place to list everything that can go wrong during
./configure.

The generic advice is "If something goes wrong during ./configure, 
read through config.log to see what went wrong"

I'm curious what is in your config.log when this error occurs!



From nas at arctrix.com  Thu Oct 26 15:29:49 2000
From: nas at arctrix.com (Neil Schemenauer)
Date: Thu, 26 Oct 2000 06:29:49 -0700
Subject: [Python-Dev] A possible bit for a README or FAQ?
In-Reply-To: <14840.36793.19348.903534@beluga.mojam.com>; from skip@mojam.com on Thu, Oct 26, 2000 at 03:10:33PM -0500
References: <14840.36793.19348.903534@beluga.mojam.com>
Message-ID: <20001026062949.A14618@glacier.fnational.com>

> The problem was that /tmp was full - sort of.

You might try "df -i".  You could be out inodes but still have
blocks.

  Neil



From guido at python.org  Thu Oct 26 23:29:33 2000
From: guido at python.org (Guido van Rossum)
Date: Thu, 26 Oct 2000 16:29:33 -0500
Subject: [Python-Dev] Gradual migration PEP
In-Reply-To: Your message of "Thu, 26 Oct 2000 07:28:12 MST."
             <39F83F7C.2241158F@prescod.net> 
References: <39F83F7C.2241158F@prescod.net> 
Message-ID: <200010262129.QAA14206@cj20424-a.reston1.va.home.com>

Paul,

Your deprecation PEP looks good.  A few comments:

- I think that the one-year period may depend on the feature.  Some
may require an even longer time.  Others less.

- I think there will be cases where run-time checks are the only way
to detect use of the old feature (e.g. I'm still struggling with how
to change the division semantics).

But this shouldn't stop it from becoming a PEP.

Please arrange for a PEP number with Barry, the PEPmaster.

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



From thomas at xs4all.net  Fri Oct 27 00:58:41 2000
From: thomas at xs4all.net (Thomas Wouters)
Date: Fri, 27 Oct 2000 00:58:41 +0200
Subject: [Python-Dev] A possible bit for a README or FAQ?
In-Reply-To: <20001026062949.A14618@glacier.fnational.com>; from nas@arctrix.com on Thu, Oct 26, 2000 at 06:29:49AM -0700
References: <14840.36793.19348.903534@beluga.mojam.com> <20001026062949.A14618@glacier.fnational.com>
Message-ID: <20001027005841.R12812@xs4all.nl>

On Thu, Oct 26, 2000 at 06:29:49AM -0700, Neil Schemenauer wrote:
> > The problem was that /tmp was full - sort of.

> You might try "df -i".  You could be out inodes but still have
> blocks.

Or failing that, it could be out of 'indirect' or 'doubly-indirect' blocks,
or some other filesystem resource. Not often the case for something like
/tmp, but definately possible on some filesystems.

-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!



From thomas at xs4all.net  Fri Oct 27 01:02:24 2000
From: thomas at xs4all.net (Thomas Wouters)
Date: Fri, 27 Oct 2000 01:02:24 +0200
Subject: [Python-Dev] A possible bit for a README or FAQ?
In-Reply-To: <14840.36793.19348.903534@beluga.mojam.com>; from skip@mojam.com on Thu, Oct 26, 2000 at 03:10:33PM -0500
References: <14840.36793.19348.903534@beluga.mojam.com>
Message-ID: <20001027010224.S12812@xs4all.nl>

On Thu, Oct 26, 2000 at 03:10:33PM -0500, Skip Montanaro wrote:

> Short term workaround is to run configure with TMPDIR set somewhere else.
> Perhaps this is something to put in a gcc-specific or Unix-specific section
> of the README file.  I didn't see anything, and the message emitted by
> configure gave no hint at the cause of the problem.  I realized what it was
> because I've been scratching my head about this problem for a couple weeks.

> If this is deemed useful I'll modify README and check it in.  If not, no big
> deal.

If you start adding things like that, also consider all the other
possibilities of configure being wrong. I hinted at one of them a couple of
weeks back, I think. (Somehow, 'last saturday', when I headed for London for
the Apachecon, feels like about two months ago :P) It's perfectly possible
for configure to be able to run gcc, gcc to be able to create working
binaries, but every check for a function or datatype failing because the
more 'involved' include files are missing. This is easy to do on Linux,
(removing /usr/src/linux, for instance) but not impossible on other systems
either.

-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!



From greg at cosc.canterbury.ac.nz  Fri Oct 27 02:21:26 2000
From: greg at cosc.canterbury.ac.nz (Greg Ewing)
Date: Fri, 27 Oct 2000 13:21:26 +1300 (NZDT)
Subject: [Python-Dev] A possible bit for a README or FAQ?
In-Reply-To: <20001027005841.R12812@xs4all.nl>
Message-ID: <200010270021.NAA28528@s454.cosc.canterbury.ac.nz>

Thomas Wouters <thomas at xs4all.net>:

> Or failing that, it could be out of 'indirect' or 'doubly-indirect'
> blocks,

I think they're allocated from the same pool as data blocks.

What *can* happen is that you can run out of "large" blocks.  The
BSD-style filesystem stores files bigger than 8k in blocks made up of
8 contiguous 1k blocks. If the filesystem is nearly full, or contains
a large number of small files, you can find that it's impossible to
create any more files > 8k, even though there appears to be plenty of
free space, because the space is too fragmented.

I don't think that's what's happening here, though, since I've
only ever seen it happen when the filesystem was about 99% full.

Greg Ewing, Computer Science Dept, +--------------------------------------+
University of Canterbury,	   | A citizen of NewZealandCorp, a	  |
Christchurch, New Zealand	   | wholly-owned subsidiary of USA Inc.  |
greg at cosc.canterbury.ac.nz	   +--------------------------------------+



From tim_one at email.msn.com  Fri Oct 27 03:13:02 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Thu, 26 Oct 2000 21:13:02 -0400
Subject: [Python-Dev] What to choose to replace Tkinter?
In-Reply-To: <39F8872B.92D69403@interet.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCEECGHNAA.tim_one@email.msn.com>

[Guido]
> are you saying that your own installer can install the
> Python DLL but not the Tk DLL?

[James Ahlstrom]
> Not exactly.  I am saying I don't want to use the standard
> Python Windows installer.  And I am saying I don't want to install
> Tk because it is big, complicated, and requires Tcl and its libraries.
>
> My installer does install the Python DLL python15.dll, so
> I guess I could study how to install Tk and duplicate the
> functionality of the Windows installer, and install Tk too.
> But why would I want to?

That's up to you and your customers.  What Guido has been telling you is
that what the Windows installer does now (as of 1.6) to "install" Tcl/Tk is
trivial:  it merely copies some Tcl/Tk files into the Python installation
tree.  It no longer runs the Scriptics installer, mucks with the path,
changes any envars, copies any files to outside of the Python tree, or even
sets anything up in the registry for Tcl/Tk.  You may not *want* to install
Tcl/Tk, but, if you would like to, there's no longer any basis for fearing
it's difficult, obscure, delicate or error-prone.

don't-know-about-those-wrt-other-gui-pkgs-ly y'rs  - tim





From skip at mojam.com  Fri Oct 27 05:54:51 2000
From: skip at mojam.com (Skip Montanaro)
Date: Thu, 26 Oct 2000 22:54:51 -0500 (CDT)
Subject: [Python-Dev] A possible bit for a README or FAQ?
In-Reply-To: <14840.37053.829696.379140@buffalo.fnal.gov>
References: <14840.36793.19348.903534@beluga.mojam.com>
	<14840.37053.829696.379140@buffalo.fnal.gov>
Message-ID: <14840.64651.444849.757658@beluga.mojam.com>

    Charles> The generic advice is "If something goes wrong during
    Charles> ./configure, read through config.log to see what went wrong"

Agreed.

    Charles> I'm curious what is in your config.log when this error occurs!

That's why I was thinking ("hmmm... perhaps a README bit").  It wasn't
giving me obvious "no space" messages.

I've concluded that it's probably best to forget it anyway.  If it's a
problem with configure or gcc messages, it's best addressed there.

Skip




From skip at mojam.com  Fri Oct 27 05:57:00 2000
From: skip at mojam.com (Skip Montanaro)
Date: Thu, 26 Oct 2000 22:57:00 -0500 (CDT)
Subject: [Python-Dev] A possible bit for a README or FAQ?
In-Reply-To: <20001026062949.A14618@glacier.fnational.com>
References: <14840.36793.19348.903534@beluga.mojam.com>
	<20001026062949.A14618@glacier.fnational.com>
Message-ID: <14840.64780.673428.672300@beluga.mojam.com>

    Neil> You might try "df -i".  You could be out inodes but still have
    Neil> blocks.

Thanks, that indeed seems to be the problem:

    % df -i /tmp
    Filesystem            Inodes   IUsed   IFree IUse% Mounted on
    /dev/hda5                39k     39k       7  100% /

I don't believe in all my years of fiddling with Unix systems I've ever run
out of inodes with a third of the disk space left.  Now to identify the
culprit.

Skip




From mal at lemburg.com  Fri Oct 27 12:15:53 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Fri, 27 Oct 2000 12:15:53 +0200
Subject: [Python-Dev] Starship is still down...
Message-ID: <39F955D9.279864FD@lemburg.com>

It's been over a week since I posted my last gripe about
our community server starship being unreachable. Nothing has
happened so far... is there any chance on getting the server
up and running again ?

I am a bit concerned about the lack of support here: starship
should be considered a very important part in the Python
universe (after all, many Python extension packages and goodies
are available from that site). With the frequent downtimes
we recently had, I think people will get a wrong picture about
the Python community support.

Here's a traceroute from Germany to starship:
traceroute to starship.python.net (208.185.174.112), 30 hops max, 40 byte packets
 1  193.158.137.129 (193.158.137.129)  24 ms  23 ms  23 ms
 2  193.158.137.130 (193.158.137.130)  24 ms  35 ms  25 ms
 3  D-gw13.D.net.DTAG.DE (212.185.10.22)  67 ms  24 ms  35 ms
 4  K-gw13.K.net.DTAG.DE (194.25.124.137)  26 ms  25 ms  25 ms
 5  F-gw13.F.net.DTAG.DE (194.25.121.101)  32 ms  33 ms  33 ms
 6  TysonsC-gw12.USA.net.DTAG.DE (194.25.6.98)  113 ms  127 ms  131 ms
 7  TysonsC-gw1.USA.net.DTAG.DE (194.25.6.113)  115 ms  117 ms  134 ms
 8  mae-east-switch0.maee.above.net (208.184.210.9)  134 ms  114 ms  123 ms
 9  core1-mae-east-oc3-1.iad.above.net (209.133.31.225)  122 ms  116 ms  115 ms
10  sjc2-iad-oc48.sjc2.above.net (216.200.127.26)  184 ms  186 ms  185 ms
11  core5-core3-oc48.sjc2.above.net (208.185.156.66)  183 ms  184 ms  186 ms
12  sjc2-gige-main1.colo6.sjc2.above.net (208.185.156.37)  299 ms  183 ms !H  188 ms !H
13  * * *
14  * * *
...

It looks as if ABOVE.NET is having some serious routing problems.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From tim_one at email.msn.com  Fri Oct 27 12:43:22 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Fri, 27 Oct 2000 06:43:22 -0400
Subject: [Python-Dev] Starship is still down...
In-Reply-To: <39F955D9.279864FD@lemburg.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCAEDHHNAA.tim_one@email.msn.com>

[MAL]
> It's been over a week since I posted my last gripe about
> our community server starship being unreachable.

Afraid Manus Head still gets the Most Outraged award for this one.

> Nothing has happened so far... is there any chance on getting the server
> up and running again ?

Works for me, but only very recently.  OTOH, my posts to python.org mailing
lists started black-holing, so it's not like Python-Dev will actually see
this post <wink>.  Here's a trace from my box (in Virginia); it may take a
while for recent routing changes to propagate:

  1   tnt32.tco2.da.uu.net [206.115.222.61]
  2   GigabitEthernet4-0.DR4.TCO2.Alter.Net [206.115.243.2]
  3   156.at-3-0-0.HR4.DCA1.ALTER.NET [152.63.34.50]
  4   517.ATM1-0.XR2.DCA1.ALTER.NET [152.63.36.198]
  5   294.at-7-1-0.XR2.DCA8.ALTER.NET [146.188.163.26]
  6   POS7-0.BR4.DCA8.ALTER.NET [152.63.36.25]
  7   137.39.52.102
  8   beth1br2-ge-1-0-0-0.md.us.prserv.net [165.87.29.139]
  9   sfra1br1-so-2-1-0-0.ca.us.prserv.net [165.87.233.42]
 10   sfra1sr3-ge-0-3-0-0.ca.us.prserv.net [165.87.33.139]
 11   pacbellpsfoc3.ca.us.prserv.net [165.87.161.5]
 12   core3-g2-0.snfc21.pbi.net [209.232.130.78]
 13   rback26-fe2-0.snfc21.pbi.net [216.102.187.153]
 14   adsl-63-202-160-65.dsl.snfc21.pacbell.net [63.202.160.65]
 15   starship.python.net [63.202.160.91]

> I am a bit concerned about the lack of support here: starship
> should be considered a very important part in the Python
> universe (after all, many Python extension packages and goodies
> are available from that site). With the frequent downtimes
> we recently had, I think people will get a wrong picture about
> the Python community support.

They're getting an accurate view of current Starship support.  So it goes.
Plans for better support *are* in progress, but for reasons that won't
become clear until later, you haven't heard anything about them yet.

for-that-matter-i'm-not-entirely-sure-i-have-either-ly y'rs  - tim





From jim at interet.com  Fri Oct 27 14:23:11 2000
From: jim at interet.com (James C. Ahlstrom)
Date: Fri, 27 Oct 2000 08:23:11 -0400
Subject: [Python-Dev] What to choose to replace Tkinter?
References: <LNBBLJKPBEHFEDALKOLCEECGHNAA.tim_one@email.msn.com>
Message-ID: <39F973AF.80D3BDBE@interet.com>

Tim Peters wrote:

> That's up to you and your customers.  What Guido has been telling you is
> that what the Windows installer does now (as of 1.6) to "install" Tcl/Tk is
> trivial:  it merely copies some Tcl/Tk files into the Python installation
> tree.  It no longer runs the Scriptics installer, mucks with the path,

Oh, OK.  That is much better.

JimA



From skip at mojam.com  Fri Oct 27 18:15:55 2000
From: skip at mojam.com (Skip Montanaro)
Date: Fri, 27 Oct 2000 11:15:55 -0500 (CDT)
Subject: [Python-Dev] Starship is still down...
In-Reply-To: <LNBBLJKPBEHFEDALKOLCAEDHHNAA.tim_one@email.msn.com>
References: <39F955D9.279864FD@lemburg.com>
	<LNBBLJKPBEHFEDALKOLCAEDHHNAA.tim_one@email.msn.com>
Message-ID: <14841.43579.261191.986406@beluga.mojam.com>

    Tim> Here's a trace from my box (in Virginia); ...

Tim's trace doesn't show times.  Looks to me like Pacbell is having trouble
(note the huge leap in response time):

    ...
    13  beth1sr3-so-5-1-3-0.md.us.prserv.net (165.87.99.50)  30.387 ms  27.426 ms  28.392 ms
    14  beth1br2-ge-1-0-0-0.md.us.prserv.net (165.87.29.139)  27.614 ms  27.349 ms  27.250 ms
    15  sfra1br1-so-2-1-0-0.ca.us.prserv.net (165.87.233.42)  71.581 ms  72.535 ms  72.429 ms
    16  sfra1sr3-ge-0-3-0-0.ca.us.prserv.net (165.87.33.139)  71.635 ms  71.420 ms  71.483 ms
    17  pacbellpsfoc3.ca.us.prserv.net (165.87.161.5)  71.070 ms  71.606 ms  71.301 ms
    18  core4-g2-0.snfc21.pbi.net (209.232.130.77)  70.986 ms  71.129 ms  73.628 ms
    19  rback26-fe2-0.snfc21.pbi.net (216.102.187.153)  72.696 ms  77.658 ms  83.046 ms
    20  adsl-63-202-160-65.dsl.snfc21.pacbell.net (63.202.160.65)  3841.343 ms  3705.648 ms  3911.584 ms
    21  adsl-63-202-160-91.dsl.snfc21.pacbell.net (63.202.160.91)  3683.340 ms  3867.550 ms  3653.732 ms

Skip



From petrilli at amber.org  Fri Oct 27 22:15:18 2000
From: petrilli at amber.org (Christopher Petrilli)
Date: Fri, 27 Oct 2000 16:15:18 -0400
Subject: GUI-Discussion; MacOS vs. MacOS X (was Re: [Python-Dev] Miscellaneous comments on Tkinter and related...)
In-Reply-To: <m13oTwr-000Dm8C@artcom0.artcom-gmbh.de>; from pf@artcom-gmbh.de on Wed, Oct 25, 2000 at 07:02:45PM +0200
References: <14838.64730.225260.148853@buffalo.fnal.gov> <m13oTwr-000Dm8C@artcom0.artcom-gmbh.de>
Message-ID: <20001027161518.B3942@trump.amber.org>

Peter Funk [pf at artcom-gmbh.de] wrote:
> 
> It will take years, before MacOS X will find its way onto the desk
> of the average Apple Mac user.  The Mac s mostly used in the graphics 
> and printing industry (our cutsomers) where people normally don't 
> even think about a OS upgrade, if they don't have to.  They usually
> run a mix of Photoshop, Quark XPRess, Artwork, illustrator or other 
> so called creative software on the version of the OS they had on 
> the machine when they bought it.  THese machines are usually used
> through a period of at least four years.

I think this is a bit incorrect.  Almost every Mac user that I
interact with (including all the users hre at Digital Creations) have
OS X running and using it at various levels.  Mostly it's waiting for
people like Adobe to release Carbon applications.  

Graphics designers will be the first to move to OS X, not thel ast, as 
they will ge the most fromt he increased stability and performance. It 
all depends on your market.

The best goal for Mac OS would be to aim at full Carbon compliance,
and not write to Cocoa, or to the original MacOS toolkit.  This would
let you run on all releases after 8.0 I believe (maybe even 7.6).

Chris
-- 
| Christopher Petrilli
| petrilli at amber.org



From guido at python.org  Sat Oct 28 03:42:42 2000
From: guido at python.org (Guido van Rossum)
Date: Fri, 27 Oct 2000 20:42:42 -0500
Subject: [Python-Dev] PythonLabs Team Moves to Digital Creations
Message-ID: <200010280142.UAA05020@cj20424-a.reston1.va.home.com>

To all Python users and developers:

Less than half a year ago, I moved with my team to BeOpen.com, in the
hope of finding a new permanent home for Python development.  At
BeOpen, we've done several good things for Python, such as moving the
Python and Jython development process to SourceForge, and the
successful release of Python 2.0.

Unfortunately, BeOpen.com's original plans for PythonLabs didn't work
out as hoped, and we weren't able to reach mutual agreement on
workable alternative plans -- despite trying for months.

I am proud to have found a new home for my entire team: starting
today, Tim Peters, Barry Warsaw, Jeremy Hylton, Fred Drake and myself
are working for Digital Creations.  We will be spending part of our
time on core Python development (including Jython and Mailman) and
part of our time on Python infrastructure improvements that also
benefit Zope.

Python will remain Open Source; Digital Creations has no desire to
monetize or brand the Python language or specific Python
distributions.  All future work we do on Python as Digital Creations
employees will be owned by a non-profit organization yet to be
created.  We think of this new organization as the Python Software
Foundation.  In the meantime (while the PSF is under construction) I
will own such copyrights personally.

We're excited to be working for Digital Creations: they are one of the
oldest companies active in the Python community, one of the companies
most committed to Python, and they have a great product!  Plus, we
know they have deep financial backing.  We trust that Digital
Creations will provide a stable home for Python for many years.

Digital Creations has also offered to take over hosting of the
python.org and starship sites.  On behalf of the Python community,
we're grateful for this support of the two prime community sites for
Python, and we expect to be implementing the transitions shortly.

These are exciting times for the PythonLabs team -- and also for
Python and its community.  Mainstream successes for Python are showing
up everywhere, and we're proud to be a part of such a smart and
friendly community.  A great year lies ahead!

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



From jim at digicool.com  Sat Oct 28 04:45:02 2000
From: jim at digicool.com (Jim Fulton)
Date: Fri, 27 Oct 2000 22:45:02 -0400
Subject: [Python-Dev] Re: PythonLabs Team Moves to Digital Creations
References: <mailman.972693760.7272.python-list@python.org>
Message-ID: <39FA3DAE.ADB2C8B1@digicool.com>

Guido van Rossum wrote:
> 
(snip)
> I am proud to have found a new home for my entire team: starting
> today, Tim Peters, Barry Warsaw, Jeremy Hylton, Fred Drake and myself
> are working for Digital Creations.  We will be spending part of our
> time on core Python development (including Jython and Mailman) and
> part of our time on Python infrastructure improvements that also
> benefit Zope.

Needless to say (but I'll say it anyway), Digital Creations is
proud and thrilled that the this team has joined us. 

These are indeed exciting times! 

Jim

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



From martin at loewis.home.cs.tu-berlin.de  Sat Oct 28 12:14:00 2000
From: martin at loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Sat, 28 Oct 2000 12:14:00 +0200
Subject: [Python-Dev] getting at the current frame
Message-ID: <200010281014.MAA01045@loewis.home.cs.tu-berlin.de>

> which actually will look something like this in real code:
>
>    def trade(yours, mine):
>        print _('if you give me %(yours)s, i will give you %(mine)s') % {
>            'yours': yours,
>            'mine' : mine,
>            }
>
> The string wrapped in _() is what gets translated here.
>
> Okay, we all know that's a pain, right?

What's wrong with

    def trade(yours, mine):
        print _('if you give me %(yours)s, i will give you %(mine)s') % vars()

Look Ma, no magic!

Regards,
Martin



From effbot at telia.com  Sat Oct 28 12:43:05 2000
From: effbot at telia.com (Fredrik Lundh)
Date: Sat, 28 Oct 2000 12:43:05 +0200
Subject: [Python-Dev] Re: [Python-checkins] SourceForge problems
References: <14839.26627.968974.44752@cj42289-a.reston1.va.home.com>
Message-ID: <012e01c040cb$dc501b30$3c6340d5@hagrid>

fred wrote:
>   At any rate, there has been activity in the source tree; you just
> might want to do a CVS update to see what's changed.  There have been
> a number of bug fixes, a fair number of documentation updates, and
> many of the modules in the standard library have been passed through
> Tim Peter's reindent.py script (look in Tools/scripts/).

now that this has been done, emacs users might want to
add something like the following to their local configuration
(based on code by jwz, so it should work...)

:::

(defun python-mode-untabify ()
  (save-excursion
    (goto-char (point-min))
    (while (re-search-forward "[ \t]+$" nil t)
      (delete-region (match-beginning 0) (match-end 0)))
    (goto-char (point-min))
    (if (search-forward "\t" nil t)
        (untabify (1- (point)) (point-max))))
  nil)
 (add-hook 'python-mode-hook 
          '(lambda ()
             (make-local-variable 'write-contents-hooks)
             (add-hook 'write-contents-hooks 'python-mode-untabify)))

</F>




From martin at loewis.home.cs.tu-berlin.de  Sat Oct 28 12:51:20 2000
From: martin at loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Sat, 28 Oct 2000 12:51:20 +0200
Subject: [Python-Dev] build problems under Solaris
Message-ID: <200010281051.MAA01290@loewis.home.cs.tu-berlin.de>

> I don't have access to a Solaris machine, so I can't do anything to
> help these users.

The patch in 117606 looks right to me: gcc on Solaris (and on any
other platform) needs -shared to build shared library; configure
currently passes -G. I haven't actually tried the patch, since it is a
pain to extract it from the SF bug report page. What happens is that
gcc passes -G to the linker, which correctly produces a shared
library.  However, gcc also links crt1/crti into the library, which
causes the reference to main.

117508 looks like a user error to me. On its own, configure would not
try to link -ldb, unless it detects the presence of db.h. My guess is
that there is a libdb in /usr/local, so a gcc configure finds it,
whereas the native compiler doesn't. Later, the linker even finds a
-ldb library, but somehow this doesn't have dbopen. So it could be
that the BSDDB installation on that system is screwed.

Regards,
Martin




From barry at scottb.demon.co.uk  Sat Oct 28 13:14:45 2000
From: barry at scottb.demon.co.uk (Barry Scott)
Date: Sat, 28 Oct 2000 12:14:45 +0100
Subject: [Python-Dev] Gradual migration
In-Reply-To: <39F82C97.12D04C85@lemburg.com>
Message-ID: <000601c040d0$474ce1d0$060210ac@private>

> > We could make integrating C++ and Python easier through CXX or Py_Cpp.
> > Perhaps we should ship one of those with Python 2.1. Anyhow, integrating
> > C++ and Python is not really so hard, in my experience.

	Integrating C++ and Python well is hard in a general library.

	CXX tries to make objects that look and feel like Python objects.
	But to do that we have to figure out the details of how python uses
	objects. You have no docs on the subject so we read the source code.

		Barry
		CXX maintainer




From barry at scottb.demon.co.uk  Sat Oct 28 13:23:50 2000
From: barry at scottb.demon.co.uk (Barry Scott)
Date: Sat, 28 Oct 2000 12:23:50 +0100
Subject: [Python-Dev] Gradual migration
In-Reply-To: <39F80C30.5448.52D32F94@localhost>
Message-ID: <000701c040d1$8beecf00$060210ac@private>

[Gordon wrote]
> All of the existing C++ interfaces / helpers deal only with type 
> objects (at least, those that I've examined, which is most of 
> them). In fact, only ExtensionClass attempts to deal with the 
> class / type split, and while it's a masterpiece, I think it's a 
> great example of everything to avoid in Py3K.

	Py_Cpp support C++ classes you can derived from in Python.
	Once I get my head around the proxy interface I'll try and
	add that to CXX. CXX today allows you to create C++ class
	that you can use from Python, but not derive from.

		Barry
		CXX maintainer





From moshez at math.huji.ac.il  Sun Oct 29 08:59:11 2000
From: moshez at math.huji.ac.il (Moshe Zadka)
Date: Sun, 29 Oct 2000 09:59:11 +0200 (IST)
Subject: [Python-Dev] development version of docs online
In-Reply-To: <14840.27182.548970.193402@cj42289-a.reston1.va.home.com>
Message-ID: <Pine.GSO.4.10.10010290956420.7911-100000@sundial>

On Thu, 26 Oct 2000, Fred L. Drake, Jr. wrote:

>   Do people want to be notified when the development copy of the
> documentation is update?  There was a comment from someone that they
> didn't know where the online copy was.  I can send the update notice
> to python-dev instead of just to myself if everyone wants it, or I can
> send it to some other (appropriate) list.

I'm for Python-Dev + doc-sig (I'm shooting myself in the foot, cause that
means I'm getting it twice. My foot is used to being shot at though)
--
Moshe Zadka <moshez at math.huji.ac.il> -- 95855124
http://advogato.org/person/moshez




From barry at wooz.org  Mon Oct 30 17:14:53 2000
From: barry at wooz.org (barry at wooz.org)
Date: Mon, 30 Oct 2000 11:14:53 -0500 (EST)
Subject: [Python-Dev] Re: getting at the current frame
References: <200010281014.MAA01045@loewis.home.cs.tu-berlin.de>
Message-ID: <14845.40573.917058.905009@anthem.concentric.net>

>>>>> "MvL" == Martin v Loewis <martin at loewis.home.cs.tu-berlin.de> writes:

    MvL> What's wrong with

    MvL>     def trade(yours, mine): print _('if you give me
    MvL> %(yours)s, i will give you %(mine)s') % vars()

    MvL> Look Ma, no magic!

Except that I also want globals() to be included and vars() doesn't
include that.  I really want:

    d = globals().copy()
    d.update(locals())

but I've also noticed that you sometimes want attribute following so
you can do things like

    _('the name of the list is %(mlist.listname)')

-Barry



From barry at wooz.org  Mon Oct 30 18:35:25 2000
From: barry at wooz.org (Barry A. Warsaw)
Date: Mon, 30 Oct 2000 12:35:25 -0500 (EST)
Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Python ceval.c,2.212,2.213
References: <200010301715.JAA32564@slayer.i.sourceforge.net>
Message-ID: <14845.45405.867829.722598@anthem.concentric.net>

Well, it looks like checkin messages are flowing again.  Yay!



From mal at lemburg.com  Mon Oct 30 18:54:50 2000
From: mal at lemburg.com (M.-A. Lemburg)
Date: Mon, 30 Oct 2000 18:54:50 +0100
Subject: [Python-Dev] Re: Python Call Mechanism ([Python-checkins] CVS: python/dist/src/Python
 ceval.c,2.212,2.213)
References: <200010301715.JAA32564@slayer.i.sourceforge.net>
Message-ID: <39FDB5EA.B60EA39A@lemburg.com>

Jeremy Hylton wrote:
> 
> Update of /cvsroot/python/python/dist/src/Python
> In directory slayer.i.sourceforge.net:/tmp/cvs-serv32349/Python
> 
> Modified Files:
>         ceval.c
> ...
> N.B. The CALL_FUNCTION implementation is getting really hairy; should
> review it to see if it can be simplified.

How about a complete redesign of the whole call mechanism ?!

I have an old patch somewhere which reorganizes the Python
calling mechanism into something more sane than what we
have in ceval.c now.

Should I try to find it for someone to use as basis for the
reorg (don't have time for this myself) ?

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From jeremy at alum.mit.edu  Mon Oct 30 15:59:00 2000
From: jeremy at alum.mit.edu (Jeremy Hylton)
Date: Mon, 30 Oct 2000 09:59:00 -0500 (EST)
Subject: [Python-Dev] Re: Python Call Mechanism ([Python-checkins] CVS: python/dist/src/Python
 ceval.c,2.212,2.213)
In-Reply-To: <39FDB5EA.B60EA39A@lemburg.com>
References: <200010301715.JAA32564@slayer.i.sourceforge.net>
	<39FDB5EA.B60EA39A@lemburg.com>
Message-ID: <14845.36020.17063.951147@bitdiddle.concentric.net>

>>>>> "MAL" == M -A Lemburg <mal at lemburg.com> writes:

  MAL> Jeremy Hylton wrote:
  >>
  >> Update of /cvsroot/python/python/dist/src/Python In directory
  >> slayer.i.sourceforge.net:/tmp/cvs-serv32349/Python
  >>
  >> Modified Files: ceval.c ...  N.B. The CALL_FUNCTION
  >> implementation is getting really hairy; should review it to see
  >> if it can be simplified.

  MAL> How about a complete redesign of the whole call mechanism ?!

  MAL> I have an old patch somewhere which reorganizes the Python
  MAL> calling mechanism into something more sane than what we have in
  MAL> ceval.c now.

  MAL> Should I try to find it for someone to use as basis for the
  MAL> reorg (don't have time for this myself) ?

I'd be interested in looking at it.

Jeremy



From tim_one at email.msn.com  Mon Oct 30 20:36:55 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Mon, 30 Oct 2000 14:36:55 -0500
Subject: [Python-Dev] New test_extcall fails on Windows -- elsewhere?  Expected?  Bug?
Message-ID: <LNBBLJKPBEHFEDALKOLCIEKPHNAA.tim_one@email.msn.com>

C:\Code\python\dist\src\PCbuild>python ../lib/test/regrtest.py test_extcall

test_extcall
test test_extcall failed -- Writing: '3', expected: ''
1 test failed: test_extcall

C:\Code\python\dist\src\PCbuild>python ../lib/test/regrtest.py -v
test_extcall

test_extcall
test_extcall
() {}
(1,) {}
(1, 2) {}
(1, 2, 3) {}
(1, 2, 3, 4, 5) {}
(1, 2, 3, 4, 5) {}
(1, 2, 3, 4, 5) {}
(1, 2, 3) {'b': 5, 'a': 4}
(1, 2, 3, 4, 5) {'b': 7, 'a': 6}
(1, 2, 3, 6, 7) {'y': 5, 'b': 9, 'x': 4, 'a': 8}
TypeError: not enough arguments to g(); expected 1, got 0
TypeError: not enough arguments to g(); expected 1, got 0
TypeError: not enough arguments to g(); expected 1, got 0
1 () {}
1 (2,) {}
1 (2, 3) {}
1 (2, 3, 4, 5) {}
0 (1, 2) {}
1 () {'d': 4, 'b': 2, 'c': 3, 'a': 1}
{'b': 2, 'c': 3, 'a': 1}
{'b': 2, 'c': 3, 'a': 1}
keyword parameter 'x' redefined in call to g()
keyword parameter 'b' redefined in function call
keywords must be strings
h() got an unexpected keyword argument 'e'
* argument must be a sequence
** argument must be a dictionary
3 512 1
3
3
unbound method must be called with instance as first argument
unbound method must be called with instance as first argument
1 test OK.





From fdrake at acm.org  Mon Oct 30 21:38:09 2000
From: fdrake at acm.org (Fred L. Drake, Jr.)
Date: Mon, 30 Oct 2000 15:38:09 -0500 (EST)
Subject: [Python-Dev] New test_extcall fails on Windows -- elsewhere?  Expected?  Bug?
In-Reply-To: <LNBBLJKPBEHFEDALKOLCIEKPHNAA.tim_one@email.msn.com>
References: <LNBBLJKPBEHFEDALKOLCIEKPHNAA.tim_one@email.msn.com>
Message-ID: <14845.56369.361598.655506@cj42289-a.reston1.va.home.com>

Tim Peters writes:
 > C:\Code\python\dist\src\PCbuild>python ../lib/test/regrtest.py test_extcall
 > 
 > test_extcall
 > test test_extcall failed -- Writing: '3', expected: ''
 > 1 test failed: test_extcall

  I get the same thing on Linux.  The output appears identical to what
Tim got.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at acm.org>
PythonLabs at Digital Creations




From jeremy at alum.mit.edu  Mon Oct 30 17:48:08 2000
From: jeremy at alum.mit.edu (Jeremy Hylton)
Date: Mon, 30 Oct 2000 11:48:08 -0500 (EST)
Subject: [Python-Dev] New test_extcall fails on Windows -- elsewhere?  Expected?  Bug?
In-Reply-To: <LNBBLJKPBEHFEDALKOLCIEKPHNAA.tim_one@email.msn.com>
References: <LNBBLJKPBEHFEDALKOLCIEKPHNAA.tim_one@email.msn.com>
Message-ID: <14845.42568.358062.805095@bitdiddle.concentric.net>

This output matches the output file I just checked in under
Lib/test/output/test_extcall.  Looks like I failed to check in this
change.

Jeremy



From tim_one at email.msn.com  Mon Oct 30 20:54:14 2000
From: tim_one at email.msn.com (Tim Peters)
Date: Mon, 30 Oct 2000 14:54:14 -0500
Subject: [Python-Dev] New test_extcall fails on Windows -- elsewhere?  Expected?  Bug?
In-Reply-To: <14845.42568.358062.805095@bitdiddle.concentric.net>
Message-ID: <LNBBLJKPBEHFEDALKOLCMELAHNAA.tim_one@email.msn.com>

[Jeremy]
> This output matches the output file I just checked in under
> Lib/test/output/test_extcall.  Looks like I failed to check in this
> change.

Thank you -- works on Windows now.  It should work on Linux too, if Linux
knows what's good for it <wink>.





From fdrake at acm.org  Mon Oct 30 21:56:13 2000
From: fdrake at acm.org (Fred L. Drake, Jr.)
Date: Mon, 30 Oct 2000 15:56:13 -0500 (EST)
Subject: [Python-Dev] New test_extcall fails on Windows -- elsewhere?  Expected?  Bug?
In-Reply-To: <LNBBLJKPBEHFEDALKOLCMELAHNAA.tim_one@email.msn.com>
References: <14845.42568.358062.805095@bitdiddle.concentric.net>
	<LNBBLJKPBEHFEDALKOLCMELAHNAA.tim_one@email.msn.com>
Message-ID: <14845.57453.54059.671795@cj42289-a.reston1.va.home.com>

Tim Peters writes:
 > Thank you -- works on Windows now.  It should work on Linux too, if Linux
 > knows what's good for it <wink>.

  It does.  ;)


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at acm.org>
PythonLabs at Digital Creations