From noreply@sourceforge.net  Tue May  1 22:24:59 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 01 May 2001 14:24:59 -0700
Subject: [Patches] [ python-Patches-420565 ] makes setup.py search sys.prefix
Message-ID: <E14uhdj-0000aC-00@usw-sf-web2.sourceforge.net>

Patches item #420565, was updated on 2001-05-01 14:24
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=420565&group_id=5470

Category: Build
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: makes setup.py search sys.prefix 

Initial Comment:
It's useful to have setup.py search the lib and include
directories in sys.prefix before it checks /usr/local.
That way, if you are building Python into a custom
location and want it to use the the libraries installed
there rather than the system defaults, you can give the
--prefix option to configure and setup.py will search
that path first.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=420565&group_id=5470


From noreply@sourceforge.net  Wed May  2 15:35:14 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 02 May 2001 07:35:14 -0700
Subject: [Patches] [ python-Patches-402364 ] Fix for119822:  Allow Unicode in urllib
Message-ID: <E14uxik-0002UA-00@usw-sf-web3.sourceforge.net>

Patches item #402364, was updated on 2000-11-12 03:06
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=402364&group_id=5470

Category: library
Group: None
Status: Closed
Resolution: None
Priority: 5
Submitted By: Martin v. Löwis (loewis)
Assigned to: Martin v. Löwis (loewis)
Summary: Fix for119822:  Allow Unicode in urllib

Initial Comment:
 

----------------------------------------------------------------------

Comment By: Walter Dörwald (doerwalter)
Date: 2001-05-02 07:35

Message:
Logged In: YES 
user_id=89016

http://www.w3.org/TR/html4/appendix/notes.html#h-B.2
states the following:

"""
Although URIs do not contain non-ASCII values authors 
sometimes specify them in attribute values expecting URIs 
(i.e., defined with %URI; in the DTD). For instance, the 
following href value is illegal:

<A href="http://foo.org/Håkon">...</A>

We recommend that user agents adopt the following 
convention for handling non-ASCII characters in such cases:

1. Represent each character in UTF-8 (see [RFC2279]) as one 
or more bytes. 
2. Escape these bytes with the URI escaping mechanism 
(i.e., by converting each byte to %HH, where HH is the 
hexadecimal notation of the byte value). 

This procedure results in a syntactically legal URI (as 
defined in [RFC1738], section 2.2 or [RFC2141], section 2) 
that is independent of the character encoding to which the 
HTML document carrying the URI may have been transcoded.
"""


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2000-12-03 10:31

Message:
Committed as urllib.py 1.108.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-11-13 11:55

Message:
Looks good.  Suggestion: maybe another name than 'toASCII()', since this may change to something else later? How about to8bit()?

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2000-11-13 00:41

Message:
Looking at http://www.ietf.org/ids.by.wg/idn.html, there is hardly any consensus on how to do internationalized domain names.

As for Unicode in URLs, there is not even an Internet Draft proposing usage of UTF-8. So I'd propose to follow established standards, until drafts for new standards come available.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2000-11-12 05:11

Message:
There are movements which want to add UTF-8 support to URLs.
I don't know if there already are RTFs on this, but since even
MS Explorer supports this, I guess the movement must be strong ;-)

It does seem to be the natural coice and DNS is moving in that
direction too.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2000-11-12 03:09

Message:
This fixes the bug by explicitly converting Unicode strings to ASCII. I could find no indication in the RFCs that anything but ASCII is allowed in URLs.

The size of the patch primarily originates from the renaming of the type local variable to urltype, so that the builtin type function is available.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=402364&group_id=5470


From noreply@sourceforge.net  Wed May  2 17:21:35 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 02 May 2001 09:21:35 -0700
Subject: [Patches] [ python-Patches-420753 ] Patch for bug #420725 urllib MIME header
Message-ID: <E14uzNf-0007L1-00@usw-sf-web2.sourceforge.net>

Patches item #420753, was updated on 2001-05-02 09:21
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=420753&group_id=5470

Category: library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Walter Dörwald (doerwalter)
Assigned to: Nobody/Anonymous (nobody)
Summary: Patch for bug #420725 urllib MIME header

Initial Comment:
Fixes the bug #420725.

One open issue is what to do when the script doesn't 
have permission to call os.stat on the file.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=420753&group_id=5470


From noreply@sourceforge.net  Fri May  4 02:29:43 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 03 May 2001 18:29:43 -0700
Subject: [Patches] [ python-Patches-421214 ] splitlist() for raw and unicode strings
Message-ID: <E14vUPf-0004rk-00@usw-sf-web3.sourceforge.net>

Patches item #421214, was updated on 2001-05-03 18:29
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=421214&group_id=5470

Category: core (C code)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Gustavo Niemeyer (niemeyer)
Assigned to: Nobody/Anonymous (nobody)
Summary: splitlist() for raw and unicode strings

Initial Comment:
This patch implements a feature that I wanted for a
long time in
python. It implements the splitlist() method for normal
and unicode strings.

This allows one to do something like:

"one, two and three".splitlist([",", "and"])

and get:

["one", " two ", "three"]


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=421214&group_id=5470


From noreply@sourceforge.net  Fri May  4 08:54:13 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 04 May 2001 00:54:13 -0700
Subject: [Patches] [ python-Patches-421214 ] splitlist() for raw and unicode strings
Message-ID: <E14vaPl-0003E6-00@usw-sf-web1.sourceforge.net>

Patches item #421214, was updated on 2001-05-03 18:29
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=421214&group_id=5470

Category: core (C code)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Gustavo Niemeyer (niemeyer)
>Assigned to: M.-A. Lemburg (lemburg)
Summary: splitlist() for raw and unicode strings

Initial Comment:
This patch implements a feature that I wanted for a
long time in
python. It implements the splitlist() method for normal
and unicode strings.

This allows one to do something like:

"one, two and three".splitlist([",", "and"])

and get:

["one", " two ", "three"]


----------------------------------------------------------------------

>Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-04 00:54

Message:
Logged In: YES 
user_id=38388

I like this idea, but will have to check with the code bloat
police first.

BTW, I'd rename .splitlist() to .tokenize() since that's
what the method is really about (it is very similiar to C's
strtok()).

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=421214&group_id=5470


From noreply@sourceforge.net  Fri May  4 14:53:43 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 04 May 2001 06:53:43 -0700
Subject: [Patches] [ python-Patches-421214 ] splitlist() for raw and unicode strings
Message-ID: <E14vg1f-0006qk-00@usw-sf-web3.sourceforge.net>

Patches item #421214, was updated on 2001-05-03 18:29
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=421214&group_id=5470

Category: core (C code)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Gustavo Niemeyer (niemeyer)
Assigned to: M.-A. Lemburg (lemburg)
Summary: splitlist() for raw and unicode strings

Initial Comment:
This patch implements a feature that I wanted for a
long time in
python. It implements the splitlist() method for normal
and unicode strings.

This allows one to do something like:

"one, two and three".splitlist([",", "and"])

and get:

["one", " two ", "three"]


----------------------------------------------------------------------

>Comment By: Gustavo Niemeyer (niemeyer)
Date: 2001-05-04 06:53

Message:
Logged In: YES 
user_id=7887

Ok. Thanks.

About the method name, I'm just trying to follow the naming
convention already there. There are methods named split(),
splitlines(). I thought
splitlist() would be a good "brother".


----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-04 00:54

Message:
Logged In: YES 
user_id=38388

I like this idea, but will have to check with the code bloat
police first.

BTW, I'd rename .splitlist() to .tokenize() since that's
what the method is really about (it is very similiar to C's
strtok()).

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=421214&group_id=5470


From noreply@sourceforge.net  Fri May  4 19:41:56 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 04 May 2001 11:41:56 -0700
Subject: [Patches] [ python-Patches-421214 ] splitlist() for raw and unicode strings
Message-ID: <E14vkWa-0005Sb-00@usw-sf-web1.sourceforge.net>

Patches item #421214, was updated on 2001-05-03 18:29
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=421214&group_id=5470

Category: core (C code)
Group: None
>Status: Closed
>Resolution: Rejected
Priority: 5
Submitted By: Gustavo Niemeyer (niemeyer)
Assigned to: M.-A. Lemburg (lemburg)
Summary: splitlist() for raw and unicode strings

Initial Comment:
This patch implements a feature that I wanted for a
long time in
python. It implements the splitlist() method for normal
and unicode strings.

This allows one to do something like:

"one, two and three".splitlist([",", "and"])

and get:

["one", " two ", "three"]


----------------------------------------------------------------------

>Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-04 11:41

Message:
Logged In: YES 
user_id=38388

Sorry, but the resonance I got from python-dev is too
negative to check this patch in.

Here's the alternative code which pretty much does the same
thing using a function (by Fredrik Lundh):

def tokenize(string, seps):
    return re.split("|".join(map(re.escape, seps)), string)

The good news is that you will probably be able to subclass
strings in one of the next releases (perhaps even Python
2.2).

----------------------------------------------------------------------

Comment By: Gustavo Niemeyer (niemeyer)
Date: 2001-05-04 06:53

Message:
Logged In: YES 
user_id=7887

Ok. Thanks.

About the method name, I'm just trying to follow the naming
convention already there. There are methods named split(),
splitlines(). I thought
splitlist() would be a good "brother".


----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-04 00:54

Message:
Logged In: YES 
user_id=38388

I like this idea, but will have to check with the code bloat
police first.

BTW, I'd rename .splitlist() to .tokenize() since that's
what the method is really about (it is very similiar to C's
strtok()).

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=421214&group_id=5470


From noreply@sourceforge.net  Fri May  4 20:23:49 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 04 May 2001 12:23:49 -0700
Subject: [Patches] [ python-Patches-421214 ] splitlist() for raw and unicode strings
Message-ID: <E14vlB7-0006BZ-00@usw-sf-web1.sourceforge.net>

Patches item #421214, was updated on 2001-05-03 18:29
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=421214&group_id=5470

Category: core (C code)
Group: None
Status: Closed
Resolution: Rejected
Priority: 5
Submitted By: Gustavo Niemeyer (niemeyer)
Assigned to: M.-A. Lemburg (lemburg)
Summary: splitlist() for raw and unicode strings

Initial Comment:
This patch implements a feature that I wanted for a
long time in
python. It implements the splitlist() method for normal
and unicode strings.

This allows one to do something like:

"one, two and three".splitlist([",", "and"])

and get:

["one", " two ", "three"]


----------------------------------------------------------------------

>Comment By: Gustavo Niemeyer (niemeyer)
Date: 2001-05-04 12:23

Message:
Logged In: YES 
user_id=7887

Yes, I knew this could be done... but this is *many* times
slower than splitlist(). A small code doesn't mean a fast
code (especially in a high
level language). Btw, what splitlines()'s doing there? ;-)

Anyway... you know what's best for the language.

Thanks!

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-04 11:41

Message:
Logged In: YES 
user_id=38388

Sorry, but the resonance I got from python-dev is too
negative to check this patch in.

Here's the alternative code which pretty much does the same
thing using a function (by Fredrik Lundh):

def tokenize(string, seps):
    return re.split("|".join(map(re.escape, seps)), string)

The good news is that you will probably be able to subclass
strings in one of the next releases (perhaps even Python
2.2).

----------------------------------------------------------------------

Comment By: Gustavo Niemeyer (niemeyer)
Date: 2001-05-04 06:53

Message:
Logged In: YES 
user_id=7887

Ok. Thanks.

About the method name, I'm just trying to follow the naming
convention already there. There are methods named split(),
splitlines(). I thought
splitlist() would be a good "brother".


----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-04 00:54

Message:
Logged In: YES 
user_id=38388

I like this idea, but will have to check with the code bloat
police first.

BTW, I'd rename .splitlist() to .tokenize() since that's
what the method is really about (it is very similiar to C's
strtok()).

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=421214&group_id=5470


From noreply@sourceforge.net  Sat May  5 21:30:27 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 05 May 2001 13:30:27 -0700
Subject: [Patches] [ python-Patches-421709 ] Access { thread id : frame } dict
Message-ID: <E14w8h9-0003X4-00@usw-sf-web3.sourceforge.net>

Patches item #421709, was updated on 2001-05-05 13:30
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=421709&group_id=5470

Category: core (C code)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: John D. Heintz (jheintz)
Assigned to: Nobody/Anonymous (nobody)
Summary: Access { thread id : frame } dict

Initial Comment:
This patch adds a new function sys._getframes() that 
returns a dictionary mapping from thread id to 
current frame object.

This is very useful when diagnosing deadlock issues 
in Python code.

The new C code function is purely additive except for 
modifying the PyThreadState struct (adding a long 
thread_ident) and modifying PyThreadState_New() 
function to set this new long.



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=421709&group_id=5470


From noreply@sourceforge.net  Sun May  6 22:42:32 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 06 May 2001 14:42:32 -0700
Subject: [Patches] [ python-Patches-421893 ] Cleanup GC API
Message-ID: <E14wWIS-0004ny-00@usw-sf-web3.sourceforge.net>

Patches item #421893, was updated on 2001-05-06 14:42
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=421893&group_id=5470

Category: core (C code)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Neil Schemenauer (nascheme)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Cleanup GC API

Initial Comment:
This patch adds three new APIs:

	PyObject_GC_New
	PyObject_GC_NewVar
	PyObject_GC_Resize
	PyObject_GC_Del

and renames PyObject_GC_Init and PyObject_GC_Fini to:

	PyObject_GC_Track
	PyObject_GC_Ignore

respectively.  Objects that wish to be tracked by the
collector must use these new APIs.  Many more details
about the GC implementation are hidden inside
gcmodule.c.  There seems to be no change in
performance.

Note that PyObject_GC_{New,NewVar} automatically adds
the object to the GC lists.  There is no need to
call PyObject_GC_Track.  PyObject_GC_Del automatically
removes the object from the GC list but usually you
want to call PyObject_GC_Ignore yourself (DECREFs can
end up running arbitrary code).

It should be more difficult to corrupt the GC linked
lists now.  Also, you can now call PyObject_GC_Ignore
on objects that you know will not create RCs. The
_weakref module does this.  Previously, every object
that had the GC type flag set and could be found by
using tp_traverse had to be in a GC linked list.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=421893&group_id=5470


From noreply@sourceforge.net  Mon May  7 04:10:23 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 06 May 2001 20:10:23 -0700
Subject: [Patches] [ python-Patches-421922 ] Restrict dict comparison to Py_EQ
Message-ID: <E14wbPj-0007RE-00@usw-sf-web1.sourceforge.net>

Patches item #421922, was updated on 2001-05-06 20:10
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=421922&group_id=5470

Category: core (C code)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Guido van Rossum (gvanrossum)
Summary: Restrict dict comparison to Py_EQ

Initial Comment:
Dict comparison currently requires that the keys and 
values enjoy a total ordering, but dicts only require 
Py_EQ in other contexts.  The patch changes dict 
compares to rely on just Py_EQ too, and replaces the 
cmp()-like calls with comparison of raw object 
addresses.  Besides yielding a huge speedup on an 
artificial test case <wink>, it stops surprises like 
these:

>>> {1: 1j} == {1: 2j}
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: cannot compare complex numbers using <, <=, 
>, >=
>>> {1j: 0} == {2j: 0}
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: cannot compare complex numbers using <, <=, 
>, >=
>>>

After the patch:

>>> {1: 1j} == {1: 2j}
0
>>> {1j: 0} == {2j: 0}
0
>>> cmp({1: 1j}, {1: 1j})
0
>>> cmp({1j: 0}, {1j: 0})
0
>>>


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=421922&group_id=5470


From noreply@sourceforge.net  Mon May  7 14:17:30 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 07 May 2001 06:17:30 -0700
Subject: [Patches] [ python-Patches-421922 ] Restrict dict comparison to Py_EQ
Message-ID: <E14wktG-0007fb-00@usw-sf-web2.sourceforge.net>

Patches item #421922, was updated on 2001-05-06 20:10
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=421922&group_id=5470

Category: core (C code)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Guido van Rossum (gvanrossum)
Summary: Restrict dict comparison to Py_EQ

Initial Comment:
Dict comparison currently requires that the keys and 
values enjoy a total ordering, but dicts only require 
Py_EQ in other contexts.  The patch changes dict 
compares to rely on just Py_EQ too, and replaces the 
cmp()-like calls with comparison of raw object 
addresses.  Besides yielding a huge speedup on an 
artificial test case <wink>, it stops surprises like 
these:

>>> {1: 1j} == {1: 2j}
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: cannot compare complex numbers using <, <=, 
>, >=
>>> {1j: 0} == {2j: 0}
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: cannot compare complex numbers using <, <=, 
>, >=
>>>

After the patch:

>>> {1: 1j} == {1: 2j}
0
>>> {1j: 0} == {2j: 0}
0
>>> cmp({1: 1j}, {1: 1j})
0
>>> cmp({1j: 0}, {1j: 0})
0
>>>


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-05-07 06:17

Message:
Logged In: YES 
user_id=6380

I have one question about this.  Will the comparison between
dicts using cmp() or <, <=, >, >= also depend on the raw
object address?  That would mean that (even in one program)
there could be two pairs of dictionaries (A,B) and (C,D)
where A<B and C>D while A==C and B==D.  I'm not sure I like
that.

What's the real use case where this matters?  (Either the
speed of == comparisons or the ability to ==-compare dicts
containing complex numbers.)

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=421922&group_id=5470


From noreply@sourceforge.net  Mon May  7 19:26:22 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 07 May 2001 11:26:22 -0700
Subject: [Patches] [ python-Patches-421922 ] Restrict dict comparison to Py_EQ
Message-ID: <E14wpiA-0003ew-00@usw-sf-web2.sourceforge.net>

Patches item #421922, was updated on 2001-05-06 20:10
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=421922&group_id=5470

Category: core (C code)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Guido van Rossum (gvanrossum)
Summary: Restrict dict comparison to Py_EQ

Initial Comment:
Dict comparison currently requires that the keys and 
values enjoy a total ordering, but dicts only require 
Py_EQ in other contexts.  The patch changes dict 
compares to rely on just Py_EQ too, and replaces the 
cmp()-like calls with comparison of raw object 
addresses.  Besides yielding a huge speedup on an 
artificial test case <wink>, it stops surprises like 
these:

>>> {1: 1j} == {1: 2j}
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: cannot compare complex numbers using <, <=, 
>, >=
>>> {1j: 0} == {2j: 0}
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: cannot compare complex numbers using <, <=, 
>, >=
>>>

After the patch:

>>> {1: 1j} == {1: 2j}
0
>>> {1j: 0} == {2j: 0}
0
>>> cmp({1: 1j}, {1: 1j})
0
>>> cmp({1j: 0}, {1j: 0})
0
>>>


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-05-07 11:26

Message:
Logged In: YES 
user_id=31435

Ya, this patch is dead.

WRT A<B and C>D while A==C and B==D, yes, I'm afraid that's 
possible, and that sucks bigtime.  The underlying problem 
is that I see no practical way to extend an equality 
relation (given by Py_EQ) to a total ordering.  For 
example, if "==" is determined by Py_EQ, and "<" by address 
comparison, then (forget dicts here for the moment) we can 
construct A, B1 and B2 s.t.

A < B1 == B2 < A

Then using those as keys and/or values in dicts can lead to 
inconsistent dict comparisons too (with this patch applied).

I had three use cases in mind:

1. Speed (in)equality testing.  A note Greg Wilson sent 
earlier this year reminded me that this is an important 
operation for sets (which he's implementing on top of 
dicts).

2. Ensure that (in)equality testing of dicts doesn't blow 
up just because the keys and/or values support only a 
partial ordering, or only (in)equality testing (complex 
numbers are just an extreme case of this).

3. Support sorting a list of dicts without blowing up, 
again if the keys and/or values support only a partial 
ordering.

I've given up on #3.  #1 and #2 could be accomplished by 
implementing the tp_richcompare slot for dicts instead:  if 
I know up-front that "equal: yes or no?" is the only 
outcome of interest, then a different, simpler and faster 
algorithm using only Py_EQ on keys and values would suffice.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-05-07 06:17

Message:
Logged In: YES 
user_id=6380

I have one question about this.  Will the comparison between
dicts using cmp() or <, <=, >, >= also depend on the raw
object address?  That would mean that (even in one program)
there could be two pairs of dictionaries (A,B) and (C,D)
where A<B and C>D while A==C and B==D.  I'm not sure I like
that.

What's the real use case where this matters?  (Either the
speed of == comparisons or the ability to ==-compare dicts
containing complex numbers.)

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=421922&group_id=5470


From noreply@sourceforge.net  Mon May  7 19:27:11 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 07 May 2001 11:27:11 -0700
Subject: [Patches] [ python-Patches-421922 ] Restrict dict comparison to Py_EQ
Message-ID: <E14wpix-0003fX-00@usw-sf-web2.sourceforge.net>

Patches item #421922, was updated on 2001-05-06 20:10
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=421922&group_id=5470

Category: core (C code)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Peters (tim_one)
>Assigned to: Tim Peters (tim_one)
Summary: Restrict dict comparison to Py_EQ

Initial Comment:
Dict comparison currently requires that the keys and 
values enjoy a total ordering, but dicts only require 
Py_EQ in other contexts.  The patch changes dict 
compares to rely on just Py_EQ too, and replaces the 
cmp()-like calls with comparison of raw object 
addresses.  Besides yielding a huge speedup on an 
artificial test case <wink>, it stops surprises like 
these:

>>> {1: 1j} == {1: 2j}
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: cannot compare complex numbers using <, <=, 
>, >=
>>> {1j: 0} == {2j: 0}
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: cannot compare complex numbers using <, <=, 
>, >=
>>>

After the patch:

>>> {1: 1j} == {1: 2j}
0
>>> {1j: 0} == {2j: 0}
0
>>> cmp({1: 1j}, {1: 1j})
0
>>> cmp({1j: 0}, {1j: 0})
0
>>>


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-05-07 11:27

Message:
Logged In: YES 
user_id=31435

Assigned back to me.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-07 11:26

Message:
Logged In: YES 
user_id=31435

Ya, this patch is dead.

WRT A<B and C>D while A==C and B==D, yes, I'm afraid that's 
possible, and that sucks bigtime.  The underlying problem 
is that I see no practical way to extend an equality 
relation (given by Py_EQ) to a total ordering.  For 
example, if "==" is determined by Py_EQ, and "<" by address 
comparison, then (forget dicts here for the moment) we can 
construct A, B1 and B2 s.t.

A < B1 == B2 < A

Then using those as keys and/or values in dicts can lead to 
inconsistent dict comparisons too (with this patch applied).

I had three use cases in mind:

1. Speed (in)equality testing.  A note Greg Wilson sent 
earlier this year reminded me that this is an important 
operation for sets (which he's implementing on top of 
dicts).

2. Ensure that (in)equality testing of dicts doesn't blow 
up just because the keys and/or values support only a 
partial ordering, or only (in)equality testing (complex 
numbers are just an extreme case of this).

3. Support sorting a list of dicts without blowing up, 
again if the keys and/or values support only a partial 
ordering.

I've given up on #3.  #1 and #2 could be accomplished by 
implementing the tp_richcompare slot for dicts instead:  if 
I know up-front that "equal: yes or no?" is the only 
outcome of interest, then a different, simpler and faster 
algorithm using only Py_EQ on keys and values would suffice.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-05-07 06:17

Message:
Logged In: YES 
user_id=6380

I have one question about this.  Will the comparison between
dicts using cmp() or <, <=, >, >= also depend on the raw
object address?  That would mean that (even in one program)
there could be two pairs of dictionaries (A,B) and (C,D)
where A<B and C>D while A==C and B==D.  I'm not sure I like
that.

What's the real use case where this matters?  (Either the
speed of == comparisons or the ability to ==-compare dicts
containing complex numbers.)

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=421922&group_id=5470


From noreply@sourceforge.net  Mon May  7 21:07:42 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 07 May 2001 13:07:42 -0700
Subject: [Patches] [ python-Patches-422106 ] Seg fault in sys.displayhook
Message-ID: <E14wrIE-00051F-00@usw-sf-web2.sourceforge.net>

Patches item #422106, was updated on 2001-05-07 13:07
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=422106&group_id=5470

Category: core (C code)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Gregory H. Ball (greg_ball)
Assigned to: Nobody/Anonymous (nobody)
Summary: Seg fault in sys.displayhook

Initial Comment:
If you do a very silly thing and delete the
"__builtin__" entry
from sys.modules, the default displayhook is defeated.
This problem exists in 2.1 and current CVS, but not 2.0
(The old display loop held a reference to the builtin
module instead of repeatedly fetching it in 2.0, I
guess.)


My patch just checks whether the module is in the
expected location and raises an exception instead of
dumping core.
The error message is not especially illuminating, but
then,
anyone who actually does this deserves far worse ;-)



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=422106&group_id=5470


From noreply@sourceforge.net  Mon May  7 21:10:12 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 07 May 2001 13:10:12 -0700
Subject: [Patches] [ python-Patches-422106 ] Seg fault in sys.displayhook
Message-ID: <E14wrKe-00053O-00@usw-sf-web2.sourceforge.net>

Patches item #422106, was updated on 2001-05-07 13:07
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=422106&group_id=5470

Category: core (C code)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Gregory H. Ball (greg_ball)
Assigned to: Nobody/Anonymous (nobody)
Summary: Seg fault in sys.displayhook

Initial Comment:
If you do a very silly thing and delete the
"__builtin__" entry
from sys.modules, the default displayhook is defeated.
This problem exists in 2.1 and current CVS, but not 2.0
(The old display loop held a reference to the builtin
module instead of repeatedly fetching it in 2.0, I
guess.)


My patch just checks whether the module is in the
expected location and raises an exception instead of
dumping core.
The error message is not especially illuminating, but
then,
anyone who actually does this deserves far worse ;-)



----------------------------------------------------------------------

>Comment By: Gregory H. Ball (greg_ball)
Date: 2001-05-07 13:10

Message:
Logged In: YES 
user_id=11365

The problem:

Python 2.2a0 (#13, May  7 2001, 15:45:00) 
[GCC 2.95.3 19991030 (prerelease)] on linux2
Type "copyright", "credits" or "license" for more
information.
>>> import sys
>>> del sys.modules['__builtin__']
>>> 1
Segmentation fault (core dumped)

The solution:

Python 2.2a0 (#16, May  7 2001, 16:03:33) 
[GCC 2.95.3 19991030 (prerelease)] on linux2
Type "copyright", "credits" or "license" for more
information.
>>> import sys
>>> del sys.modules['__builtin__']
>>> 1
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
RuntimeError: lost __builtin__
>>> 


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=422106&group_id=5470


From noreply@sourceforge.net  Mon May  7 21:40:48 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 07 May 2001 13:40:48 -0700
Subject: [Patches] [ python-Patches-421922 ] Implement rich comparison for dicts
Message-ID: <E14wroG-0005T5-00@usw-sf-web2.sourceforge.net>

Patches item #421922, was updated on 2001-05-06 20:10
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=421922&group_id=5470

Category: core (C code)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Tim Peters (tim_one)
>Summary: Implement rich comparison for dicts

Initial Comment:
Dict comparison currently requires that the keys and 
values enjoy a total ordering, but dicts only require 
Py_EQ in other contexts.  The patch changes dict 
compares to rely on just Py_EQ too, and replaces the 
cmp()-like calls with comparison of raw object 
addresses.  Besides yielding a huge speedup on an 
artificial test case <wink>, it stops surprises like 
these:

>>> {1: 1j} == {1: 2j}
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: cannot compare complex numbers using <, <=, 
>, >=
>>> {1j: 0} == {2j: 0}
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: cannot compare complex numbers using <, <=, 
>, >=
>>>

After the patch:

>>> {1: 1j} == {1: 2j}
0
>>> {1j: 0} == {2j: 0}
0
>>> cmp({1: 1j}, {1: 1j})
0
>>> cmp({1j: 0}, {1j: 0})
0
>>>


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-05-07 13:40

Message:
Logged In: YES 
user_id=31435

New patch attached.  As noted in the comment two back, this 
gives up on trying to embed Py_EQ in a total ordering.  
Instead the focii are on making == and != comparison work 
for dicts regardless of whether the keys and values are 
totally ordered, and on speeding == and != dict comparisons 
in any case.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-07 11:27

Message:
Logged In: YES 
user_id=31435

Assigned back to me.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-07 11:26

Message:
Logged In: YES 
user_id=31435

Ya, this patch is dead.

WRT A<B and C>D while A==C and B==D, yes, I'm afraid that's 
possible, and that sucks bigtime.  The underlying problem 
is that I see no practical way to extend an equality 
relation (given by Py_EQ) to a total ordering.  For 
example, if "==" is determined by Py_EQ, and "<" by address 
comparison, then (forget dicts here for the moment) we can 
construct A, B1 and B2 s.t.

A < B1 == B2 < A

Then using those as keys and/or values in dicts can lead to 
inconsistent dict comparisons too (with this patch applied).

I had three use cases in mind:

1. Speed (in)equality testing.  A note Greg Wilson sent 
earlier this year reminded me that this is an important 
operation for sets (which he's implementing on top of 
dicts).

2. Ensure that (in)equality testing of dicts doesn't blow 
up just because the keys and/or values support only a 
partial ordering, or only (in)equality testing (complex 
numbers are just an extreme case of this).

3. Support sorting a list of dicts without blowing up, 
again if the keys and/or values support only a partial 
ordering.

I've given up on #3.  #1 and #2 could be accomplished by 
implementing the tp_richcompare slot for dicts instead:  if 
I know up-front that "equal: yes or no?" is the only 
outcome of interest, then a different, simpler and faster 
algorithm using only Py_EQ on keys and values would suffice.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-05-07 06:17

Message:
Logged In: YES 
user_id=6380

I have one question about this.  Will the comparison between
dicts using cmp() or <, <=, >, >= also depend on the raw
object address?  That would mean that (even in one program)
there could be two pairs of dictionaries (A,B) and (C,D)
where A<B and C>D while A==C and B==D.  I'm not sure I like
that.

What's the real use case where this matters?  (Either the
speed of == comparisons or the ability to ==-compare dicts
containing complex numbers.)

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=421922&group_id=5470


From noreply@sourceforge.net  Mon May  7 21:42:40 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 07 May 2001 13:42:40 -0700
Subject: [Patches] [ python-Patches-421922 ] Implement rich comparison for dicts
Message-ID: <E14wrq4-0005Ui-00@usw-sf-web2.sourceforge.net>

Patches item #421922, was updated on 2001-05-06 20:10
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=421922&group_id=5470

Category: core (C code)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Peters (tim_one)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: Implement rich comparison for dicts

Initial Comment:
Dict comparison currently requires that the keys and 
values enjoy a total ordering, but dicts only require 
Py_EQ in other contexts.  The patch changes dict 
compares to rely on just Py_EQ too, and replaces the 
cmp()-like calls with comparison of raw object 
addresses.  Besides yielding a huge speedup on an 
artificial test case <wink>, it stops surprises like 
these:

>>> {1: 1j} == {1: 2j}
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: cannot compare complex numbers using <, <=, 
>, >=
>>> {1j: 0} == {2j: 0}
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: cannot compare complex numbers using <, <=, 
>, >=
>>>

After the patch:

>>> {1: 1j} == {1: 2j}
0
>>> {1j: 0} == {2j: 0}
0
>>> cmp({1: 1j}, {1: 1j})
0
>>> cmp({1j: 0}, {1j: 0})
0
>>>


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-05-07 13:42

Message:
Logged In: YES 
user_id=31435

Back to Guido.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-07 13:40

Message:
Logged In: YES 
user_id=31435

New patch attached.  As noted in the comment two back, this 
gives up on trying to embed Py_EQ in a total ordering.  
Instead the focii are on making == and != comparison work 
for dicts regardless of whether the keys and values are 
totally ordered, and on speeding == and != dict comparisons 
in any case.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-07 11:27

Message:
Logged In: YES 
user_id=31435

Assigned back to me.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-07 11:26

Message:
Logged In: YES 
user_id=31435

Ya, this patch is dead.

WRT A<B and C>D while A==C and B==D, yes, I'm afraid that's 
possible, and that sucks bigtime.  The underlying problem 
is that I see no practical way to extend an equality 
relation (given by Py_EQ) to a total ordering.  For 
example, if "==" is determined by Py_EQ, and "<" by address 
comparison, then (forget dicts here for the moment) we can 
construct A, B1 and B2 s.t.

A < B1 == B2 < A

Then using those as keys and/or values in dicts can lead to 
inconsistent dict comparisons too (with this patch applied).

I had three use cases in mind:

1. Speed (in)equality testing.  A note Greg Wilson sent 
earlier this year reminded me that this is an important 
operation for sets (which he's implementing on top of 
dicts).

2. Ensure that (in)equality testing of dicts doesn't blow 
up just because the keys and/or values support only a 
partial ordering, or only (in)equality testing (complex 
numbers are just an extreme case of this).

3. Support sorting a list of dicts without blowing up, 
again if the keys and/or values support only a partial 
ordering.

I've given up on #3.  #1 and #2 could be accomplished by 
implementing the tp_richcompare slot for dicts instead:  if 
I know up-front that "equal: yes or no?" is the only 
outcome of interest, then a different, simpler and faster 
algorithm using only Py_EQ on keys and values would suffice.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-05-07 06:17

Message:
Logged In: YES 
user_id=6380

I have one question about this.  Will the comparison between
dicts using cmp() or <, <=, >, >= also depend on the raw
object address?  That would mean that (even in one program)
there could be two pairs of dictionaries (A,B) and (C,D)
where A<B and C>D while A==C and B==D.  I'm not sure I like
that.

What's the real use case where this matters?  (Either the
speed of == comparisons or the ability to ==-compare dicts
containing complex numbers.)

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=421922&group_id=5470


From noreply@sourceforge.net  Mon May  7 21:44:55 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 07 May 2001 13:44:55 -0700
Subject: [Patches] [ python-Patches-417081 ] termios modernization
Message-ID: <E14wrsF-0004sX-00@usw-sf-web3.sourceforge.net>

Patches item #417081, was updated on 2001-04-18 08:30
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=417081&group_id=5470

Category: Modules
Group: None
Status: Open
>Resolution: Accepted
Priority: 5
Submitted By: Michael Hudson (mwh)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: termios modernization

Initial Comment:
this patch does several things to termios:

(1) changes all functions to be METH_VARARGS
(2) changes all functions to be able to take a file 
    object as the first parameter, as per 

http://mail.python.org/pipermail/python-dev/2001-February/012701.html

(3) give better error messages
(4) removes a bunch of comments that just repeat the
    docstrings
(5) #includes <termio.h> before #including
    <sys/ioctl.h> so more constants are actually
    #defined.
(6) a couple of docstring tweaks

I have tested this minimally (i.e. it builds, and
doesn't blow up too embarassingly) on OSF1/alpha and
on one of the sf compile farm's solaris boxes, and
rather more comprehansively on my linux/x86 box.

It still needs to be tested on all the other platforms
we build termios on (which is why I didn't do this
last week...)

I still need to do the docs.

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-05-07 13:44

Message:
Logged In: YES 
user_id=3066

Checked in as Modules/termios.c revision 2.25; documentation to be checked in as soon as SF admins clear a stale CVS lock.  This patch will be closed once the doc patch is commited.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2001-04-18 08:35

Message:
Logged In: YES 
user_id=6656

And here's the docs (not much, as it turns out).

Fred likes these, we hear.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=417081&group_id=5470


From noreply@sourceforge.net  Mon May  7 21:45:33 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 07 May 2001 13:45:33 -0700
Subject: [Patches] [ python-Patches-413419 ] termios cleanup
Message-ID: <E14wrsr-0004tL-00@usw-sf-web3.sourceforge.net>

Patches item #413419, was updated on 2001-04-03 07:06
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=413419&group_id=5470

Category: Modules
Group: None
>Status: Closed
>Resolution: Out of Date
Priority: 5
Submitted By: Michael Hudson (mwh)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: termios cleanup

Initial Comment:
If TERMIOS is deprecated, then perhaps it would be best
if the docstrings in termios didn't refer to it!

Also updates termios functions to be METH_VARARGS.

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-05-07 13:45

Message:
Logged In: YES 
user_id=3066

Obsoleted by patch #417081.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2001-04-18 08:00

Message:
Logged In: YES 
user_id=6656

I am about to submit a patch that subsumes this one.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-04-09 12:35

Message:
Logged In: YES 
user_id=3066

The docstring updates have been checked in as Modules/termios.c revision 2.23.  The remaining changes will be considered after the 2.1 release -- since there is not a test suite for this module, we do not want to risk introducing bugs immediately before release.

This will remain open & assigned to me for consideration after the release.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=413419&group_id=5470


From noreply@sourceforge.net  Mon May  7 22:44:53 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 07 May 2001 14:44:53 -0700
Subject: [Patches] [ python-Patches-421922 ] Implement rich comparison for dicts
Message-ID: <E14wsoH-0006Ii-00@usw-sf-web2.sourceforge.net>

Patches item #421922, was updated on 2001-05-06 20:10
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=421922&group_id=5470

Category: core (C code)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Peters (tim_one)
>Assigned to: Tim Peters (tim_one)
Summary: Implement rich comparison for dicts

Initial Comment:
Dict comparison currently requires that the keys and 
values enjoy a total ordering, but dicts only require 
Py_EQ in other contexts.  The patch changes dict 
compares to rely on just Py_EQ too, and replaces the 
cmp()-like calls with comparison of raw object 
addresses.  Besides yielding a huge speedup on an 
artificial test case <wink>, it stops surprises like 
these:

>>> {1: 1j} == {1: 2j}
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: cannot compare complex numbers using <, <=, 
>, >=
>>> {1j: 0} == {2j: 0}
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: cannot compare complex numbers using <, <=, 
>, >=
>>>

After the patch:

>>> {1: 1j} == {1: 2j}
0
>>> {1j: 0} == {2j: 0}
0
>>> cmp({1: 1j}, {1: 1j})
0
>>> cmp({1j: 0}, {1j: 0})
0
>>>


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-05-07 14:44

Message:
Logged In: YES 
user_id=6380

Looks cool to me.  Go for it.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-07 13:42

Message:
Logged In: YES 
user_id=31435

Back to Guido.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-07 13:40

Message:
Logged In: YES 
user_id=31435

New patch attached.  As noted in the comment two back, this 
gives up on trying to embed Py_EQ in a total ordering.  
Instead the focii are on making == and != comparison work 
for dicts regardless of whether the keys and values are 
totally ordered, and on speeding == and != dict comparisons 
in any case.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-07 11:27

Message:
Logged In: YES 
user_id=31435

Assigned back to me.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-07 11:26

Message:
Logged In: YES 
user_id=31435

Ya, this patch is dead.

WRT A<B and C>D while A==C and B==D, yes, I'm afraid that's 
possible, and that sucks bigtime.  The underlying problem 
is that I see no practical way to extend an equality 
relation (given by Py_EQ) to a total ordering.  For 
example, if "==" is determined by Py_EQ, and "<" by address 
comparison, then (forget dicts here for the moment) we can 
construct A, B1 and B2 s.t.

A < B1 == B2 < A

Then using those as keys and/or values in dicts can lead to 
inconsistent dict comparisons too (with this patch applied).

I had three use cases in mind:

1. Speed (in)equality testing.  A note Greg Wilson sent 
earlier this year reminded me that this is an important 
operation for sets (which he's implementing on top of 
dicts).

2. Ensure that (in)equality testing of dicts doesn't blow 
up just because the keys and/or values support only a 
partial ordering, or only (in)equality testing (complex 
numbers are just an extreme case of this).

3. Support sorting a list of dicts without blowing up, 
again if the keys and/or values support only a partial 
ordering.

I've given up on #3.  #1 and #2 could be accomplished by 
implementing the tp_richcompare slot for dicts instead:  if 
I know up-front that "equal: yes or no?" is the only 
outcome of interest, then a different, simpler and faster 
algorithm using only Py_EQ on keys and values would suffice.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-05-07 06:17

Message:
Logged In: YES 
user_id=6380

I have one question about this.  Will the comparison between
dicts using cmp() or <, <=, >, >= also depend on the raw
object address?  That would mean that (even in one program)
there could be two pairs of dictionaries (A,B) and (C,D)
where A<B and C>D while A==C and B==D.  I'm not sure I like
that.

What's the real use case where this matters?  (Either the
speed of == comparisons or the ability to ==-compare dicts
containing complex numbers.)

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=421922&group_id=5470


From noreply@sourceforge.net  Tue May  8 04:35:46 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 07 May 2001 20:35:46 -0700
Subject: [Patches] [ python-Patches-416220 ] pstats.py interactive read function fix
Message-ID: <E14wyHq-0005bX-00@usw-sf-web1.sourceforge.net>

Patches item #416220, was updated on 2001-04-14 19:25
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416220&group_id=5470

Category: library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthew Mueller (donut)
>Assigned to: Eric S. Raymond (esr)
Summary: pstats.py interactive read function fix

Initial Comment:
In pstats.py new interactive mode, read with no
arguments dies because of a misplaced paren.  Simple
one liner fix.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416220&group_id=5470


From noreply@sourceforge.net  Tue May  8 04:36:10 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 07 May 2001 20:36:10 -0700
Subject: [Patches] [ python-Patches-419176 ] Fix 418977: Properly trace cellobjects
Message-ID: <E14wyIE-0005c9-00@usw-sf-web1.sourceforge.net>

Patches item #419176, was updated on 2001-04-26 08:50
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=419176&group_id=5470

Category: core (C code)
Group: None
Status: Open
Resolution: None
>Priority: 6
Submitted By: Martin v. Löwis (loewis)
>Assigned to: Jeremy Hylton (jhylton)
Summary: Fix 418977: Properly trace cellobjects

Initial Comment:
There were two errors in PyFrame_LocalsToFast: first,
it did not add the offset for cell and free vars.
Furthermore, when clearing a cell, not should the
cellobject be deallocated, but the object in the
cellobject.
This patch fixes both bugs.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=419176&group_id=5470


From noreply@sourceforge.net  Tue May  8 05:09:11 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 07 May 2001 21:09:11 -0700
Subject: [Patches] [ python-Patches-419176 ] Fix 418977: Properly trace cellobjects
Message-ID: <E14wyoB-0006AC-00@usw-sf-web1.sourceforge.net>

Patches item #419176, was updated on 2001-04-26 08:50
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=419176&group_id=5470

Category: core (C code)
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 6
Submitted By: Martin v. Löwis (loewis)
Assigned to: Jeremy Hylton (jhylton)
Summary: Fix 418977: Properly trace cellobjects

Initial Comment:
There were two errors in PyFrame_LocalsToFast: first,
it did not add the offset for cell and free vars.
Furthermore, when clearing a cell, not should the
cellobject be deallocated, but the object in the
cellobject.
This patch fixes both bugs.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=419176&group_id=5470


From noreply@sourceforge.net  Tue May  8 05:42:49 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 07 May 2001 21:42:49 -0700
Subject: [Patches] [ python-Patches-421922 ] Implement rich comparison for dicts
Message-ID: <E14wzKj-0002L0-00@usw-sf-web3.sourceforge.net>

Patches item #421922, was updated on 2001-05-06 20:10
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=421922&group_id=5470

Category: core (C code)
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Tim Peters (tim_one)
Summary: Implement rich comparison for dicts

Initial Comment:
Dict comparison currently requires that the keys and 
values enjoy a total ordering, but dicts only require 
Py_EQ in other contexts.  The patch changes dict 
compares to rely on just Py_EQ too, and replaces the 
cmp()-like calls with comparison of raw object 
addresses.  Besides yielding a huge speedup on an 
artificial test case <wink>, it stops surprises like 
these:

>>> {1: 1j} == {1: 2j}
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: cannot compare complex numbers using <, <=, 
>, >=
>>> {1j: 0} == {2j: 0}
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: cannot compare complex numbers using <, <=, 
>, >=
>>>

After the patch:

>>> {1: 1j} == {1: 2j}
0
>>> {1j: 0} == {2j: 0}
0
>>> cmp({1: 1j}, {1: 1j})
0
>>> cmp({1j: 0}, {1j: 0})
0
>>>


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-05-07 21:42

Message:
Logged In: YES 
user_id=31435

Deleted the patch here and checked in a minor variation:

Objects/dictobject.c new revision: 2.83
Lib/test/test_richcmp.py new revision: 1.6
Misc/NEWS new revision: 1.162


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-05-07 14:44

Message:
Logged In: YES 
user_id=6380

Looks cool to me.  Go for it.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-07 13:42

Message:
Logged In: YES 
user_id=31435

Back to Guido.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-07 13:40

Message:
Logged In: YES 
user_id=31435

New patch attached.  As noted in the comment two back, this 
gives up on trying to embed Py_EQ in a total ordering.  
Instead the focii are on making == and != comparison work 
for dicts regardless of whether the keys and values are 
totally ordered, and on speeding == and != dict comparisons 
in any case.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-07 11:27

Message:
Logged In: YES 
user_id=31435

Assigned back to me.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-07 11:26

Message:
Logged In: YES 
user_id=31435

Ya, this patch is dead.

WRT A<B and C>D while A==C and B==D, yes, I'm afraid that's 
possible, and that sucks bigtime.  The underlying problem 
is that I see no practical way to extend an equality 
relation (given by Py_EQ) to a total ordering.  For 
example, if "==" is determined by Py_EQ, and "<" by address 
comparison, then (forget dicts here for the moment) we can 
construct A, B1 and B2 s.t.

A < B1 == B2 < A

Then using those as keys and/or values in dicts can lead to 
inconsistent dict comparisons too (with this patch applied).

I had three use cases in mind:

1. Speed (in)equality testing.  A note Greg Wilson sent 
earlier this year reminded me that this is an important 
operation for sets (which he's implementing on top of 
dicts).

2. Ensure that (in)equality testing of dicts doesn't blow 
up just because the keys and/or values support only a 
partial ordering, or only (in)equality testing (complex 
numbers are just an extreme case of this).

3. Support sorting a list of dicts without blowing up, 
again if the keys and/or values support only a partial 
ordering.

I've given up on #3.  #1 and #2 could be accomplished by 
implementing the tp_richcompare slot for dicts instead:  if 
I know up-front that "equal: yes or no?" is the only 
outcome of interest, then a different, simpler and faster 
algorithm using only Py_EQ on keys and values would suffice.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-05-07 06:17

Message:
Logged In: YES 
user_id=6380

I have one question about this.  Will the comparison between
dicts using cmp() or <, <=, >, >= also depend on the raw
object address?  That would mean that (even in one program)
there could be two pairs of dictionaries (A,B) and (C,D)
where A<B and C>D while A==C and B==D.  I'm not sure I like
that.

What's the real use case where this matters?  (Either the
speed of == comparisons or the ability to ==-compare dicts
containing complex numbers.)

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=421922&group_id=5470


From noreply@sourceforge.net  Tue May  8 06:59:01 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 07 May 2001 22:59:01 -0700
Subject: [Patches] [ python-Patches-417081 ] termios modernization
Message-ID: <E14x0WT-0003jj-00@usw-sf-web2.sourceforge.net>

Patches item #417081, was updated on 2001-04-18 08:30
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=417081&group_id=5470

Category: Modules
Group: None
>Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: Michael Hudson (mwh)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: termios modernization

Initial Comment:
this patch does several things to termios:

(1) changes all functions to be METH_VARARGS
(2) changes all functions to be able to take a file 
    object as the first parameter, as per 

http://mail.python.org/pipermail/python-dev/2001-February/012701.html

(3) give better error messages
(4) removes a bunch of comments that just repeat the
    docstrings
(5) #includes <termio.h> before #including
    <sys/ioctl.h> so more constants are actually
    #defined.
(6) a couple of docstring tweaks

I have tested this minimally (i.e. it builds, and
doesn't blow up too embarassingly) on OSF1/alpha and
on one of the sf compile farm's solaris boxes, and
rather more comprehansively on my linux/x86 box.

It still needs to be tested on all the other platforms
we build termios on (which is why I didn't do this
last week...)

I still need to do the docs.

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-05-07 22:59

Message:
Logged In: YES 
user_id=3066

Documentation checked in as Doc/lib/libtermios.tex revision 1.20.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-05-07 13:44

Message:
Logged In: YES 
user_id=3066

Checked in as Modules/termios.c revision 2.25; documentation to be checked in as soon as SF admins clear a stale CVS lock.  This patch will be closed once the doc patch is commited.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2001-04-18 08:35

Message:
Logged In: YES 
user_id=6656

And here's the docs (not much, as it turns out).

Fred likes these, we hear.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=417081&group_id=5470


From noreply@sourceforge.net  Tue May  8 16:03:03 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 08 May 2001 08:03:03 -0700
Subject: [Patches] [ python-Patches-422329 ] Python 2.1 site.py patch
Message-ID: <E14x90x-0002NR-00@usw-sf-web2.sourceforge.net>

Patches item #422329, was updated on 2001-05-08 08:03
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=422329&group_id=5470

Category: library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Gleen Aduana (gleen)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python 2.1 site.py patch

Initial Comment:
site-package support in Python 2.1 does not work
in Windows because site.py fails to add the
site-package directory in sys.path





----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=422329&group_id=5470


From noreply@sourceforge.net  Tue May  8 17:46:03 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 08 May 2001 09:46:03 -0700
Subject: [Patches] [ python-Patches-422383 ] typo fix in ref7.tex
Message-ID: <E14xAcd-0001dI-00@usw-sf-web1.sourceforge.net>

Patches item #422383, was updated on 2001-05-08 09:46
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=422383&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: David Goodger (goodger)
Assigned to: Nobody/Anonymous (nobody)
Summary: typo fix in ref7.tex

Initial Comment:
Doc/ref/ref7.tex

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=422383&group_id=5470


From noreply@sourceforge.net  Tue May  8 17:46:32 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 08 May 2001 09:46:32 -0700
Subject: [Patches] [ python-Patches-422383 ] typo fix in ref7.tex
Message-ID: <E14xAd6-0001dX-00@usw-sf-web1.sourceforge.net>

Patches item #422383, was updated on 2001-05-08 09:46
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=422383&group_id=5470

>Category: documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: David Goodger (goodger)
Assigned to: Nobody/Anonymous (nobody)
Summary: typo fix in ref7.tex

Initial Comment:
Doc/ref/ref7.tex

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=422383&group_id=5470


From noreply@sourceforge.net  Tue May  8 22:48:32 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 08 May 2001 14:48:32 -0700
Subject: [Patches] [ python-Patches-422471 ] Install Help File
Message-ID: <E14xFLM-0006pb-00@usw-sf-web1.sourceforge.net>

Patches item #422471, was updated on 2001-05-08 14:48
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=422471&group_id=5470

Category: IDLE
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Kurt B. Kaiser (kbk)
Assigned to: Nobody/Anonymous (nobody)
Summary: Install Help File

Initial Comment:
Installing Idle to site-packages via Distutils does not
copy
the Idle help.txt file.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=422471&group_id=5470


From joker@aol.com  Wed May  9 04:03:49 2001
From: joker@aol.com (joker@aol.com)
Date: Tue, 8 May 2001 23:03:49 -0400 (EDT)
Subject: [Patches] Hi
Message-ID: <200105090303.XAA00560@mclean.mail.mindspring.net>

Hi


From joker@aol.com  Wed May  9 08:55:16 2001
From: joker@aol.com (joker@aol.com)
Date: Wed, 9 May 2001 03:55:16 -0400 (EDT)
Subject: [Patches] Hi
Message-ID: <200105090755.DAA00770@smtp6.mindspring.com>

Hi


From noreply@sourceforge.net  Wed May  9 17:11:06 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 09 May 2001 09:11:06 -0700
Subject: [Patches] [ python-Patches-403753 ] zlib decompress; uncontrollable memory usage
Message-ID: <E14xWYM-0004fY-00@usw-sf-web2.sourceforge.net>

Patches item #403753, was updated on 2001-02-12 08:10
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403753&group_id=5470

Category: Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Toby Dickenson (htrd)
>Assigned to: Jeremy Hylton (jhylton)
Summary: zlib decompress; uncontrollable memory usage

Initial Comment:
zlib's decompress method will allocate as much memory as is
needed to hold the decompressed output. The length of the output
buffer may be very much larger than the length of the input buffer,
and the python code calling the decompress method has no other way
to control how much memory is allocated.

In experimentation, I seen decompress generate output that is
1000 times larger than its input

These characteristics may make the decompress method unsuitable for
handling data obtained from untrusted sources (for example,
in a http proxy which implements gzip encoding) since it may be
vulnerable to a denial of service attack. A malicious user could
construct a moderately sized input which forces 'decompress' to
try to allocate too much memory.

This patch adds a new method, decompress_incremental, which allows
the caller to specify the maximum size of the output. This method
returns the excess input, in addition to the decompressed output.

It is possible to solve this problem without a patch:
If input is fed to the decompressor a few tens of bytes
at a time, memory usage will surge by (at most)
a few tens of kilobytes. Such a process is a kludge, and much
less efficient that the approach used in this patch.

(Ive not been able to test the documentation patch; I hope its ok)

(This patch also includes the change from Patch #103748)


----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2001-04-10 10:52

Message:
Logged In: YES 
user_id=11375

I've let this patch gather dust long enough.  Unassigning so
that someone else can review it.

----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2001-04-07 00:20

Message:
Logged In: YES 
user_id=413

as a side note.  I believe I implemented a python workaround
for this problem by just decompressing data in small chunks
(4k at a time) using a decompressor object.

see the mojonation project on sourceforge if you're
curious.  (specifically, in the mojonation evil module, look
at common/mojoutil.py for function named
safe_zlib_decompress).

Regardless, I like thie idea of this patch.  It would be
good to have that in the main API and documentation for
simplicity. (and because there are too many programmers out
there who don't realize potential denial of service issues
on their own...)


----------------------------------------------------------------------

Comment By: Toby Dickenson (htrd)
Date: 2001-02-22 04:50

Message:
New patch implementing a new optional parameter to .decompress, and a new attribute .unconsumed_tail



----------------------------------------------------------------------

Comment By: Toby Dickenson (htrd)
Date: 2001-02-22 03:42

Message:
Waaah - that last comment should be 'cant' not 'can'

----------------------------------------------------------------------

Comment By: Toby Dickenson (htrd)
Date: 2001-02-22 03:40

Message:
We can reuse .unused_data without introducing an ambiguity. I will prepare a patch that uses a new attribute .unconsumed_tail



----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2001-02-21 11:32

Message:
Doesn't .unused_data serve much the same purpose, though?
So that even with a maximum size, .decompress() always returns a string, and .unused_data would contain the unprocessed data.

----------------------------------------------------------------------

Comment By: Toby Dickenson (htrd)
Date: 2001-02-21 06:00

Message:
I did consider that....

An extra change that you didnt mention is the need for a different return value. Currently .decompress() always returns a string. The new method in my patch returns a tuple containing the same string, and an integer specifying how many bytes were consumed from the input.

Overloading return values based on an optional parameter seems a little hairy to me, but I would be happy to change the patch if that is your preferred option.

I also considered (and rejected) the possibility of adding an optional max-size argument to .decompress() as you suggest, but raising an exception if this limit is exceeded. This avoids the need for an extra return value, but looses out on flexibility.


----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2001-02-20 18:48

Message:
Rather than introducing a new method, why not just add an optional maxlen argument to .decompress().  I think the changes would be:

* add 'int maxlen=-1;'
* add "...|i" ... ,&maxlen to the argument parsing
* if maxlen != -1, length = maxlen else length = DEFAULTALLOC;
* Add '&& maxlen==-1' to the while loop.  (Use the current CVS; I just checked in a patch rearranging the zlib module a bit.)

Do you want to make those changes and resubmit the patch?


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403753&group_id=5470


From noreply@sourceforge.net  Wed May  9 17:11:58 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 09 May 2001 09:11:58 -0700
Subject: [Patches] [ python-Patches-403972 ] threaded profiler.
Message-ID: <E14xWZC-0004g5-00@usw-sf-web2.sourceforge.net>

Patches item #403972, was updated on 2001-02-23 07:21
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403972&group_id=5470

Category: demos and tools
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Amila Fernando (amila)
Assigned to: Nobody/Anonymous (nobody)
Summary: threaded profiler.

Initial Comment:
Basically a profiler that can handle threaded programs and generate
profiling snapshots. It does however have some situations it cannot handle well . (see included README for details). 

----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2001-05-09 09:11

Message:
Logged In: YES 
user_id=31392

Perhaps you could share this on comp.lang.python and see if
people can help you fix the situations it doesn't handle
well.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403972&group_id=5470


From noreply@sourceforge.net  Wed May  9 17:12:53 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 09 May 2001 09:12:53 -0700
Subject: [Patches] [ python-Patches-403977 ] Rename config.h to pyac_config.h, per SF bug #131774
Message-ID: <E14xWa5-0004h2-00@usw-sf-web2.sourceforge.net>

Patches item #403977, was updated on 2001-02-23 13:28
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403977&group_id=5470

Category: Build
Group: None
Status: Open
Resolution: Postponed
Priority: 1
Submitted By: Thomas Wouters (twouters)
>Assigned to: Thomas Wouters (twouters)
Summary: Rename config.h to pyac_config.h, per SF bug #131774

Initial Comment:
This patch fixes the UNIX and Windows builds to use 'pyac_config.h' instead of 'config.h', to avoid the problems summarized in SF bug #131774. It doesn't address the placing issue, however, because I believe it's intended to be like this.

Most changes were done using a fairly intelligent shell+sed oneliner, but they should be correct. The Windows build *seems* correct, though I can't be sure. Someone will have to check ;) It is probably a good idea to remove 'config.h' before testing, to be sure I got all references.

The UNIX build requires that autoconf is installed, and requires a 'autoheader ; autoconf' is done before running 'configure'. Removing config.h(.in) is also a good idea.

I excluded the OS2 build files, and will be uploading those as a seperate patch to avoid making this one unreadable Though only two files are involved, they both list all dependencies for *all* files in its entirety, so the patch is quite large. If those files are auto-generated, someone please tell me so :-)

I also didn't fix distutils, though it looks like it does need fixing. And I didn't do anything wrt. backwards compatibility. We should probably provide a config.h that just does

#warning Warning: Use of Python-specific config.h is deprecated. Use pyac_config.h instead.
#include <pyac_config.h>

The name is just my suggestion, changing it into something less acronymic would be no problem at all. I think 'pythonconfig.h' gives the wrong message though: the file isn't used to configure Python itself, after all ;)


----------------------------------------------------------------------

Comment By: Thomas Wouters (twouters)
Date: 2001-04-11 05:43

Message:
Logged In: YES 
user_id=34209

I'm not sure about the supersedence here. See my comment in
#411138.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-10 15:15

Message:
Logged In: YES 
user_id=6380

Is this superseded by patch #411138?


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-03-18 16:09

Message:
Logged In: YES 
user_id=6380

Let's do this after 2.1 is released.  Status set to postponed and priority lowered.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-03-01 17:29

Message:
Logged In: YES 
user_id=31435

Na, I don't mind the pyac name.  I had forgotten (or 
perhaps never knew) that this thing is a generated file (on 
Windows it's done by hand).  It's an internal 
implementation detail anyway, so it doesn't matter if the 
name "makes sense" to Windows geeks; at least pyac_config 
will make some sense to Linux dweebs.

----------------------------------------------------------------------

Comment By: Trent Mick (tmick)
Date: 2001-03-01 17:08

Message:
Logged In: YES 
user_id=34892

Tim said:
> BTW, I have no idea what "pyac" is supposed to bring
> to mind.  Is that some Unixism?

In answer to that. How about just calling it "pyconfig.h". 
The reference to autoconf is not very accurate for Windows. 

----------------------------------------------------------------------

Comment By: Thomas Wouters (twouters)
Date: 2001-02-28 01:07

Message:
Logged In: YES 
user_id=34209

I forgot to mention that I think this should be postponed
until 2.2 or 2.1.1 anyway. It's not that big a change, but
it's big enough to have weird and unsuspected sideffects.

The bug is now numbered #231774, by the way. The problem is
that 'config.h' is an oft-used name, and if you include it
but have another directory with another project's config.h
earlier in your include path, you get the wrong one. Similar
if you intend to use the other one, but get this one.
Leaving a fake config.h would only cause this patch to fix
half of those problems, but only the first problem was
reported in the bugreport :)

The 'pyac_config' name comes from 'python', 'autoconf',
'config', and is IMHO sufficiently vague that it implies it
is autogenerated :-)





----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2001-02-27 23:14

Message:
Logged In: YES 
user_id=31392

No time

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2001-02-27 13:53

Message:
Logged In: YES 
user_id=35752

SF seems to have changed the bug ids!  I can't find bug 
#131774.  Unless there is a very good reason for the
change I'm against it for 2.1.

----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2001-02-27 13:05

Message:
Logged In: YES 
user_id=11375

Regarding Distutils: I think the only actual *code* 
that would change is in distutils/sysconfig.py, 
in the get_config_h_filename() method.  For backward
compat., this method would probably have to check the Python
version and use pyac_config.h if the version is 2.1 or
greater.

There are also lots of references to config.h in comments;
we can change those or not, as desired.  (I probably *would*
change most of them.)


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-02-27 12:48

Message:
Logged In: YES 
user_id=31435

Pushed onto Jeremy.  Jeremy, we want to do this much 
fiddling so late in the cycle?

Thomas, don't worry about Windows.  I only need a warning 
about that, and I've aware of this now (thanks!).  Check in 
the new MS project files or don't, it's easy for me to 
fix 'em up regardless (indeed, it's not worth extra time to 
check it in advance).

Note that "#warning" is not std C.  I'm afraid you'll have 
to make it an #error.  OTOH, if you leave a file 
*named* "config.h" in the distribution, it doesn't really 
address the bug report, right?

BTW, I have no idea what "pyac" is supposed to bring to 
mind.  Is that some Unixism?


----------------------------------------------------------------------

Comment By: Thomas Wouters (twouters)
Date: 2001-02-23 13:32

Message:
Apologies for the large blurb in the 'details' section. I keep forgetting SF strips *all* whitespace from that block :(

Assigning to Tim "The Windows Bot" Peters to test (and fix) the Windows build changes. Let me know if your patch still doesn't work and you want me to send you patched files instead, Tim.



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403977&group_id=5470


From noreply@sourceforge.net  Wed May  9 17:12:53 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 09 May 2001 09:12:53 -0700
Subject: [Patches] [ python-Patches-403978 ] config.h -&amp;gt; pyac_config.h change for OS2
Message-ID: <E14xWa5-0004hA-00@usw-sf-web2.sourceforge.net>

Patches item #403978, was updated on 2001-02-23 13:34
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403978&group_id=5470

Category: Build
Group: None
Status: Open
Resolution: Postponed
Priority: 1
Submitted By: Thomas Wouters (twouters)
>Assigned to: Thomas Wouters (twouters)
>Summary: config.h -&amp;gt; pyac_config.h change for OS2

Initial Comment:
Companion to SF patch #103977, the OS2 part. To keep the size down, I didn't include pyac_config.h. If you want to test this patch, you'll have to rename config.h to pyac_config.h manually.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-10 15:11

Message:
Logged In: YES 
user_id=6380

Is this superseded by patch #411138?

----------------------------------------------------------------------

Comment By: Thomas Wouters (twouters)
Date: 2001-02-28 01:01

Message:
Logged In: YES 
user_id=34209

Postponed, it's too late to get it into 2.1 (I actually
intended to mark it postponed from the start, but forgot
to.)

The companion patch is now numbered '#403977', by the way.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403978&group_id=5470


From noreply@sourceforge.net  Wed May  9 17:15:04 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 09 May 2001 09:15:04 -0700
Subject: [Patches] [ python-Patches-422383 ] typo fix in ref7.tex
Message-ID: <E14xWcC-0004jV-00@usw-sf-web2.sourceforge.net>

Patches item #422383, was updated on 2001-05-08 09:46
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=422383&group_id=5470

Category: documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: David Goodger (goodger)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: typo fix in ref7.tex

Initial Comment:
Doc/ref/ref7.tex

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=422383&group_id=5470


From noreply@sourceforge.net  Wed May  9 17:14:50 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 09 May 2001 09:14:50 -0700
Subject: [Patches] [ python-Patches-419648 ] Carbon support for distutils on Mac
Message-ID: <E14xWby-0004ib-00@usw-sf-web2.sourceforge.net>

Patches item #419648, was updated on 2001-04-27 15:15
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=419648&group_id=5470

Category: distutils
Group: 2.0.1 bugfix
Status: Open
Resolution: None
Priority: 7
Submitted By: Jack Jansen (jackjansen)
Assigned to: Nobody/Anonymous (nobody)
Summary: Carbon support for distutils on Mac

Initial Comment:
Carbon support for distutils on the mac was somehow not checked in. MacPython from 2.1
onwards needs this.


----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2001-05-09 09:14

Message:
Logged In: YES 
user_id=31392

Is there a reason you don't check this in yourself, Jack?


----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2001-04-27 15:43

Message:
Logged In: YES 
user_id=45365




----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=419648&group_id=5470


From noreply@sourceforge.net  Wed May  9 17:15:36 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 09 May 2001 09:15:36 -0700
Subject: [Patches] [ python-Patches-422106 ] Seg fault in sys.displayhook
Message-ID: <E14xWci-0004kD-00@usw-sf-web2.sourceforge.net>

Patches item #422106, was updated on 2001-05-07 13:07
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=422106&group_id=5470

Category: core (C code)
Group: None
Status: Open
Resolution: None
>Priority: 7
Submitted By: Gregory H. Ball (greg_ball)
>Assigned to: Moshe Zadka (moshez)
Summary: Seg fault in sys.displayhook

Initial Comment:
If you do a very silly thing and delete the
"__builtin__" entry
from sys.modules, the default displayhook is defeated.
This problem exists in 2.1 and current CVS, but not 2.0
(The old display loop held a reference to the builtin
module instead of repeatedly fetching it in 2.0, I
guess.)


My patch just checks whether the module is in the
expected location and raises an exception instead of
dumping core.
The error message is not especially illuminating, but
then,
anyone who actually does this deserves far worse ;-)



----------------------------------------------------------------------

Comment By: Gregory H. Ball (greg_ball)
Date: 2001-05-07 13:10

Message:
Logged In: YES 
user_id=11365

The problem:

Python 2.2a0 (#13, May  7 2001, 15:45:00) 
[GCC 2.95.3 19991030 (prerelease)] on linux2
Type "copyright", "credits" or "license" for more
information.
>>> import sys
>>> del sys.modules['__builtin__']
>>> 1
Segmentation fault (core dumped)

The solution:

Python 2.2a0 (#16, May  7 2001, 16:03:33) 
[GCC 2.95.3 19991030 (prerelease)] on linux2
Type "copyright", "credits" or "license" for more
information.
>>> import sys
>>> del sys.modules['__builtin__']
>>> 1
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
RuntimeError: lost __builtin__
>>> 


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=422106&group_id=5470


From noreply@sourceforge.net  Wed May  9 17:15:22 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 09 May 2001 09:15:22 -0700
Subject: [Patches] [ python-Patches-422329 ] Python 2.1 site.py patch
Message-ID: <E14xWcU-0004jg-00@usw-sf-web2.sourceforge.net>

Patches item #422329, was updated on 2001-05-08 08:03
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=422329&group_id=5470

Category: library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Gleen Aduana (gleen)
>Assigned to: Tim Peters (tim_one)
Summary: Python 2.1 site.py patch

Initial Comment:
site-package support in Python 2.1 does not work
in Windows because site.py fails to add the
site-package directory in sys.path





----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=422329&group_id=5470


From noreply@sourceforge.net  Wed May  9 17:15:53 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 09 May 2001 09:15:53 -0700
Subject: [Patches] [ python-Patches-421709 ] Access { thread id : frame } dict
Message-ID: <E14xWcz-0004kb-00@usw-sf-web2.sourceforge.net>

Patches item #421709, was updated on 2001-05-05 13:30
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=421709&group_id=5470

Category: core (C code)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: John D. Heintz (jheintz)
>Assigned to: Barry Warsaw (bwarsaw)
Summary: Access { thread id : frame } dict

Initial Comment:
This patch adds a new function sys._getframes() that 
returns a dictionary mapping from thread id to 
current frame object.

This is very useful when diagnosing deadlock issues 
in Python code.

The new C code function is purely additive except for 
modifying the PyThreadState struct (adding a long 
thread_ident) and modifying PyThreadState_New() 
function to set this new long.



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=421709&group_id=5470


From noreply@sourceforge.net  Wed May  9 17:16:22 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 09 May 2001 09:16:22 -0700
Subject: [Patches] [ python-Patches-419652 ] Disable input look Tk event processing o
Message-ID: <E14xWdS-0004lN-00@usw-sf-web2.sourceforge.net>

Patches item #419652, was updated on 2001-04-27 15:25
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=419652&group_id=5470

Category: core (C code)
Group: 2.0.1 bugfix
Status: Open
Resolution: None
Priority: 5
Submitted By: Jack Jansen (jackjansen)
>Assigned to: Fredrik Lundh (effbot)
Summary: Disable input look Tk event processing o

Initial Comment:
The Tk input handler on the Mac is too greedy, and file handlers are available but don't work. Disable
mainloop Tk event handling at least makes the console usable again after using Tk.


----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2001-04-27 15:39

Message:
Logged In: YES 
user_id=45365




----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=419652&group_id=5470


From noreply@sourceforge.net  Wed May  9 17:16:40 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 09 May 2001 09:16:40 -0700
Subject: [Patches] [ python-Patches-420565 ] makes setup.py search sys.prefix
Message-ID: <E14xWdk-0004ln-00@usw-sf-web2.sourceforge.net>

Patches item #420565, was updated on 2001-05-01 14:24
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=420565&group_id=5470

Category: Build
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: A.M. Kuchling (akuchling)
Summary: makes setup.py search sys.prefix 

Initial Comment:
It's useful to have setup.py search the lib and include
directories in sys.prefix before it checks /usr/local.
That way, if you are building Python into a custom
location and want it to use the the libraries installed
there rather than the system defaults, you can give the
--prefix option to configure and setup.py will search
that path first.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=420565&group_id=5470


From noreply@sourceforge.net  Wed May  9 17:16:55 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 09 May 2001 09:16:55 -0700
Subject: [Patches] [ python-Patches-418489 ] unittest string format error
Message-ID: <E14xWdz-0004mD-00@usw-sf-web2.sourceforge.net>

Patches item #418489, was updated on 2001-04-23 23:58
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=418489&group_id=5470

Category: library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Andrew Dalke (dalke)
>Assigned to: Steve Purcell (purcell)
Summary: unittest string format error

Initial Comment:
unittest.loadTestsFromName has a string format error
of the form - it needs some parens.  Currently is:

 raise ValueError, \
    "calling %s returned %s, not a test" % obj,test

should be

 raise ValueError, \
   "calling %s returned %s, not a test" % (obj,test)

Let's see if this really will let me upload a patch.

Index: unittest.py
=======================================================
============
RCS 
file: /cvsroot/python/python/dist/src/Lib/unittest.py,v
retrieving revision 1.7
diff -c -r1.7 unittest.py
*** unittest.py 2001/04/15 09:18:32     1.7
--- unittest.py 2001/04/24 06:57:32
***************
*** 443,449 ****
              if not isinstance(test, TestCase) and \
                 not isinstance(test, TestSuite):
                  raise ValueError, \
!                       "calling %s returned %s, not a 
test" % obj,test
              return test
          else:
              raise ValueError, "don't know how to 
make test from: %s" % obj
--- 443,449 ----
              if not isinstance(test, TestCase) and \
                 not isinstance(test, TestSuite):
                  raise ValueError, \
!                       "calling %s returned %s, not a 
test" % (obj, test)
              return test
          else:
              raise ValueError, "don't know how to 
make test from: %s" % obj


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=418489&group_id=5470


From noreply@sourceforge.net  Wed May  9 17:17:16 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 09 May 2001 09:17:16 -0700
Subject: [Patches] [ python-Patches-419070 ] Fix #416670: register SRE types
Message-ID: <E14xWeK-0004ml-00@usw-sf-web2.sourceforge.net>

Patches item #419070, was updated on 2001-04-26 00:59
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=419070&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Martin v. Löwis (loewis)
>Assigned to: Fredrik Lundh (effbot)
Summary: Fix #416670: register SRE types

Initial Comment:
This patch registers the three SRE types in the copy
module as immutable, atomic types. This is not
completely correct, since pattern.groupindex is a
mutable object (a dictionary). Since nobody *should*
change that dictionary, treating it as immutable is
sufficient.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=419070&group_id=5470


From noreply@sourceforge.net  Wed May  9 17:17:57 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 09 May 2001 09:17:57 -0700
Subject: [Patches] [ python-Patches-418390 ] static member functions
Message-ID: <E14xWez-0004nb-00@usw-sf-web2.sourceforge.net>

Patches item #418390, was updated on 2001-04-23 15:39
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=418390&group_id=5470

Category: core (C code)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: static member functions

Initial Comment:
This allows for class methods to be called statically 
without the need for workaround abuse as described in 
the python FAQ (or any other method involving grabbing 
the "im_func" member from an unbound method object).

This patch changes the "call_method" function in 
ceval.c. It removes the improper 'class type 
enforcement' on unbound method objects and just passes 
the arguments as is.

This allows for natural and clean static methods 
inside classes.

The only thing potentially broken with this patch is a 
looser guarantee that the "self" value for a method 
would be some inherited type instance. This is far 
less 'dangerous for abuse' than other python class 
designs (no private members, etc).

With this the static method example in the FAQ is much 
more cleanly realized. notice, no "self" member for 
static methods...


class C:
    count = 0   
    def __init__(self):
        C.count += 1
    def getcount():
        return C.count 
    def sum(x, y):
        return x + y
        
C(); C()
c = C()
print C.getcount()  # prints 3
print c.getcount()  # prints 3
print C.sum(27, 15) # prints 42


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-04-23 16:00

Message:
Logged In: NO 

btw, i did submit with my email address, but sourceforge 
has relabeled me as anonymous. please respond to

"pete at shinners dot org" 

should that be required. doh, i see sourceforge didn't 
respect my example formatting either.

----------------------------------------------------------------------

Comment By: Mark Kimsal (hardcoreholly)
Date: 2001-04-23 15:47

Message:
Logged In: YES 
user_id=89302

an application programmer could still secure the type of 
the arguments if s/he felt it was necessary by raising the 
unbound method exception if the first arg was not the 
expected type.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=418390&group_id=5470


From noreply@sourceforge.net  Wed May  9 17:18:59 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 09 May 2001 09:18:59 -0700
Subject: [Patches] [ python-Patches-416250 ] 2.1c1 thread_pthread: unused vrbl  clean
Message-ID: <E14xWfz-0004p8-00@usw-sf-web2.sourceforge.net>

Patches item #416250, was updated on 2001-04-15 04:25
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416250&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark Favas (mfavas)
>Assigned to: M.-A. Lemburg (lemburg)
Summary: 2.1c1 thread_pthread: unused vrbl  clean

Initial Comment:
Variables set but not used

*** thread_pthread.h.orig       Sun Apr 15 18:30:22
2001
--- thread_pthread.h    Sun Apr 15 18:32:02 2001
***************
*** 273,279 ****
  PyThread_free_lock(PyThread_type_lock lock)
  {
        pthread_lock *thelock = (pthread_lock *)lock;
!       int status, error = 0;
  
        dprintf(("PyThread_free_lock(%p) called\n",
lock));
  
--- 273,279 ----
  PyThread_free_lock(PyThread_type_lock lock)
  {
        pthread_lock *thelock = (pthread_lock *)lock;
!       int status;
  
        dprintf(("PyThread_free_lock(%p) called\n",
lock));
  
***************
*** 328,334 ****
  PyThread_release_lock(PyThread_type_lock lock)
  {
        pthread_lock *thelock = (pthread_lock *)lock;
!       int status, error = 0;
  
        dprintf(("PyThread_release_lock(%p) called\n",
lock));
  
--- 328,334 ----
  PyThread_release_lock(PyThread_type_lock lock)
  {
        pthread_lock *thelock = (pthread_lock *)lock;
!       int status;
  
        dprintf(("PyThread_release_lock(%p) called\n",
lock));
  
***************
*** 386,392 ****
  void 
  PyThread_free_sema(PyThread_type_sema sema)
  {
!       int status, error = 0;
        struct semaphore *thesema = (struct semaphore
*) sema;
  
        dprintf(("PyThread_free_sema(%p) called\n", 
sema));
--- 386,392 ----
  void 
  PyThread_free_sema(PyThread_type_sema sema)
  {
!       int status;
        struct semaphore *thesema = (struct semaphore
*) sema;
  
        dprintf(("PyThread_free_sema(%p) called\n", 
sema));
***************
*** 430,436 ****
  void 
  PyThread_up_sema(PyThread_type_sema sema)
  {
!       int status, error = 0;
        struct semaphore *thesema = (struct semaphore
*) sema;
  
        dprintf(("PyThread_up_sema(%p)\n",  sema));
--- 430,436 ----
  void 
  PyThread_up_sema(PyThread_type_sema sema)
  {
!       int status;
        struct semaphore *thesema = (struct semaphore
*) sema;
  
        dprintf(("PyThread_up_sema(%p)\n",  sema));


----------------------------------------------------------------------

Comment By: Mark Favas (mfavas)
Date: 2001-04-15 04:36

Message:
Logged In: YES 
user_id=44979

Aaaaaaaaargh! Ignore this one - sorry! I rebuilt after
changing this, but thread.c (which depends on this include
file) was not rebuilt automatically (makefile dependency
needs fixing, I guess). Errors ensued when I recompiled
thread.c - error is set in the macro CHECK_STATUS and
sometimes used and sometimes not - would require making two
macros, so not worth doing.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416250&group_id=5470


From noreply@sourceforge.net  Wed May  9 17:19:00 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 09 May 2001 09:19:00 -0700
Subject: [Patches] [ python-Patches-416262 ] 2.1c1: make setup.py check zlib version
Message-ID: <E14xWg0-0004pO-00@usw-sf-web2.sourceforge.net>

Patches item #416262, was updated on 2001-04-15 06:14
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416262&group_id=5470

Category: Build
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark Favas (mfavas)
>Assigned to: M.-A. Lemburg (lemburg)
Summary: 2.1c1: make setup.py check zlib version

Initial Comment:
Currently, setup.py will build the zlib module without
checking whether the version of zlib on the target
system is up to date (or at least 1.1.3). The module
will thus be built on a stock SGI system where the zlib
version is 1.0.4. WHen the zlib test is run, a core
dump results. The patch below checks the version of
zlib, and only builds if >= 1.1.3

*** setup.py.orig       Sun Apr 15 20:59:34 2001
--- setup.py    Sun Apr 15 21:00:53 2001
***************
*** 449,457 ****
          # Andrew Kuchling's zlib module.
          # This require zlib 1.1.3 (or later).
          # See http://www.cdrom.com/pub/infozip/zlib/
!         if (self.compiler.find_library_file(lib_dirs,
'z')):
!             exts.append( Extension('zlib',
['zlibmodule.c'],
!                                    libraries = ['z'])
)
  
          # Interface to the Expat XML parser
          #
--- 449,471 ----
          # Andrew Kuchling's zlib module.
          # This require zlib 1.1.3 (or later).
          # See http://www.cdrom.com/pub/infozip/zlib/
!         zlib_inc = find_file('zlib.h', [], inc_dirs)
!         if zlib_inc is not None:
!             zlib_h = zlib_inc[0] + '/zlib.h'
!             version = '"0.0.0"'
!             version_req = '"1.1.3"'
!             fp = open(zlib_h)
!             while 1:
!                 line = fp.readline()
!                 if not line:
!                     break
!                 if line.find('#define ZLIB_VERSION',
0) == 0:
!                     version = line.split()[2]
!                     break
!             if version >= version_req:
!                 if
(self.compiler.find_library_file(lib_dirs, 'z')):
!                     exts.append( Extension('zlib',
['zlibmodule.c'],
!                                            libraries
= ['z']) )
  
          # Interface to the Expat XML parser
          #


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416262&group_id=5470


From noreply@sourceforge.net  Wed May  9 17:18:59 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 09 May 2001 09:18:59 -0700
Subject: [Patches] [ python-Patches-416251 ] 2.1c1 mmapmodule: unused vrbl cleanup
Message-ID: <E14xWfz-0004pG-00@usw-sf-web2.sourceforge.net>

Patches item #416251, was updated on 2001-04-15 04:26
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416251&group_id=5470

Category: Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark Favas (mfavas)
>Assigned to: M.-A. Lemburg (lemburg)
Summary: 2.1c1 mmapmodule: unused vrbl cleanup

Initial Comment:
Variable set but unused

*** mmapmodule.c.orig   Sun Apr 15 18:37:16 2001
--- mmapmodule.c        Sun Apr 15 18:38:43 2001
***************
*** 163,169 ****
  mmap_read_byte_method(mmap_object *self,
                      PyObject *args)
  {
-       char value;
        char *where;
        CHECK_VALID(NULL);
          if (!PyArg_ParseTuple(args, ":read_byte"))
--- 163,168 ----
***************
*** 170,176 ****
                return NULL;
        if (self->pos < self->size) {
                where = self->data + self->pos;
-               value = (char) *(where);
                self->pos += 1;
                return Py_BuildValue("c", (char)
*(where));
        } else {
--- 169,174 ----


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416251&group_id=5470


From noreply@sourceforge.net  Wed May  9 17:18:59 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 09 May 2001 09:18:59 -0700
Subject: [Patches] [ python-Patches-416249 ] 2.1c1 compile: unused vrbl cleanup
Message-ID: <E14xWfz-0004p0-00@usw-sf-web2.sourceforge.net>

Patches item #416249, was updated on 2001-04-15 04:22
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416249&group_id=5470

Category: core (C code)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark Favas (mfavas)
>Assigned to: M.-A. Lemburg (lemburg)
Summary: 2.1c1 compile: unused vrbl cleanup

Initial Comment:
Variable set but unused

*** compile.c.orig      Sun Apr 15 18:15:26 2001
--- compile.c   Sun Apr 15 18:17:08 2001
***************
*** 3551,3563 ****
        for (i = 0, narg = 0; i < nch; i++) {
                node *ch = CHILD(n, i);
                node *fp;
-               char *name;
                if (TYPE(ch) == STAR || TYPE(ch) ==
DOUBLESTAR)
                        break;
                REQ(ch, fpdef); /* fpdef: NAME | '('
fplist ')' */
                fp = CHILD(ch, 0);
                if (TYPE(fp) != NAME) {
-                       name = nbuf;
                        sprintf(nbuf, ".%d", i);
                        complex = 1;
                }
--- 3551,3561 ----


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416249&group_id=5470


From noreply@sourceforge.net  Wed May  9 17:18:59 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 09 May 2001 09:18:59 -0700
Subject: [Patches] [ python-Patches-416247 ] 2.1c1 stringobject: unused vrbl cleanup
Message-ID: <E14xWfz-0004os-00@usw-sf-web2.sourceforge.net>

Patches item #416247, was updated on 2001-04-15 04:18
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416247&group_id=5470

Category: core (C code)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark Favas (mfavas)
>Assigned to: M.-A. Lemburg (lemburg)
Summary: 2.1c1 stringobject: unused vrbl cleanup

Initial Comment:
Variable set but unused:

*** stringobject.c.orig Sun Apr 15 17:51:21 2001
--- stringobject.c      Sun Apr 15 18:10:26 2001
***************
*** 2758,2764 ****
                        int flags = 0;
                        int width = -1;
                        int prec = -1;
-                       int size = 0;
                        int c = '\0';
                        int fill;
                        PyObject *v = NULL;
--- 2758,2763 ----
***************
*** 2895,2901 ****
                        } /* prec */
                        if (fmtcnt >= 0) {
                                if (c == 'h' || c ==
'l' || c == 'L') {
-                                       size = c;
                                        if (--fmtcnt >=
0)
                                                c =
*fmt++;
                                }
--- 2894,2899 ----


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416247&group_id=5470


From noreply@sourceforge.net  Wed May  9 17:19:18 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 09 May 2001 09:19:18 -0700
Subject: [Patches] [ python-Patches-417084 ] sre: Speed up Unicode charsets
Message-ID: <E14xWgI-0004pu-00@usw-sf-web2.sourceforge.net>

Patches item #417084, was updated on 2001-04-18 08:34
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=417084&group_id=5470

Category: core (C code)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Martin v. Löwis (loewis)
>Assigned to: Fredrik Lundh (effbot)
Summary: sre: Speed up Unicode charsets

Initial Comment:
When matching large Unicode charsets (e.g. the one that
defines an XML name, from xml.utils.characters),
matching is quite slow, since a linear search over the
ranges is performed.

The patch compiles a unicode character class into a
BIGCHARSET opcode, using a compression technique
similar to the one that the expat parser uses (see
comment in sre_parse).

With the patch, runtime for

import time,re,xml.utils.characters
u = u"Hallo welt"
e = xml.utils.characters.re_Name
t = time.time()
for i in xrange(1000000):
    e.match(u)
print time.time()-t

could be reduced to 45%. Even when doing full parsing
using CVS xmlproc, a 4% speedup can still be observed.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=417084&group_id=5470


From noreply@sourceforge.net  Wed May  9 17:19:36 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 09 May 2001 09:19:36 -0700
Subject: [Patches] [ python-Patches-416298 ] Fix in typo in WeakValueDictionary
Message-ID: <E14xWga-0004q6-00@usw-sf-web2.sourceforge.net>

Patches item #416298, was updated on 2001-04-15 12:14
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416298&group_id=5470

Category: Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Fix in typo in WeakValueDictionary

Initial Comment:
There is a small error in weakref.WeakValueDictionary.

This error was found in 2.1c1, a quick look in the
april 15th build revealed it was not fixed.

Demonstration:

>>> class Spam:
...     pass
...
>>> dict = {'a':Spam()}
>>> weakref.WeakValueDictionary(dict)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File
"/usr/local/python-2.1c1/lib/python2.1/UserDict.py",
line 6, in __init__
    if dict is not None: self.update(dict)
  File
"/usr/local/python-2.1c1/lib/python2.1/weakref.py",
line 103, in update
    L.append(key, ref(o, remove))

Examination of the script reveals that the fix is obvious:

    def update(self, dict):
        d = self.data
        L = []
        for key, o in dict.items():
            def remove(o, data=d, key=key):
                del data[key]
            # L.append(key, ref(o, remove))
            # ^^^ erroneous ^^^^
            L.append((key, ref(o, remove)))
            # ^^^ right ^^^
        for key, r in L:
            d[key] = r


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-04-17 21:36

Message:
Logged In: NO 

Ok, I submitted it the day before the 2.1 was released.

I has been fixed in the release. Nevermind.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-04-17 21:35

Message:
Logged In: NO 

Ok, I submitted it the day before the 2.1 was released.

I has been fixed in the release. Nevermind.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416298&group_id=5470


From noreply@sourceforge.net  Wed May  9 17:20:08 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 09 May 2001 09:20:08 -0700
Subject: [Patches] [ python-Patches-418011 ] Updated zipfile docs
Message-ID: <E14xWh6-0004qx-00@usw-sf-web2.sourceforge.net>

Patches item #418011, was updated on 2001-04-22 07:54
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=418011&group_id=5470

Category: documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Itamar Shtull-Trauring (itamar)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Updated zipfile docs

Initial Comment:
Updates zipfile.ZipFile's docs so it mentions that fact
you can open arbitary file-like objects.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=418011&group_id=5470


From noreply@sourceforge.net  Wed May  9 17:20:44 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 09 May 2001 09:20:44 -0700
Subject: [Patches] [ python-Patches-417795 ] Fix memory cycles in Weak*Dictionary
Message-ID: <E14xWhg-0004rJ-00@usw-sf-web2.sourceforge.net>

Patches item #417795, was updated on 2001-04-20 21:19
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=417795&group_id=5470

Category: library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: David Allouche (ddaa10)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Fix memory cycles in Weak*Dictionary

Initial Comment:
There is a subtle bug in WeakValueDictionary and
WeakKeyDictonary that cause them to create reference
cycles.

This does not break anything by itself, but:
1/ it's bad to rely on the garbage collector;
2/ this could lead to uncollectable cycles if a
subclass of Weak*Dictionary defines __del__.

The trick is that deletions of a key/value of a item
trigger a remove function. That remove function is
strong referenced inside the weakref object. That
function internally stores a strong reference to the
self.data (dictionary) object. self.data obviously
strong references the weakref object.

The minimal overhead solution would be to use a __del__
method that would empty the self.data dictionary (thus
breaking the references loops at Weak*Dictionary
destruction). This solution is not acceptable since a
key (for WeakValueDictionnary) or a value (for
WeakKeyDictionary) can be a composite object. Such
composite object can contain a reference which
ultimately loops back to the Weak*Dictionary. Ok that's
an user ref cycle, but the library __del__ method makes
it uncollectable.

The solution I propose is to change the remove function
to contain, not a strong reference to the dictionary,
but a weak reference to the Weak*Dictionary object. If
the weakref has expired when the remove function is
called; we just do nothing.

This can lead to a silent change in behavior if the
user has broken the encapsulation of the
Weak*Dictionary and stored an external reference to the
data dictionary. I think the best possible solution
would be to give the choice between the two remove
functions at runtime through a module variable.

The attached patch makes a "weakref-patched.py" file
from the "weakref.py" file of the 2.1 distribution.
That file implements my proposed solution. It has been
regression tested.

It would make sense to add test units for memory cycles
int test_weakref.py, but I'm too newbie (and do not
have enough time) to do it myself.

Keep on the good work.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=417795&group_id=5470


From noreply@sourceforge.net  Wed May  9 19:48:50 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 09 May 2001 11:48:50 -0700
Subject: [Patches] [ python-Patches-416251 ] 2.1c1 mmapmodule: unused vrbl cleanup
Message-ID: <E14xZ10-0005NT-00@usw-sf-web3.sourceforge.net>

Patches item #416251, was updated on 2001-04-15 04:26
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416251&group_id=5470

Category: Modules
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Mark Favas (mfavas)
>Assigned to: Tim Peters (tim_one)
Summary: 2.1c1 mmapmodule: unused vrbl cleanup

Initial Comment:
Variable set but unused

*** mmapmodule.c.orig   Sun Apr 15 18:37:16 2001
--- mmapmodule.c        Sun Apr 15 18:38:43 2001
***************
*** 163,169 ****
  mmap_read_byte_method(mmap_object *self,
                      PyObject *args)
  {
-       char value;
        char *where;
        CHECK_VALID(NULL);
          if (!PyArg_ParseTuple(args, ":read_byte"))
--- 163,168 ----
***************
*** 170,176 ****
                return NULL;
        if (self->pos < self->size) {
                where = self->data + self->pos;
-               value = (char) *(where);
                self->pos += 1;
                return Py_BuildValue("c", (char)
*(where));
        } else {
--- 169,174 ----


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-05-09 11:48

Message:
Logged In: YES 
user_id=31435

Checked in a similar change, to mmapmodule.c rev 2.29.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416251&group_id=5470


From noreply@sourceforge.net  Wed May  9 19:54:11 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 09 May 2001 11:54:11 -0700
Subject: [Patches] [ python-Patches-416249 ] 2.1c1 compile: unused vrbl cleanup
Message-ID: <E14xZ6B-0005SG-00@usw-sf-web3.sourceforge.net>

Patches item #416249, was updated on 2001-04-15 04:22
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416249&group_id=5470

Category: core (C code)
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Mark Favas (mfavas)
>Assigned to: Tim Peters (tim_one)
Summary: 2.1c1 compile: unused vrbl cleanup

Initial Comment:
Variable set but unused

*** compile.c.orig      Sun Apr 15 18:15:26 2001
--- compile.c   Sun Apr 15 18:17:08 2001
***************
*** 3551,3563 ****
        for (i = 0, narg = 0; i < nch; i++) {
                node *ch = CHILD(n, i);
                node *fp;
-               char *name;
                if (TYPE(ch) == STAR || TYPE(ch) ==
DOUBLESTAR)
                        break;
                REQ(ch, fpdef); /* fpdef: NAME | '('
fplist ')' */
                fp = CHILD(ch, 0);
                if (TYPE(fp) != NAME) {
-                       name = nbuf;
                        sprintf(nbuf, ".%d", i);
                        complex = 1;
                }
--- 3551,3561 ----


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-05-09 11:54

Message:
Logged In: YES 
user_id=31435

Patch applied to compile.c, rev 2.200.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416249&group_id=5470


From noreply@sourceforge.net  Wed May  9 20:32:37 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 09 May 2001 12:32:37 -0700
Subject: [Patches] [ python-Patches-422329 ] Python 2.1 site.py patch
Message-ID: <E14xZhN-0002RD-00@usw-sf-web1.sourceforge.net>

Patches item #422329, was updated on 2001-05-08 08:03
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=422329&group_id=5470

Category: library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Gleen Aduana (gleen)
>Assigned to: Mark Hammond (mhammond)
Summary: Python 2.1 site.py patch

Initial Comment:
site-package support in Python 2.1 does not work
in Windows because site.py fails to add the
site-package directory in sys.path





----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-05-09 12:32

Message:
Logged In: YES 
user_id=31435

Mark, has site-packages ever worked on Windows?  Not that I 
can recall.  Do you want it to (the patch appears to want 
it to work the way it works on Macintosh (classic) boxes)?


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=422329&group_id=5470


From noreply@sourceforge.net  Wed May  9 20:39:14 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 09 May 2001 12:39:14 -0700
Subject: [Patches] [ python-Patches-416251 ] 2.1c1 mmapmodule: unused vrbl cleanup
Message-ID: <E14xZnm-00064i-00@usw-sf-web3.sourceforge.net>

Patches item #416251, was updated on 2001-04-15 04:26
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416251&group_id=5470

Category: Modules
Group: None
>Status: Open
Resolution: Fixed
Priority: 5
Submitted By: Mark Favas (mfavas)
Assigned to: Tim Peters (tim_one)
Summary: 2.1c1 mmapmodule: unused vrbl cleanup

Initial Comment:
Variable set but unused

*** mmapmodule.c.orig   Sun Apr 15 18:37:16 2001
--- mmapmodule.c        Sun Apr 15 18:38:43 2001
***************
*** 163,169 ****
  mmap_read_byte_method(mmap_object *self,
                      PyObject *args)
  {
-       char value;
        char *where;
        CHECK_VALID(NULL);
          if (!PyArg_ParseTuple(args, ":read_byte"))
--- 163,168 ----
***************
*** 170,176 ****
                return NULL;
        if (self->pos < self->size) {
                where = self->data + self->pos;
-               value = (char) *(where);
                self->pos += 1;
                return Py_BuildValue("c", (char)
*(where));
        } else {
--- 169,174 ----


----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-05-09 12:39

Message:
Logged In: YES 
user_id=3066

Reopening -- the fix introduced breakage on Linux (kernel
2.2.17):

cj42289-a(.../python/linux-beowolf); ./python
../Lib/test/regrtest.py -v test_mmap
test_mmap
test_mmap
test test_mmap crashed -- exceptions.IOError: [Errno 22]
Invalid argument
Traceback (most recent call last):
  File "../Lib/test/regrtest.py", line 246, in runtest
    __import__(test, globals(), locals(), [])
  File "../Lib/test/test_mmap.py", line 124, in ?
    test_both()
  File "../Lib/test/test_mmap.py", line 14, in test_both
    f.write('\0'* PAGESIZE)
IOError: [Errno 22] Invalid argument
1 test failed: test_mmap


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-09 11:48

Message:
Logged In: YES 
user_id=31435

Checked in a similar change, to mmapmodule.c rev 2.29.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416251&group_id=5470


From noreply@sourceforge.net  Wed May  9 20:42:22 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 09 May 2001 12:42:22 -0700
Subject: [Patches] [ python-Patches-422383 ] typo fix in ref7.tex
Message-ID: <E14xZqo-0007dO-00@usw-sf-web2.sourceforge.net>

Patches item #422383, was updated on 2001-05-08 09:46
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=422383&group_id=5470

Category: documentation
Group: None
>Status: Closed
>Resolution: Rejected
Priority: 5
Submitted By: David Goodger (goodger)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: typo fix in ref7.tex

Initial Comment:
Doc/ref/ref7.tex

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-05-09 12:42

Message:
Logged In: YES 
user_id=3066

There is no patch and no description of a problem.  Please
submit a bug report or patch that contains a description of
the problem in case SF loses the patch file.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=422383&group_id=5470


From noreply@sourceforge.net  Wed May  9 20:48:10 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 09 May 2001 12:48:10 -0700
Subject: [Patches] [ python-Patches-416298 ] Fix in typo in WeakValueDictionary
Message-ID: <E14xZwQ-0007i3-00@usw-sf-web2.sourceforge.net>

Patches item #416298, was updated on 2001-04-15 12:14
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416298&group_id=5470

Category: Modules
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Fix in typo in WeakValueDictionary

Initial Comment:
There is a small error in weakref.WeakValueDictionary.

This error was found in 2.1c1, a quick look in the
april 15th build revealed it was not fixed.

Demonstration:

>>> class Spam:
...     pass
...
>>> dict = {'a':Spam()}
>>> weakref.WeakValueDictionary(dict)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File
"/usr/local/python-2.1c1/lib/python2.1/UserDict.py",
line 6, in __init__
    if dict is not None: self.update(dict)
  File
"/usr/local/python-2.1c1/lib/python2.1/weakref.py",
line 103, in update
    L.append(key, ref(o, remove))

Examination of the script reveals that the fix is obvious:

    def update(self, dict):
        d = self.data
        L = []
        for key, o in dict.items():
            def remove(o, data=d, key=key):
                del data[key]
            # L.append(key, ref(o, remove))
            # ^^^ erroneous ^^^^
            L.append((key, ref(o, remove)))
            # ^^^ right ^^^
        for key, r in L:
            d[key] = r


----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-05-09 12:48

Message:
Logged In: YES 
user_id=3066

This was fixed in Lib/weakref.py revision 1.8 (the version
included with Python 2.1).


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-04-17 21:36

Message:
Logged In: NO 

Ok, I submitted it the day before the 2.1 was released.

I has been fixed in the release. Nevermind.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-04-17 21:35

Message:
Logged In: NO 

Ok, I submitted it the day before the 2.1 was released.

I has been fixed in the release. Nevermind.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416298&group_id=5470


From noreply@sourceforge.net  Wed May  9 20:57:41 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 09 May 2001 12:57:41 -0700
Subject: [Patches] [ python-Patches-416250 ] 2.1c1 thread_pthread: unused vrbl  clean
Message-ID: <E14xa5d-0006KZ-00@usw-sf-web3.sourceforge.net>

Patches item #416250, was updated on 2001-04-15 04:25
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416250&group_id=5470

Category: None
Group: None
>Status: Closed
>Resolution: Rejected
Priority: 5
Submitted By: Mark Favas (mfavas)
>Assigned to: Tim Peters (tim_one)
Summary: 2.1c1 thread_pthread: unused vrbl  clean

Initial Comment:
Variables set but not used

*** thread_pthread.h.orig       Sun Apr 15 18:30:22
2001
--- thread_pthread.h    Sun Apr 15 18:32:02 2001
***************
*** 273,279 ****
  PyThread_free_lock(PyThread_type_lock lock)
  {
        pthread_lock *thelock = (pthread_lock *)lock;
!       int status, error = 0;
  
        dprintf(("PyThread_free_lock(%p) called\n",
lock));
  
--- 273,279 ----
  PyThread_free_lock(PyThread_type_lock lock)
  {
        pthread_lock *thelock = (pthread_lock *)lock;
!       int status;
  
        dprintf(("PyThread_free_lock(%p) called\n",
lock));
  
***************
*** 328,334 ****
  PyThread_release_lock(PyThread_type_lock lock)
  {
        pthread_lock *thelock = (pthread_lock *)lock;
!       int status, error = 0;
  
        dprintf(("PyThread_release_lock(%p) called\n",
lock));
  
--- 328,334 ----
  PyThread_release_lock(PyThread_type_lock lock)
  {
        pthread_lock *thelock = (pthread_lock *)lock;
!       int status;
  
        dprintf(("PyThread_release_lock(%p) called\n",
lock));
  
***************
*** 386,392 ****
  void 
  PyThread_free_sema(PyThread_type_sema sema)
  {
!       int status, error = 0;
        struct semaphore *thesema = (struct semaphore
*) sema;
  
        dprintf(("PyThread_free_sema(%p) called\n", 
sema));
--- 386,392 ----
  void 
  PyThread_free_sema(PyThread_type_sema sema)
  {
!       int status;
        struct semaphore *thesema = (struct semaphore
*) sema;
  
        dprintf(("PyThread_free_sema(%p) called\n", 
sema));
***************
*** 430,436 ****
  void 
  PyThread_up_sema(PyThread_type_sema sema)
  {
!       int status, error = 0;
        struct semaphore *thesema = (struct semaphore
*) sema;
  
        dprintf(("PyThread_up_sema(%p)\n",  sema));
--- 430,436 ----
  void 
  PyThread_up_sema(PyThread_type_sema sema)
  {
!       int status;
        struct semaphore *thesema = (struct semaphore
*) sema;
  
        dprintf(("PyThread_up_sema(%p)\n",  sema));


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-05-09 12:57

Message:
Logged In: YES 
user_id=31435

Rejected as requested.  But you could, e.g., instead change 
the "error = 1" part of the macro to "set_error(&error)" 
and define a

static void
set_error(int* error) {*error = 1;}

function near the top of the file.  Then the unused var 
wngs should go away, and the oost of an extra function call 
in case there *is* an error is insignificant.

If I had a pthreads box with a picky compiler to test it 
on, I'd do that myself.

----------------------------------------------------------------------

Comment By: Mark Favas (mfavas)
Date: 2001-04-15 04:36

Message:
Logged In: YES 
user_id=44979

Aaaaaaaaargh! Ignore this one - sorry! I rebuilt after
changing this, but thread.c (which depends on this include
file) was not rebuilt automatically (makefile dependency
needs fixing, I guess). Errors ensued when I recompiled
thread.c - error is set in the macro CHECK_STATUS and
sometimes used and sometimes not - would require making two
macros, so not worth doing.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416250&group_id=5470


From noreply@sourceforge.net  Wed May  9 20:58:40 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 09 May 2001 12:58:40 -0700
Subject: [Patches] [ python-Patches-418011 ] Updated zipfile docs
Message-ID: <E14xa6a-0002rD-00@usw-sf-web1.sourceforge.net>

Patches item #418011, was updated on 2001-04-22 07:54
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=418011&group_id=5470

Category: documentation
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Itamar Shtull-Trauring (itamar)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Updated zipfile docs

Initial Comment:
Updates zipfile.ZipFile's docs so it mentions that fact
you can open arbitary file-like objects.

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-05-09 12:58

Message:
Logged In: YES 
user_id=3066

Checked in as Doc/lib/libzipfile.tex revisions 1.9 and 1.8.6.1.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=418011&group_id=5470


From noreply@sourceforge.net  Wed May  9 21:06:12 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 09 May 2001 13:06:12 -0700
Subject: [Patches] [ python-Patches-416247 ] 2.1c1 stringobject: unused vrbl cleanup
Message-ID: <E14xaDs-0006Ro-00@usw-sf-web3.sourceforge.net>

Patches item #416247, was updated on 2001-04-15 04:18
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416247&group_id=5470

Category: core (C code)
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Mark Favas (mfavas)
>Assigned to: Tim Peters (tim_one)
Summary: 2.1c1 stringobject: unused vrbl cleanup

Initial Comment:
Variable set but unused:

*** stringobject.c.orig Sun Apr 15 17:51:21 2001
--- stringobject.c      Sun Apr 15 18:10:26 2001
***************
*** 2758,2764 ****
                        int flags = 0;
                        int width = -1;
                        int prec = -1;
-                       int size = 0;
                        int c = '\0';
                        int fill;
                        PyObject *v = NULL;
--- 2758,2763 ----
***************
*** 2895,2901 ****
                        } /* prec */
                        if (fmtcnt >= 0) {
                                if (c == 'h' || c ==
'l' || c == 'L') {
-                                       size = c;
                                        if (--fmtcnt >=
0)
                                                c =
*fmt++;
                                }
--- 2894,2899 ----


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-05-09 13:06

Message:
Logged In: YES 
user_id=31435

Thanks -- applied to stringobject.c, rev 2.113.

Mark, in the future could you attach patch files instead?  
It's impossible to extract patches from the SF web view 
(leading whitespace destroyed), and in this case the email 
version was mangled too (line wrap).

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416247&group_id=5470


From noreply@sourceforge.net  Wed May  9 21:25:56 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 09 May 2001 13:25:56 -0700
Subject: [Patches] [ python-Patches-416251 ] 2.1c1 mmapmodule: unused vrbl cleanup
Message-ID: <E14xaWy-0008F3-00@usw-sf-web2.sourceforge.net>

Patches item #416251, was updated on 2001-04-15 04:26
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416251&group_id=5470

Category: Modules
Group: None
Status: Open
Resolution: Fixed
Priority: 5
Submitted By: Mark Favas (mfavas)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: 2.1c1 mmapmodule: unused vrbl cleanup

Initial Comment:
Variable set but unused

*** mmapmodule.c.orig   Sun Apr 15 18:37:16 2001
--- mmapmodule.c        Sun Apr 15 18:38:43 2001
***************
*** 163,169 ****
  mmap_read_byte_method(mmap_object *self,
                      PyObject *args)
  {
-       char value;
        char *where;
        CHECK_VALID(NULL);
          if (!PyArg_ParseTuple(args, ":read_byte"))
--- 163,168 ----
***************
*** 170,176 ****
                return NULL;
        if (self->pos < self->size) {
                where = self->data + self->pos;
-               value = (char) *(where);
                self->pos += 1;
                return Py_BuildValue("c", (char)
*(where));
        } else {
--- 169,174 ----


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-05-09 13:25

Message:
Logged In: YES 
user_id=31435

Could you please look at the "before" and "after" code and 
try to guess why?

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-05-09 12:39

Message:
Logged In: YES 
user_id=3066

Reopening -- the fix introduced breakage on Linux (kernel
2.2.17):

cj42289-a(.../python/linux-beowolf); ./python
../Lib/test/regrtest.py -v test_mmap
test_mmap
test_mmap
test test_mmap crashed -- exceptions.IOError: [Errno 22]
Invalid argument
Traceback (most recent call last):
  File "../Lib/test/regrtest.py", line 246, in runtest
    __import__(test, globals(), locals(), [])
  File "../Lib/test/test_mmap.py", line 124, in ?
    test_both()
  File "../Lib/test/test_mmap.py", line 14, in test_both
    f.write('\0'* PAGESIZE)
IOError: [Errno 22] Invalid argument
1 test failed: test_mmap


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-09 11:48

Message:
Logged In: YES 
user_id=31435

Checked in a similar change, to mmapmodule.c rev 2.29.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416251&group_id=5470


From noreply@sourceforge.net  Thu May 10 02:31:35 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 09 May 2001 18:31:35 -0700
Subject: [Patches] [ python-Patches-418489 ] unittest string format error
Message-ID: <E14xfIl-0003YW-00@usw-sf-web2.sourceforge.net>

Patches item #418489, was updated on 2001-04-23 23:58
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=418489&group_id=5470

Category: library
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Andrew Dalke (dalke)
Assigned to: Steve Purcell (purcell)
Summary: unittest string format error

Initial Comment:
unittest.loadTestsFromName has a string format error
of the form - it needs some parens.  Currently is:

 raise ValueError, \
    "calling %s returned %s, not a test" % obj,test

should be

 raise ValueError, \
   "calling %s returned %s, not a test" % (obj,test)

Let's see if this really will let me upload a patch.

Index: unittest.py
=======================================================
============
RCS 
file: /cvsroot/python/python/dist/src/Lib/unittest.py,v
retrieving revision 1.7
diff -c -r1.7 unittest.py
*** unittest.py 2001/04/15 09:18:32     1.7
--- unittest.py 2001/04/24 06:57:32
***************
*** 443,449 ****
              if not isinstance(test, TestCase) and \
                 not isinstance(test, TestSuite):
                  raise ValueError, \
!                       "calling %s returned %s, not a 
test" % obj,test
              return test
          else:
              raise ValueError, "don't know how to 
make test from: %s" % obj
--- 443,449 ----
              if not isinstance(test, TestCase) and \
                 not isinstance(test, TestSuite):
                  raise ValueError, \
!                       "calling %s returned %s, not a 
test" % (obj, test)
              return test
          else:
              raise ValueError, "don't know how to 
make test from: %s" % obj


----------------------------------------------------------------------

>Comment By: Steve Purcell (purcell)
Date: 2001-05-09 18:31

Message:
Logged In: YES 
user_id=21477

Thanks Andrew.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=418489&group_id=5470


From noreply@sourceforge.net  Thu May 10 05:27:41 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 09 May 2001 21:27:41 -0700
Subject: [Patches] [ python-Patches-422383 ] typo fix in ref7.tex
Message-ID: <E14xi3B-0002te-00@usw-sf-web1.sourceforge.net>

Patches item #422383, was updated on 2001-05-08 09:46
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=422383&group_id=5470

Category: documentation
Group: None
Status: Closed
Resolution: Rejected
Priority: 5
Submitted By: David Goodger (goodger)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: typo fix in ref7.tex

Initial Comment:
Doc/ref/ref7.tex

----------------------------------------------------------------------

>Comment By: David Goodger (goodger)
Date: 2001-05-09 21:27

Message:
Logged In: YES 
user_id=7733

There *was* a patch file attached. Is it common for 
SourceForge to lose them? If so, sounds like a bug 
report is due on SourceForge itself. Most discouraging.

Patch description: find a triple-backquote at the end of 
Doc/ref/ref7.tex and change the last backquote to a 
backslash. That's it.

Shall I regenerate the patch and resubmit?

One-byte typo fix, look at all this bandwidth wasted on it. 
Sad.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-05-09 12:42

Message:
Logged In: YES 
user_id=3066

There is no patch and no description of a problem.  Please
submit a bug report or patch that contains a description of
the problem in case SF loses the patch file.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=422383&group_id=5470


From noreply@sourceforge.net  Thu May 10 07:30:28 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 09 May 2001 23:30:28 -0700
Subject: [Patches] [ python-Patches-422329 ] Python 2.1 site.py patch
Message-ID: <E14xjy0-00074N-00@usw-sf-web2.sourceforge.net>

Patches item #422329, was updated on 2001-05-08 08:03
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=422329&group_id=5470

Category: library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Gleen Aduana (gleen)
Assigned to: Mark Hammond (mhammond)
Summary: Python 2.1 site.py patch

Initial Comment:
site-package support in Python 2.1 does not work
in Windows because site.py fails to add the
site-package directory in sys.path





----------------------------------------------------------------------

>Comment By: Gleen Aduana (gleen)
Date: 2001-05-09 23:30

Message:
Logged In: YES 
user_id=214628

It seems that PEP 250 (for release 2.2) addresses 
the same issue but was too late to have been included 
in release 2.1-final.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-09 12:32

Message:
Logged In: YES 
user_id=31435

Mark, has site-packages ever worked on Windows?  Not that I 
can recall.  Do you want it to (the patch appears to want 
it to work the way it works on Macintosh (classic) boxes)?


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=422329&group_id=5470


From noreply@sourceforge.net  Thu May 10 15:19:57 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 10 May 2001 07:19:57 -0700
Subject: [Patches] [ python-Patches-416251 ] 2.1c1 mmapmodule: unused vrbl cleanup
Message-ID: <E14xrIL-0004iC-00@usw-sf-web2.sourceforge.net>

Patches item #416251, was updated on 2001-04-15 04:26
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416251&group_id=5470

Category: Modules
Group: None
>Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Mark Favas (mfavas)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: 2.1c1 mmapmodule: unused vrbl cleanup

Initial Comment:
Variable set but unused

*** mmapmodule.c.orig   Sun Apr 15 18:37:16 2001
--- mmapmodule.c        Sun Apr 15 18:38:43 2001
***************
*** 163,169 ****
  mmap_read_byte_method(mmap_object *self,
                      PyObject *args)
  {
-       char value;
        char *where;
        CHECK_VALID(NULL);
          if (!PyArg_ParseTuple(args, ":read_byte"))
--- 163,168 ----
***************
*** 170,176 ****
                return NULL;
        if (self->pos < self->size) {
                where = self->data + self->pos;
-               value = (char) *(where);
                self->pos += 1;
                return Py_BuildValue("c", (char)
*(where));
        } else {
--- 169,174 ----


----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-05-10 07:19

Message:
Logged In: YES 
user_id=3066

Trouble found -- this was a bogosity on my part (which is
better than the alternatives, I suppose).

The mmap test creates a temporary file named "foo" in the
"w+" mode; I happened to have created a named pipe named
"foo" in the same directory while working on another bug and
had failed to clean it up.  So of course most operations on
it as a normal file object were pretty bogus!  ;-)

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-09 13:25

Message:
Logged In: YES 
user_id=31435

Could you please look at the "before" and "after" code and 
try to guess why?

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-05-09 12:39

Message:
Logged In: YES 
user_id=3066

Reopening -- the fix introduced breakage on Linux (kernel
2.2.17):

cj42289-a(.../python/linux-beowolf); ./python
../Lib/test/regrtest.py -v test_mmap
test_mmap
test_mmap
test test_mmap crashed -- exceptions.IOError: [Errno 22]
Invalid argument
Traceback (most recent call last):
  File "../Lib/test/regrtest.py", line 246, in runtest
    __import__(test, globals(), locals(), [])
  File "../Lib/test/test_mmap.py", line 124, in ?
    test_both()
  File "../Lib/test/test_mmap.py", line 14, in test_both
    f.write('\0'* PAGESIZE)
IOError: [Errno 22] Invalid argument
1 test failed: test_mmap


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-09 11:48

Message:
Logged In: YES 
user_id=31435

Checked in a similar change, to mmapmodule.c rev 2.29.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416251&group_id=5470


From noreply@sourceforge.net  Thu May 10 16:12:18 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 10 May 2001 08:12:18 -0700
Subject: [Patches] [ python-Patches-422383 ] typo fix in ref7.tex
Message-ID: <E14xs70-0004yp-00@usw-sf-web1.sourceforge.net>

Patches item #422383, was updated on 2001-05-08 09:46
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=422383&group_id=5470

Category: documentation
Group: None
Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: David Goodger (goodger)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: typo fix in ref7.tex

Initial Comment:
Doc/ref/ref7.tex

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-05-10 08:12

Message:
Logged In: YES 
user_id=3066

OK, fixed in Doc/ref/ref7.tex revisions 1.25 and 1.24.2.1;
thanks!

I'm not sure why SF loses patches sometimes; I think it
depends on how the bug/patch is submitted.  I think this has
been reported, but haven't had time to go look.

----------------------------------------------------------------------

Comment By: David Goodger (goodger)
Date: 2001-05-09 21:27

Message:
Logged In: YES 
user_id=7733

There *was* a patch file attached. Is it common for 
SourceForge to lose them? If so, sounds like a bug 
report is due on SourceForge itself. Most discouraging.

Patch description: find a triple-backquote at the end of 
Doc/ref/ref7.tex and change the last backquote to a 
backslash. That's it.

Shall I regenerate the patch and resubmit?

One-byte typo fix, look at all this bandwidth wasted on it. 
Sad.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-05-09 12:42

Message:
Logged In: YES 
user_id=3066

There is no patch and no description of a problem.  Please
submit a bug report or patch that contains a description of
the problem in case SF loses the patch file.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=422383&group_id=5470


From noreply@sourceforge.net  Thu May 10 20:44:46 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 10 May 2001 12:44:46 -0700
Subject: [Patches] [ python-Patches-423139 ] webbrowser.py fix for konqueror
Message-ID: <E14xwMg-0000g5-00@usw-sf-web2.sourceforge.net>

Patches item #423139, was updated on 2001-05-10 12:44
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=423139&group_id=5470

Category: library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Joseph VanAndel (vanandel)
Assigned to: Nobody/Anonymous (nobody)
Summary: webbrowser.py fix for konqueror

Initial Comment:
The 2.1 version of webbrowser.py uses kfmclient, and
opens a new Konqueror window for each 'open' call.

This patched version of webbrowser.py uses the KDE
command line utility 'dcop' to either open a URL in an
existing Konqueror window, or to open a new window.

pydoc is much more useful with this version of
webbrowser.py

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=423139&group_id=5470


From noreply@sourceforge.net  Thu May 10 20:44:58 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 10 May 2001 12:44:58 -0700
Subject: [Patches] [ python-Patches-423140 ] adds encode- and decodestring to quopri
Message-ID: <E14xwMs-0000gJ-00@usw-sf-web2.sourceforge.net>

Patches item #423140, was updated on 2001-05-10 12:44
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=423140&group_id=5470

Category: library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Aluo Nowu (etoffi)
Assigned to: Nobody/Anonymous (nobody)
Summary: adds encode- and decodestring to quopri

Initial Comment:
i added this to match base64.py

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=423140&group_id=5470


From noreply@sourceforge.net  Thu May 10 20:52:22 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 10 May 2001 12:52:22 -0700
Subject: [Patches] [ python-Patches-423140 ] adds encode- and decodestring to quopri
Message-ID: <E14xwU2-0007Rx-00@usw-sf-web3.sourceforge.net>

Patches item #423140, was updated on 2001-05-10 12:44
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=423140&group_id=5470

Category: library
Group: None
Status: Open
Resolution: None
>Priority: 3
Submitted By: Aluo Nowu (etoffi)
Assigned to: Nobody/Anonymous (nobody)
Summary: adds encode- and decodestring to quopri

Initial Comment:
i added this to match base64.py

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=423140&group_id=5470


From noreply@sourceforge.net  Thu May 10 22:16:23 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 10 May 2001 14:16:23 -0700
Subject: [Patches] [ python-Patches-416704 ] More robust freeze
Message-ID: <E14xxnL-0008WI-00@usw-sf-web3.sourceforge.net>

Patches item #416704, was updated on 2001-04-17 07:24
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416704&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Toby Dickenson (htrd)
>Assigned to: Mark Hammond (mhammond)
Summary: More robust freeze

Initial Comment:
This patch addresses three issues, all relating to 
robustness of frozen programs.

Specifically, this patch allows explicit and complete 
control over which modules may be loaded from source 
on the filesystem of the host system where the frozen 
program is run, and which may not.

Without this patch it is impossible to create a non-
trivial frozen program which will *never* load a 
module from source on the filesystem.



1. A patch to correct bug #404545 (frozen package 
import uses wrong files). Under this change, 
submodules of a frozen package must themselves be 
frozen modules. Previously, the import machinery may 
also try to import submodules from curiously named 
files (packagename.modulename.py) from directories in 
sys.path


2. A patch to add an extra command line option -E to 
freeze.py, which forces freeze to terminate with an 
error message if there are modules that it can not 
locate.

If this switch is not specified then the default 
behaviour is unchanged: modules which can not be found 
by freeze will not be included in the frozen program, 
and the import machinery will try to load them from 
source on sys.path when the frozen program is run.

In practice we have found that a missing module is 
probably an error (and it is a fairly frequent error 
too!). The -E switch can be used to detect this error; 
any missing modules will cause freeze.py to fail.

In the rare case of a frozen module importing a non-
frozen one (ie one which should be loaded from source 
when the program is run), the non-frozen module must 
be excluded from the freeze using the -x option.


3. A patch to add an extra command line option -X to 
freeze.py, which indicates that a specified module is 
excluded from the freeze, and also that the frozen 
program should not try to load the module from 
sys.path when it is imported. Importing the specified 
module will always trigger an ImportError.

This is useful if a module used by a frozen program 
can optionally use a submodule...
try:
    import optional_submodule
except ImportError:
    pass

It may be preferable for the frozen program's 
behaviour to not depend on whether optional_submodule 
happens to be installed on the host system, and that 
the 'import optional_submodule' should always fail 
with an ImportError. This can be achieved using the '-
X optional_submodule' command line switch to freeze.py

This is implemented by including the excluded module 
in the frozen imports table (_PyImport_FrozenModules), 
with the code pointer set to NULL.




----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416704&group_id=5470


From noreply@sourceforge.net  Thu May 10 22:17:14 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 10 May 2001 14:17:14 -0700
Subject: [Patches] [ python-Patches-413171 ] fix UserDict.get, setdefault, update
Message-ID: <E14xxoA-00005N-00@usw-sf-web3.sourceforge.net>

Patches item #413171, was updated on 2001-04-02 10:18
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=413171&group_id=5470

Category: library
Group: None
Status: Open
Resolution: Postponed
Priority: 4
Submitted By: Ka-Ping Yee (ping)
>Assigned to: Ka-Ping Yee (ping)
Summary: fix UserDict.get, setdefault, update

Initial Comment:
The methods 'get', 'setdefault', and 'update'
on a dictionary are usually implemented (and
thought of) in terms of the lower-level methods
has_key, __getitem__, and __setitem__.  The
current implementation of UserDict relays a
call to e.g. x.get() to x.data.get(), which
behaves inconsistently if __getitem__ has been
implemented on x.

One particular big place where this turns up is cgi.
If you get a dict = cgi.SvFormContentDict(), then
dict.get('key') will return a *list* even though
dict['key'] returns a single item!

To make UserDict behave consistently, this patch
fixes get(), update(), and setdefault() to re-use
the other methods.  Then the only occurrence of
self.data[k] = v is in __setitem__, the only
occurrence of self.data[k] without assignment is
in __getitem__, etc.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-10 14:17

Message:
Logged In: YES 
user_id=6380

Let's not fix this in 2.1.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=413171&group_id=5470


From noreply@sourceforge.net  Thu May 10 23:39:11 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 10 May 2001 15:39:11 -0700
Subject: [Patches] [ python-Patches-423181 ] small speedup in object rich comparisons
Message-ID: <E14xz5T-00030k-00@usw-sf-web2.sourceforge.net>

Patches item #423181, was updated on 2001-05-10 15:39
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=423181&group_id=5470

Category: core (C code)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeremy Hylton (jhylton)
Assigned to: Tim Peters (tim_one)
Summary: small speedup in object rich comparisons

Initial Comment:
One thing that jumped out at me when I profiled
test_mutant is how often PyErr_Format() was called.  It
ends up that the rich comparisons code does a lot of
lookups for methods like __lt__ and __gt__ and usually
doesn't find them.  It uses PyObject_GetAttr() for the
lookups, so it goes to the expense of creating a Python
string with a nice error message.

This patch uses the internal instance_getattr2 when it
can, i.e. when the instance doesn't define
__getattr__.  This function won't find __dict__ or
__class__, won't do rexec checks, won't call
__getattr__, and (best of all) won't set an exception.

Unfortunately, test_mutants sees only a small speedup
as a result -- about six percent.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=423181&group_id=5470


From noreply@sourceforge.net  Fri May 11 00:32:37 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 10 May 2001 16:32:37 -0700
Subject: [Patches] [ python-Patches-423181 ] small speedup in object rich comparisons
Message-ID: <E14xzvB-0001mN-00@usw-sf-web3.sourceforge.net>

Patches item #423181, was updated on 2001-05-10 15:39
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=423181&group_id=5470

Category: core (C code)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeremy Hylton (jhylton)
Assigned to: Tim Peters (tim_one)
Summary: small speedup in object rich comparisons

Initial Comment:
One thing that jumped out at me when I profiled
test_mutant is how often PyErr_Format() was called.  It
ends up that the rich comparisons code does a lot of
lookups for methods like __lt__ and __gt__ and usually
doesn't find them.  It uses PyObject_GetAttr() for the
lookups, so it goes to the expense of creating a Python
string with a nice error message.

This patch uses the internal instance_getattr2 when it
can, i.e. when the instance doesn't define
__getattr__.  This function won't find __dict__ or
__class__, won't do rexec checks, won't call
__getattr__, and (best of all) won't set an exception.

Unfortunately, test_mutants sees only a small speedup
as a result -- about six percent.


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-05-10 16:32

Message:
Logged In: YES 
user_id=31435

Cool!  I'll check this out.

Another interesting thing about the test_mutants profile 
was that it spent no measurable time at all in the dict 
comparison code (dict_compare() + dict_richcompare() + 
dict_equal() + characterize() times summed to 0) -- which 
kinda explains why my efforts to speed those had no 
measurable effect <wink/sigh>.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=423181&group_id=5470


From noreply@sourceforge.net  Fri May 11 01:21:51 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 10 May 2001 17:21:51 -0700
Subject: [Patches] [ python-Patches-423181 ] small speedup in object rich comparisons
Message-ID: <E14y0gp-0004KK-00@usw-sf-web2.sourceforge.net>

Patches item #423181, was updated on 2001-05-10 15:39
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=423181&group_id=5470

Category: core (C code)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeremy Hylton (jhylton)
Assigned to: Tim Peters (tim_one)
Summary: small speedup in object rich comparisons

Initial Comment:
One thing that jumped out at me when I profiled
test_mutant is how often PyErr_Format() was called.  It
ends up that the rich comparisons code does a lot of
lookups for methods like __lt__ and __gt__ and usually
doesn't find them.  It uses PyObject_GetAttr() for the
lookups, so it goes to the expense of creating a Python
string with a nice error message.

This patch uses the internal instance_getattr2 when it
can, i.e. when the instance doesn't define
__getattr__.  This function won't find __dict__ or
__class__, won't do rexec checks, won't call
__getattr__, and (best of all) won't set an exception.

Unfortunately, test_mutants sees only a small speedup
as a result -- about six percent.


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-05-10 17:21

Message:
Logged In: YES 
user_id=31435

Another odd thing:  there are way more calls to 
string_compare() than I would expect in this nearly string-
free program <wink>.  One cause:  half_richcompare has a 
table of special operator names:

static char *name_op[] = {
	"__lt__",
	"__le__",
	"__eq__",
	"__ne__",
	"__gt__",
	"__ge__",
};

and does this at the start:

name = PyString_InternFromString(name_op[op]);

That *always* ends up calling PyDict_GetItem(), and then 
string_compare() one or more times, for the obvious reason 
(i.e., the interning work is wasted because it doesn't get 
reflected back into the name_op table).

Interning isn't buying us anything for module attribute 
lookups either, because module_getattr takes a char* 
argument (i.e., this is another frequent cause of 
string_compare() calls in this program, due to lots of 
random.this() and random.that() calls, and they always end 
up getting resolved via string_compare()).

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-10 16:32

Message:
Logged In: YES 
user_id=31435

Cool!  I'll check this out.

Another interesting thing about the test_mutants profile 
was that it spent no measurable time at all in the dict 
comparison code (dict_compare() + dict_richcompare() + 
dict_equal() + characterize() times summed to 0) -- which 
kinda explains why my efforts to speed those had no 
measurable effect <wink/sigh>.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=423181&group_id=5470


From noreply@sourceforge.net  Fri May 11 05:14:03 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 10 May 2001 21:14:03 -0700
Subject: [Patches] [ python-Patches-423221 ] Add a few Windows encoding aliases
Message-ID: <E14y4JX-0006zq-00@usw-sf-web2.sourceforge.net>

Patches item #423221, was updated on 2001-05-10 21:14
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=423221&group_id=5470

Category: library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Brian Quinlan (bquinlan)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add a few Windows encoding aliases

Initial Comment:
This patch adds aliases for some of the common Windows 
encodings. Windows-1252 is particularly useful because 
it is the default encoding used by Visual Studio .NET 
projects. 

Microsoft's complete encoding list can be found at:
http://msdn.microsoft.com/workshop/author/dhtml/referen
ce/charsets/charset4.asp


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=423221&group_id=5470


From noreply@sourceforge.net  Fri May 11 05:53:51 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 10 May 2001 21:53:51 -0700
Subject: [Patches] [ python-Patches-423224 ] unittest fixture finder
Message-ID: <E14y4w3-0005QZ-00@usw-sf-web3.sourceforge.net>

Patches item #423224, was updated on 2001-05-10 21:53
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=423224&group_id=5470

Category: Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Benjamin Saller (bcsaller)
Assigned to: Nobody/Anonymous (nobody)
Summary: unittest fixture finder

Initial Comment:
Some times it is helpful to know the directory that 
tests are being run from so that they can collect 
their test data. If for example you have a parser and 
some test files finding those file reguardless of how 
the test is called is helpful to the test author.

TestCase has been extended to allow for this. When a 
testCase instance needs to find a data file relative 
to itself it can now say

class TestFoo(TestCase):
  def checkFoo(self):   
   dirname = self.getPath()
   # or
   filename = self.getPath("foo.data")

If TestFoo.py is in /home/user/python/tests then
dirname == /home/user/python/tests 
and 
filename == /home/user/python/tests/foo.data


There is not cost if this feature is not invoked.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=423224&group_id=5470


From noreply@sourceforge.net  Fri May 11 06:02:22 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 10 May 2001 22:02:22 -0700
Subject: [Patches] [ python-Patches-423181 ] small speedup in object rich comparisons
Message-ID: <E14y54I-0005Wz-00@usw-sf-web3.sourceforge.net>

Patches item #423181, was updated on 2001-05-10 15:39
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=423181&group_id=5470

Category: core (C code)
Group: None
Status: Open
>Resolution: Accepted
Priority: 5
Submitted By: Jeremy Hylton (jhylton)
Assigned to: Tim Peters (tim_one)
Summary: small speedup in object rich comparisons

Initial Comment:
One thing that jumped out at me when I profiled
test_mutant is how often PyErr_Format() was called.  It
ends up that the rich comparisons code does a lot of
lookups for methods like __lt__ and __gt__ and usually
doesn't find them.  It uses PyObject_GetAttr() for the
lookups, so it goes to the expense of creating a Python
string with a nice error message.

This patch uses the internal instance_getattr2 when it
can, i.e. when the instance doesn't define
__getattr__.  This function won't find __dict__ or
__class__, won't do rexec checks, won't call
__getattr__, and (best of all) won't set an exception.

Unfortunately, test_mutants sees only a small speedup
as a result -- about six percent.


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-05-10 22:02

Message:
Logged In: YES 
user_id=31435

Marked Accepted.  I'd be happier with

1) A comment in the *code* explaining why instance_getattr2 
is called.

2) assert(!PyErr_Occurred()) after getting back with a NULL 
result (no cost in release builds, potentially helpful in 
debug builds).

3) A general rewrite of the whole attribute lookup 
mechanism that doesn't force anyone to pay for stuff they 
later need to undo -- plus that never does string 
comparisons.

I'll settle for #3 alone, though <wink>.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-10 17:21

Message:
Logged In: YES 
user_id=31435

Another odd thing:  there are way more calls to 
string_compare() than I would expect in this nearly string-
free program <wink>.  One cause:  half_richcompare has a 
table of special operator names:

static char *name_op[] = {
	"__lt__",
	"__le__",
	"__eq__",
	"__ne__",
	"__gt__",
	"__ge__",
};

and does this at the start:

name = PyString_InternFromString(name_op[op]);

That *always* ends up calling PyDict_GetItem(), and then 
string_compare() one or more times, for the obvious reason 
(i.e., the interning work is wasted because it doesn't get 
reflected back into the name_op table).

Interning isn't buying us anything for module attribute 
lookups either, because module_getattr takes a char* 
argument (i.e., this is another frequent cause of 
string_compare() calls in this program, due to lots of 
random.this() and random.that() calls, and they always end 
up getting resolved via string_compare()).

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-10 16:32

Message:
Logged In: YES 
user_id=31435

Cool!  I'll check this out.

Another interesting thing about the test_mutants profile 
was that it spent no measurable time at all in the dict 
comparison code (dict_compare() + dict_richcompare() + 
dict_equal() + characterize() times summed to 0) -- which 
kinda explains why my efforts to speed those had no 
measurable effect <wink/sigh>.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=423181&group_id=5470


From noreply@sourceforge.net  Fri May 11 09:05:13 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 11 May 2001 01:05:13 -0700
Subject: [Patches] [ python-Patches-419648 ] Carbon support for distutils on Mac
Message-ID: <E14y7vF-0001HT-00@usw-sf-web2.sourceforge.net>

Patches item #419648, was updated on 2001-04-27 15:15
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=419648&group_id=5470

Category: distutils
Group: 2.0.1 bugfix
Status: Open
Resolution: None
Priority: 7
Submitted By: Jack Jansen (jackjansen)
Assigned to: Nobody/Anonymous (nobody)
Summary: Carbon support for distutils on Mac

Initial Comment:
Carbon support for distutils on the mac was somehow not checked in. MacPython from 2.1
onwards needs this.


----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2001-05-11 01:05

Message:
Logged In: YES 
user_id=45365

Well, when I started porting distutils to the Mac Greg said
he'd prefer me to supply patches than check in things
myself.

I'll give him (or anyone else) a few days more and then I'll
apply it myself.

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2001-05-09 09:14

Message:
Logged In: YES 
user_id=31392

Is there a reason you don't check this in yourself, Jack?


----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2001-04-27 15:43

Message:
Logged In: YES 
user_id=45365




----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=419648&group_id=5470


From noreply@sourceforge.net  Fri May 11 10:11:42 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 11 May 2001 02:11:42 -0700
Subject: [Patches] [ python-Patches-423262 ] Change module attribute get & set
Message-ID: <E14y8xa-0005G1-00@usw-sf-web1.sourceforge.net>

Patches item #423262, was updated on 2001-05-11 02:11
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=423262&group_id=5470

Category: core (C code)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Guido van Rossum (gvanrossum)
Summary: Change module attribute get & set

Initial Comment:
Module objects currently don't define the tp_getattro 
or tp_setattro slots.  As a result, interning of 
attribute names does them no good:  a char* is always 
passed, so the dict lookup always needs to do a string 
compare despite that the attribute name is interned.

The patch simply implements these slots, and nulls out 
the raw-string tp_getattr and tp_setattr slots.

The former is by far the more important one, and I've 
measured speedups over 25% for simple programs that do 
lots of module lookups inside loops (random.random, 
os.path, etc).

So, sure looks like a big cheap win to me, but 
assigning for review in case I'm missing something 
obvious (i.e., if it's such an easy win, why didn't we 
already do it?).


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=423262&group_id=5470


From noreply@sourceforge.net  Fri May 11 14:35:08 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 11 May 2001 06:35:08 -0700
Subject: [Patches] [ python-Patches-423262 ] Change module attribute get & set
Message-ID: <E14yD4W-0001Al-00@usw-sf-web1.sourceforge.net>

Patches item #423262, was updated on 2001-05-11 02:11
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=423262&group_id=5470

Category: core (C code)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Guido van Rossum (gvanrossum)
Summary: Change module attribute get & set

Initial Comment:
Module objects currently don't define the tp_getattro 
or tp_setattro slots.  As a result, interning of 
attribute names does them no good:  a char* is always 
passed, so the dict lookup always needs to do a string 
compare despite that the attribute name is interned.

The patch simply implements these slots, and nulls out 
the raw-string tp_getattr and tp_setattr slots.

The former is by far the more important one, and I've 
measured speedups over 25% for simple programs that do 
lots of module lookups inside loops (random.random, 
os.path, etc).

So, sure looks like a big cheap win to me, but 
assigning for review in case I'm missing something 
obvious (i.e., if it's such an easy win, why didn't we 
already do it?).


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-05-11 06:35

Message:
Logged In: YES 
user_id=6380

There's no deep reason -- this code is ancient and has never
drawn anybody's attention.  I noticed the same thing while
doing a review of getattr vs. getattro for the descr-branch
code.

So I'd say, go for it!

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=423262&group_id=5470


From noreply@sourceforge.net  Fri May 11 14:35:28 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 11 May 2001 06:35:28 -0700
Subject: [Patches] [ python-Patches-423262 ] Change module attribute get & set
Message-ID: <E14yD4q-0001Au-00@usw-sf-web1.sourceforge.net>

Patches item #423262, was updated on 2001-05-11 02:11
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=423262&group_id=5470

Category: core (C code)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Peters (tim_one)
>Assigned to: Tim Peters (tim_one)
Summary: Change module attribute get & set

Initial Comment:
Module objects currently don't define the tp_getattro 
or tp_setattro slots.  As a result, interning of 
attribute names does them no good:  a char* is always 
passed, so the dict lookup always needs to do a string 
compare despite that the attribute name is interned.

The patch simply implements these slots, and nulls out 
the raw-string tp_getattr and tp_setattr slots.

The former is by far the more important one, and I've 
measured speedups over 25% for simple programs that do 
lots of module lookups inside loops (random.random, 
os.path, etc).

So, sure looks like a big cheap win to me, but 
assigning for review in case I'm missing something 
obvious (i.e., if it's such an easy win, why didn't we 
already do it?).


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-05-11 06:35

Message:
Logged In: YES 
user_id=6380

There's no deep reason -- this code is ancient and has never
drawn anybody's attention.  I noticed the same thing while
doing a review of getattr vs. getattro for the descr-branch
code.

So I'd say, go for it!

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=423262&group_id=5470


From noreply@sourceforge.net  Fri May 11 14:36:55 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 11 May 2001 06:36:55 -0700
Subject: [Patches] [ python-Patches-423181 ] small speedup in object rich comparisons
Message-ID: <E14yD6F-0001C2-00@usw-sf-web1.sourceforge.net>

Patches item #423181, was updated on 2001-05-10 15:39
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=423181&group_id=5470

Category: core (C code)
Group: None
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Jeremy Hylton (jhylton)
>Assigned to: Jeremy Hylton (jhylton)
Summary: small speedup in object rich comparisons

Initial Comment:
One thing that jumped out at me when I profiled
test_mutant is how often PyErr_Format() was called.  It
ends up that the rich comparisons code does a lot of
lookups for methods like __lt__ and __gt__ and usually
doesn't find them.  It uses PyObject_GetAttr() for the
lookups, so it goes to the expense of creating a Python
string with a nice error message.

This patch uses the internal instance_getattr2 when it
can, i.e. when the instance doesn't define
__getattr__.  This function won't find __dict__ or
__class__, won't do rexec checks, won't call
__getattr__, and (best of all) won't set an exception.

Unfortunately, test_mutants sees only a small speedup
as a result -- about six percent.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-10 22:02

Message:
Logged In: YES 
user_id=31435

Marked Accepted.  I'd be happier with

1) A comment in the *code* explaining why instance_getattr2 
is called.

2) assert(!PyErr_Occurred()) after getting back with a NULL 
result (no cost in release builds, potentially helpful in 
debug builds).

3) A general rewrite of the whole attribute lookup 
mechanism that doesn't force anyone to pay for stuff they 
later need to undo -- plus that never does string 
comparisons.

I'll settle for #3 alone, though <wink>.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-10 17:21

Message:
Logged In: YES 
user_id=31435

Another odd thing:  there are way more calls to 
string_compare() than I would expect in this nearly string-
free program <wink>.  One cause:  half_richcompare has a 
table of special operator names:

static char *name_op[] = {
	"__lt__",
	"__le__",
	"__eq__",
	"__ne__",
	"__gt__",
	"__ge__",
};

and does this at the start:

name = PyString_InternFromString(name_op[op]);

That *always* ends up calling PyDict_GetItem(), and then 
string_compare() one or more times, for the obvious reason 
(i.e., the interning work is wasted because it doesn't get 
reflected back into the name_op table).

Interning isn't buying us anything for module attribute 
lookups either, because module_getattr takes a char* 
argument (i.e., this is another frequent cause of 
string_compare() calls in this program, due to lots of 
random.this() and random.that() calls, and they always end 
up getting resolved via string_compare()).

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-10 16:32

Message:
Logged In: YES 
user_id=31435

Cool!  I'll check this out.

Another interesting thing about the test_mutants profile 
was that it spent no measurable time at all in the dict 
comparison code (dict_compare() + dict_richcompare() + 
dict_equal() + characterize() times summed to 0) -- which 
kinda explains why my efforts to speed those had no 
measurable effect <wink/sigh>.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=423181&group_id=5470


From noreply@sourceforge.net  Fri May 11 14:37:33 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 11 May 2001 06:37:33 -0700
Subject: [Patches] [ python-Patches-419648 ] Carbon support for distutils on Mac
Message-ID: <E14yD6r-0001DH-00@usw-sf-web1.sourceforge.net>

Patches item #419648, was updated on 2001-04-27 15:15
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=419648&group_id=5470

Category: distutils
Group: 2.0.1 bugfix
Status: Open
Resolution: None
Priority: 7
Submitted By: Jack Jansen (jackjansen)
>Assigned to: Greg Ward (gward)
Summary: Carbon support for distutils on Mac

Initial Comment:
Carbon support for distutils on the mac was somehow not checked in. MacPython from 2.1
onwards needs this.


----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2001-05-11 06:37

Message:
Logged In: YES 
user_id=31392

I'll assign to Greg so that he knows you're waiting for his
review.


----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2001-05-11 01:05

Message:
Logged In: YES 
user_id=45365

Well, when I started porting distutils to the Mac Greg said
he'd prefer me to supply patches than check in things
myself.

I'll give him (or anyone else) a few days more and then I'll
apply it myself.

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2001-05-09 09:14

Message:
Logged In: YES 
user_id=31392

Is there a reason you don't check this in yourself, Jack?


----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2001-04-27 15:43

Message:
Logged In: YES 
user_id=45365




----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=419648&group_id=5470


From noreply@sourceforge.net  Fri May 11 14:38:10 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 11 May 2001 06:38:10 -0700
Subject: [Patches] [ python-Patches-423221 ] Add a few Windows encoding aliases
Message-ID: <E14yD7S-0001F9-00@usw-sf-web1.sourceforge.net>

Patches item #423221, was updated on 2001-05-10 21:14
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=423221&group_id=5470

Category: library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Brian Quinlan (bquinlan)
>Assigned to: Mark Hammond (mhammond)
Summary: Add a few Windows encoding aliases

Initial Comment:
This patch adds aliases for some of the common Windows 
encodings. Windows-1252 is particularly useful because 
it is the default encoding used by Visual Studio .NET 
projects. 

Microsoft's complete encoding list can be found at:
http://msdn.microsoft.com/workshop/author/dhtml/referen
ce/charsets/charset4.asp


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=423221&group_id=5470


From noreply@sourceforge.net  Fri May 11 14:37:44 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 11 May 2001 06:37:44 -0700
Subject: [Patches] [ python-Patches-423224 ] unittest fixture finder
Message-ID: <E14yD72-0001DS-00@usw-sf-web1.sourceforge.net>

Patches item #423224, was updated on 2001-05-10 21:53
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=423224&group_id=5470

Category: Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Benjamin Saller (bcsaller)
>Assigned to: Steve Purcell (purcell)
Summary: unittest fixture finder

Initial Comment:
Some times it is helpful to know the directory that 
tests are being run from so that they can collect 
their test data. If for example you have a parser and 
some test files finding those file reguardless of how 
the test is called is helpful to the test author.

TestCase has been extended to allow for this. When a 
testCase instance needs to find a data file relative 
to itself it can now say

class TestFoo(TestCase):
  def checkFoo(self):   
   dirname = self.getPath()
   # or
   filename = self.getPath("foo.data")

If TestFoo.py is in /home/user/python/tests then
dirname == /home/user/python/tests 
and 
filename == /home/user/python/tests/foo.data


There is not cost if this feature is not invoked.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=423224&group_id=5470


From noreply@sourceforge.net  Fri May 11 15:23:50 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 11 May 2001 07:23:50 -0700
Subject: [Patches] [ python-Patches-423262 ] Change module attribute get & set
Message-ID: <E14yDpe-00043I-00@usw-sf-web3.sourceforge.net>

Patches item #423262, was updated on 2001-05-11 02:11
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=423262&group_id=5470

Category: core (C code)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Tim Peters (tim_one)
Summary: Change module attribute get & set

Initial Comment:
Module objects currently don't define the tp_getattro 
or tp_setattro slots.  As a result, interning of 
attribute names does them no good:  a char* is always 
passed, so the dict lookup always needs to do a string 
compare despite that the attribute name is interned.

The patch simply implements these slots, and nulls out 
the raw-string tp_getattr and tp_setattr slots.

The former is by far the more important one, and I've 
measured speedups over 25% for simple programs that do 
lots of module lookups inside loops (random.random, 
os.path, etc).

So, sure looks like a big cheap win to me, but 
assigning for review in case I'm missing something 
obvious (i.e., if it's such an easy win, why didn't we 
already do it?).


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-05-11 07:23

Message:
Logged In: YES 
user_id=6380

BTW, by convention the C function's name changes to
..._getattro and ..._setattro.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-05-11 06:35

Message:
Logged In: YES 
user_id=6380

There's no deep reason -- this code is ancient and has never
drawn anybody's attention.  I noticed the same thing while
doing a review of getattr vs. getattro for the descr-branch
code.

So I'd say, go for it!

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=423262&group_id=5470


From noreply@sourceforge.net  Fri May 11 15:49:06 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 11 May 2001 07:49:06 -0700
Subject: [Patches] [ python-Patches-423181 ] small speedup in object rich comparisons
Message-ID: <E14yEE6-0002Xy-00@usw-sf-web1.sourceforge.net>

Patches item #423181, was updated on 2001-05-10 15:39
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=423181&group_id=5470

Category: core (C code)
Group: None
>Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: Jeremy Hylton (jhylton)
Assigned to: Jeremy Hylton (jhylton)
Summary: small speedup in object rich comparisons

Initial Comment:
One thing that jumped out at me when I profiled
test_mutant is how often PyErr_Format() was called.  It
ends up that the rich comparisons code does a lot of
lookups for methods like __lt__ and __gt__ and usually
doesn't find them.  It uses PyObject_GetAttr() for the
lookups, so it goes to the expense of creating a Python
string with a nice error message.

This patch uses the internal instance_getattr2 when it
can, i.e. when the instance doesn't define
__getattr__.  This function won't find __dict__ or
__class__, won't do rexec checks, won't call
__getattr__, and (best of all) won't set an exception.

Unfortunately, test_mutants sees only a small speedup
as a result -- about six percent.


----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2001-05-11 07:49

Message:
Logged In: YES 
user_id=31392

rev 2.131 of classobject.c


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-10 22:02

Message:
Logged In: YES 
user_id=31435

Marked Accepted.  I'd be happier with

1) A comment in the *code* explaining why instance_getattr2 
is called.

2) assert(!PyErr_Occurred()) after getting back with a NULL 
result (no cost in release builds, potentially helpful in 
debug builds).

3) A general rewrite of the whole attribute lookup 
mechanism that doesn't force anyone to pay for stuff they 
later need to undo -- plus that never does string 
comparisons.

I'll settle for #3 alone, though <wink>.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-10 17:21

Message:
Logged In: YES 
user_id=31435

Another odd thing:  there are way more calls to 
string_compare() than I would expect in this nearly string-
free program <wink>.  One cause:  half_richcompare has a 
table of special operator names:

static char *name_op[] = {
	"__lt__",
	"__le__",
	"__eq__",
	"__ne__",
	"__gt__",
	"__ge__",
};

and does this at the start:

name = PyString_InternFromString(name_op[op]);

That *always* ends up calling PyDict_GetItem(), and then 
string_compare() one or more times, for the obvious reason 
(i.e., the interning work is wasted because it doesn't get 
reflected back into the name_op table).

Interning isn't buying us anything for module attribute 
lookups either, because module_getattr takes a char* 
argument (i.e., this is another frequent cause of 
string_compare() calls in this program, due to lots of 
random.this() and random.that() calls, and they always end 
up getting resolved via string_compare()).

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-10 16:32

Message:
Logged In: YES 
user_id=31435

Cool!  I'll check this out.

Another interesting thing about the test_mutants profile 
was that it spent no measurable time at all in the dict 
comparison code (dict_compare() + dict_richcompare() + 
dict_equal() + characterize() times summed to 0) -- which 
kinda explains why my efforts to speed those had no 
measurable effect <wink/sigh>.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=423181&group_id=5470


From noreply@sourceforge.net  Fri May 11 19:04:42 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 11 May 2001 11:04:42 -0700
Subject: [Patches] [ python-Patches-423394 ] Fix pulldom to preserve ns attributes
Message-ID: <E14yHHO-0007Ik-00@usw-sf-web3.sourceforge.net>

Patches item #423394, was updated on 2001-05-11 11:04
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=423394&group_id=5470

Category: XML
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Fix pulldom to preserve ns attributes

Initial Comment:
Here is a fix for pulldom.py that preserves 
xmlns attributes that declare namespaces. 

The current pulldom / minidom captures xml namespace 
information in elements and attributes, but the 
actual namespace declaration attributes 
(xmlns:foo="...") are not preserved on the element 
where they appear. 

This makes it impossible for 
certain applications that do more complex name 
dereferencing (XMLSchema is an example) that 
requires not only namespace uris but 
also the prefixes used and the original scope 
information.

The current patch preserves xmlns="" and 
xmlns:foo="" as *non-namespace qualified* 
attributes, which appears to be the norm in other 
DOM implementations.

Pls let me know if you have any questions.

-Brian (brian@digicool.com)

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=423394&group_id=5470


From noreply@sourceforge.net  Fri May 11 22:27:58 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 11 May 2001 14:27:58 -0700
Subject: [Patches] [ python-Patches-423262 ] Change module attribute get & set
Message-ID: <E14yKS6-0001A5-00@usw-sf-web1.sourceforge.net>

Patches item #423262, was updated on 2001-05-11 02:11
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=423262&group_id=5470

Category: core (C code)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Peters (tim_one)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: Change module attribute get & set

Initial Comment:
Module objects currently don't define the tp_getattro 
or tp_setattro slots.  As a result, interning of 
attribute names does them no good:  a char* is always 
passed, so the dict lookup always needs to do a string 
compare despite that the attribute name is interned.

The patch simply implements these slots, and nulls out 
the raw-string tp_getattr and tp_setattr slots.

The former is by far the more important one, and I've 
measured speedups over 25% for simple programs that do 
lots of module lookups inside loops (random.random, 
os.path, etc).

So, sure looks like a big cheap win to me, but 
assigning for review in case I'm missing something 
obvious (i.e., if it's such an easy win, why didn't we 
already do it?).


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-05-11 14:27

Message:
Logged In: YES 
user_id=31435

(getattrofunc)class_getattr, /* tp_getattro */
(getattrofunc)instance_getattr,	/* tp_getattro */
(getattrofunc)instancemethod_getattro,	/* tp_getattro */
(getattrofunc)func_getattro, /* tp_getattro */
(getattrofunc)proxy_getattr, /*tp_getattro*/
(getattrofunc)proxy_getattr,/*tp_getattro*/

It's not much of a convention when only 2 of 6 existing 
slots followed it!  Pronounce, please (make it 2 of 7, 3 of 
7, or change the non-conformers too to make it 7 of 7).

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-05-11 07:23

Message:
Logged In: YES 
user_id=6380

BTW, by convention the C function's name changes to
..._getattro and ..._setattro.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-05-11 06:35

Message:
Logged In: YES 
user_id=6380

There's no deep reason -- this code is ancient and has never
drawn anybody's attention.  I noticed the same thing while
doing a review of getattr vs. getattro for the descr-branch
code.

So I'd say, go for it!

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=423262&group_id=5470


From noreply@sourceforge.net  Fri May 11 22:30:53 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 11 May 2001 14:30:53 -0700
Subject: [Patches] [ python-Patches-423262 ] Change module attribute get & set
Message-ID: <E14yKUv-0001Z1-00@usw-sf-web3.sourceforge.net>

Patches item #423262, was updated on 2001-05-11 02:11
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=423262&group_id=5470

Category: core (C code)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Peters (tim_one)
>Assigned to: Tim Peters (tim_one)
Summary: Change module attribute get & set

Initial Comment:
Module objects currently don't define the tp_getattro 
or tp_setattro slots.  As a result, interning of 
attribute names does them no good:  a char* is always 
passed, so the dict lookup always needs to do a string 
compare despite that the attribute name is interned.

The patch simply implements these slots, and nulls out 
the raw-string tp_getattr and tp_setattr slots.

The former is by far the more important one, and I've 
measured speedups over 25% for simple programs that do 
lots of module lookups inside loops (random.random, 
os.path, etc).

So, sure looks like a big cheap win to me, but 
assigning for review in case I'm missing something 
obvious (i.e., if it's such an easy win, why didn't we 
already do it?).


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-05-11 14:30

Message:
Logged In: YES 
user_id=6380

Oh, fudge.  It *should* be a convention.

But I don't care, this code won't be needed in the
descr-branch anyway.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-11 14:27

Message:
Logged In: YES 
user_id=31435

(getattrofunc)class_getattr, /* tp_getattro */
(getattrofunc)instance_getattr,	/* tp_getattro */
(getattrofunc)instancemethod_getattro,	/* tp_getattro */
(getattrofunc)func_getattro, /* tp_getattro */
(getattrofunc)proxy_getattr, /*tp_getattro*/
(getattrofunc)proxy_getattr,/*tp_getattro*/

It's not much of a convention when only 2 of 6 existing 
slots followed it!  Pronounce, please (make it 2 of 7, 3 of 
7, or change the non-conformers too to make it 7 of 7).

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-05-11 07:23

Message:
Logged In: YES 
user_id=6380

BTW, by convention the C function's name changes to
..._getattro and ..._setattro.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-05-11 06:35

Message:
Logged In: YES 
user_id=6380

There's no deep reason -- this code is ancient and has never
drawn anybody's attention.  I noticed the same thing while
doing a review of getattr vs. getattro for the descr-branch
code.

So I'd say, go for it!

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=423262&group_id=5470


From noreply@sourceforge.net  Fri May 11 22:53:24 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 11 May 2001 14:53:24 -0700
Subject: [Patches] [ python-Patches-423262 ] Change module attribute get & set
Message-ID: <E14yKqi-0003W6-00@usw-sf-web2.sourceforge.net>

Patches item #423262, was updated on 2001-05-11 02:11
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=423262&group_id=5470

Category: core (C code)
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Tim Peters (tim_one)
Summary: Change module attribute get & set

Initial Comment:
Module objects currently don't define the tp_getattro 
or tp_setattro slots.  As a result, interning of 
attribute names does them no good:  a char* is always 
passed, so the dict lookup always needs to do a string 
compare despite that the attribute name is interned.

The patch simply implements these slots, and nulls out 
the raw-string tp_getattr and tp_setattr slots.

The former is by far the more important one, and I've 
measured speedups over 25% for simple programs that do 
lots of module lookups inside loops (random.random, 
os.path, etc).

So, sure looks like a big cheap win to me, but 
assigning for review in case I'm missing something 
obvious (i.e., if it's such an easy win, why didn't we 
already do it?).


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-05-11 14:53

Message:
Logged In: YES 
user_id=31435

OK, I made it 3 of 7 then.  Checked in as

Objects/moduleobject, new revision: 2.32
Misc/NEWS, new revision: 1.165


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-05-11 14:30

Message:
Logged In: YES 
user_id=6380

Oh, fudge.  It *should* be a convention.

But I don't care, this code won't be needed in the
descr-branch anyway.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-11 14:27

Message:
Logged In: YES 
user_id=31435

(getattrofunc)class_getattr, /* tp_getattro */
(getattrofunc)instance_getattr,	/* tp_getattro */
(getattrofunc)instancemethod_getattro,	/* tp_getattro */
(getattrofunc)func_getattro, /* tp_getattro */
(getattrofunc)proxy_getattr, /*tp_getattro*/
(getattrofunc)proxy_getattr,/*tp_getattro*/

It's not much of a convention when only 2 of 6 existing 
slots followed it!  Pronounce, please (make it 2 of 7, 3 of 
7, or change the non-conformers too to make it 7 of 7).

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-05-11 07:23

Message:
Logged In: YES 
user_id=6380

BTW, by convention the C function's name changes to
..._getattro and ..._setattro.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-05-11 06:35

Message:
Logged In: YES 
user_id=6380

There's no deep reason -- this code is ancient and has never
drawn anybody's attention.  I noticed the same thing while
doing a review of getattr vs. getattro for the descr-branch
code.

So I'd say, go for it!

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=423262&group_id=5470


From noreply@sourceforge.net  Sun May 13 09:08:54 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 13 May 2001 01:08:54 -0700
Subject: [Patches] [ python-Patches-410465 ] Allow pre-encoded strings as filenames
Message-ID: <E14yqvu-0008Jb-00@usw-sf-web1.sourceforge.net>

Patches item #410465, was updated on 2001-03-21 21:02
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410465&group_id=5470

Category: core (C code)
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Mark Hammond (mhammond)
Assigned to: Mark Hammond (mhammond)
Summary: Allow pre-encoded strings as filenames

Initial Comment:
This patch enables most filename parameters to use pre-
encoded strings.  On Windows, the default of "mbcs" is 
used.  On all other platforms, the default filename 
encoding is the same as the general default encoding, 
which in reality means there is no functional change.  
However, other platforms can simply plugin their own 
encodings.

Rationalle: os.listdir() etc already return pre-
encoded strings on some platforms (notably Windows).  
These pre-encoded strings may be used now for all 
these functions - however, if you convert this encoded 
string to a Unicode string, it can not be used to open 
the file.  This patch enables either a pre-encoded 
string to work (as now) or a Unicode representation of 
that same string (unlike now)

Things of note:
* I invented a new "Es" PyArg_ParseTuple marker.  This 
is very similar to "es", except it leaves string 
objects alone assuming they are already encoded 
correctly.  "es" assumes a string in the default 
encoding which it will then encode in the new 
characterset - ie, a pre-encoded string fails here.

* This means that all affected functions have an extra 
string copy.  This copy still happens even when 
strings are passed, and even on platforms where no 
Unicode filesystem support exists.  The only other 
alternative was to make a much uglier patch, somehow 
using string objects in-place, but converting and 
freeing the buffer when Unicode.  This could be done 
if desired, but I'm not sure the added code complexity 
is worth it.

* New method on win32: nt._getpathname().  This is 
almost identical to win32api.GetPathName(), except it 
handles encoded strings.  ntpath.py has also been 
changed to work with this.  A hidden bonus of this 
patch is that it will make os.abspath() work 
identically regardless of the Win32 extensions being 
installed.

* Tested on Linux, Windows 98 and Windows 2k.  Still 
working out how to build Python on my BeOs box :)

* New test for these semantics added.


----------------------------------------------------------------------

>Comment By: Mark Hammond (mhammond)
Date: 2001-05-13 01:08

Message:
Logged In: YES 
user_id=14198

checked in:

Checking in Lib/ntpath.py;
new revision: 1.35; previous revision: 1.34
Checking in Lib/test/test_support.py;
new revision: 1.23; previous revision: 1.22
Checking in Lib/test/test_unicode_file.py;
initial revision: 1.1
Checking in Lib/test/output/test_unicode_file;
initial revision: 1.1
Checking in Modules/posixmodule.c;
new revision: 2.188; previous revision: 2.187
Checking in Python/bltinmodule.c;
new revision: 2.206; previous revision: 2.205
Checking in Python/getargs.c;
new revision: 2.56; previous revision: 2.55


----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2001-04-27 05:15

Message:
Logged In: YES 
user_id=14198

MAL - please do!  I generally look for the least-intrusive 
patch when dealing with potentially contentious issues, but 
I agree it makes more sense to rationalize.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-04-27 00:54

Message:
Logged In: YES 
user_id=38388

I like the idea of telling the arg parser to accept strings
as-is, but I think that copying all the code just to
implement the new "E" parser. Much easier would be switching
on the second marker
(behind the "e"), e.g. using "et" and "et#".

Do you want me to look into this ?

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2001-03-22 14:10

Message:
Logged In: YES 
user_id=14198

I appreciate it is too late for 2.1 for a change of this 
size.

I don't think posixmodule is wrong - at least not how you 
think :)

posix_rename calls:
	return posix_2str(args, "EsEs:rename", rename);

however, it is posix_2str that passes the encoding, not 
posix_rename itself.  Ditto for posix_1str and 
posix_do_stat.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-03-22 13:45

Message:
Logged In: YES 
user_id=6380

Mark, I don't think you expected to get this into 2.1, did
you?  It's way too big.

Also, I think your patch to posixmodule.c has some bugs --
if I understand correctly, the format string "Es" requires
two arguments, the encoding and the address of the C string
pointer; but several functions (posix_rename and onwards)
don't pass the encoding name.

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2001-03-21 21:04

Message:
Logged In: YES 
user_id=14198

doh - forgot to click the checkbox

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410465&group_id=5470


From noreply@sourceforge.net  Sun May 13 20:18:52 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 13 May 2001 12:18:52 -0700
Subject: [Patches] [ python-Patches-423759 ] fix on Python bugs 422678 and 423728
Message-ID: <E14z1OG-000373-00@usw-sf-web1.sourceforge.net>

Patches item #423759, was updated on 2001-05-13 12:18
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=423759&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Frederic Giacometti (giacometti)
Assigned to: Nobody/Anonymous (nobody)
Summary: fix on Python bugs 422678 and 423728

Initial Comment:

This patch simply suppresses the assignment 'argv[_PyOS_optind] = "-c";'

This patch will be required for running JPE (the Java-Python Extension), starting from beta 2 
release.

Effects:

a)
python -c "import sys; print sys.argv" a b c
  will print
[ 'import sys; print sys.argv', 'a', 'b', 'c']

(note: 'import sys; print sys.argv' is a valid Unix/Windows/Macintosh file name.

b) argv[] is not modified unduely, and JPE's Java python.PyRun.main() method will not crash.

This patch should have no other technical effect.

FG

----------------------

*** Modules/main.c~	Tue Apr 10 18:07:08 2001
--- Modules/main.c	Sun May 13 14:54:02 2001
***************
*** 281,289 ****
  	
  	
  	if (command != NULL) {
! 		/* Backup _PyOS_optind and force sys.argv[0] = '-c' */
  		_PyOS_optind--;
- 		argv[_PyOS_optind] = "-c";
  	}
  
  	PySys_SetArgv(argc-_PyOS_optind, argv+_PyOS_optind);
--- 281,288 ----
  	
  	
  	if (command != NULL) {
! 		/* Backup _PyOS_optind */
  		_PyOS_optind--;
  	}
  
  	PySys_SetArgv(argc-_PyOS_optind, argv+_PyOS_optind);


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=423759&group_id=5470


From noreply@sourceforge.net  Sun May 13 21:34:34 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 13 May 2001 13:34:34 -0700
Subject: [Patches] [ python-Patches-423759 ] fix on Python bugs 422678 and 423728
Message-ID: <E14z2ZW-0004N7-00@usw-sf-web1.sourceforge.net>

Patches item #423759, was updated on 2001-05-13 12:18
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=423759&group_id=5470

>Category: core (C code)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Frederic Giacometti (giacometti)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: fix on Python bugs 422678 and 423728

Initial Comment:

This patch simply suppresses the assignment 'argv[_PyOS_optind] = "-c";'

This patch will be required for running JPE (the Java-Python Extension), starting from beta 2 
release.

Effects:

a)
python -c "import sys; print sys.argv" a b c
  will print
[ 'import sys; print sys.argv', 'a', 'b', 'c']

(note: 'import sys; print sys.argv' is a valid Unix/Windows/Macintosh file name.

b) argv[] is not modified unduely, and JPE's Java python.PyRun.main() method will not crash.

This patch should have no other technical effect.

FG

----------------------

*** Modules/main.c~	Tue Apr 10 18:07:08 2001
--- Modules/main.c	Sun May 13 14:54:02 2001
***************
*** 281,289 ****
  	
  	
  	if (command != NULL) {
! 		/* Backup _PyOS_optind and force sys.argv[0] = '-c' */
  		_PyOS_optind--;
- 		argv[_PyOS_optind] = "-c";
  	}
  
  	PySys_SetArgv(argc-_PyOS_optind, argv+_PyOS_optind);
--- 281,288 ----
  	
  	
  	if (command != NULL) {
! 		/* Backup _PyOS_optind */
  		_PyOS_optind--;
  	}
  
  	PySys_SetArgv(argc-_PyOS_optind, argv+_PyOS_optind);


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-05-13 13:34

Message:
Logged In: YES 
user_id=31435

Changed Category, assigned to Guido.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=423759&group_id=5470


From noreply@sourceforge.net  Sun May 13 21:53:19 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 13 May 2001 13:53:19 -0700
Subject: [Patches] [ python-Patches-423759 ] fix on Python bugs 422678 and 423728
Message-ID: <E14z2rf-0000TO-00@usw-sf-web3.sourceforge.net>

Patches item #423759, was updated on 2001-05-13 12:18
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=423759&group_id=5470

Category: core (C code)
Group: None
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Frederic Giacometti (giacometti)
Assigned to: Guido van Rossum (gvanrossum)
Summary: fix on Python bugs 422678 and 423728

Initial Comment:

This patch simply suppresses the assignment 'argv[_PyOS_optind] = "-c";'

This patch will be required for running JPE (the Java-Python Extension), starting from beta 2 
release.

Effects:

a)
python -c "import sys; print sys.argv" a b c
  will print
[ 'import sys; print sys.argv', 'a', 'b', 'c']

(note: 'import sys; print sys.argv' is a valid Unix/Windows/Macintosh file name.

b) argv[] is not modified unduely, and JPE's Java python.PyRun.main() method will not crash.

This patch should have no other technical effect.

FG

----------------------

*** Modules/main.c~	Tue Apr 10 18:07:08 2001
--- Modules/main.c	Sun May 13 14:54:02 2001
***************
*** 281,289 ****
  	
  	
  	if (command != NULL) {
! 		/* Backup _PyOS_optind and force sys.argv[0] = '-c' */
  		_PyOS_optind--;
- 		argv[_PyOS_optind] = "-c";
  	}
  
  	PySys_SetArgv(argc-_PyOS_optind, argv+_PyOS_optind);
--- 281,288 ----
  	
  	
  	if (command != NULL) {
! 		/* Backup _PyOS_optind */
  		_PyOS_optind--;
  	}
  
  	PySys_SetArgv(argc-_PyOS_optind, argv+_PyOS_optind);


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-05-13 13:53

Message:
Logged In: YES 
user_id=6380

Ten years ago when I though what argv[0] should be when the
-c option was used, I considered all the possibilities, and
decided that '-c' made the most sense. It still does. So I'm
against changing this behavior.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-13 13:34

Message:
Logged In: YES 
user_id=31435

Changed Category, assigned to Guido.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=423759&group_id=5470


From noreply@sourceforge.net  Mon May 14 02:02:14 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 13 May 2001 18:02:14 -0700
Subject: [Patches] [ python-Patches-423224 ] unittest fixture finder
Message-ID: <E14z6kY-0000Cc-00@usw-sf-web1.sourceforge.net>

Patches item #423224, was updated on 2001-05-10 21:53
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=423224&group_id=5470

Category: Modules
Group: None
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Benjamin Saller (bcsaller)
Assigned to: Steve Purcell (purcell)
Summary: unittest fixture finder

Initial Comment:
Some times it is helpful to know the directory that 
tests are being run from so that they can collect 
their test data. If for example you have a parser and 
some test files finding those file reguardless of how 
the test is called is helpful to the test author.

TestCase has been extended to allow for this. When a 
testCase instance needs to find a data file relative 
to itself it can now say

class TestFoo(TestCase):
  def checkFoo(self):   
   dirname = self.getPath()
   # or
   filename = self.getPath("foo.data")

If TestFoo.py is in /home/user/python/tests then
dirname == /home/user/python/tests 
and 
filename == /home/user/python/tests/foo.data


There is not cost if this feature is not invoked.

----------------------------------------------------------------------

>Comment By: Steve Purcell (purcell)
Date: 2001-05-13 18:02

Message:
Logged In: YES 
user_id=21477

This method is helpful for *some* test environments, but as
the docs mention, 'unittest.py' aims to provide only
functionality common to all testing environments.

What usually happens is that each project has its own
'BaseTestCase' class that provides site-specific add-ons
(such as 'getPath()').

I will keep this patch and use it later in documentation to
illustrate the principle of customising a base TestCase
subclass for a specific test environment.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=423224&group_id=5470


From noreply@sourceforge.net  Mon May 14 02:48:05 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 13 May 2001 18:48:05 -0700
Subject: [Patches] [ python-Patches-423830 ] Spurious Install Warning
Message-ID: <E14z7Sv-0000wV-00@usw-sf-web1.sourceforge.net>

Patches item #423830, was updated on 2001-05-13 18:48
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=423830&group_id=5470

Category: Build
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Kurt B. Kaiser (kbk)
Assigned to: Nobody/Anonymous (nobody)
Summary: Spurious Install Warning

Initial Comment:
During installation setup.py install is generating a
warning that the lib-dynload directory is not in
sys.path. While that is true for the instance of Python
doing the installation, the installed Python will have
the correct path. Suppress the warning during
installation.

Ref: Bug 232619, Bug 417472

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=423830&group_id=5470


From chief@bandits.org  Mon May 14 16:51:23 2001
From: chief@bandits.org (John Fremlin)
Date: 14 May 2001 16:51:23 +0100
Subject: [Patches] SysV IPC Implementation
Message-ID: <m2g0e8kjyc.fsf@boreas.yi.org.>

I have a written a SysV IPC message queue C module, and a python
SysVQueue class (modelled on Queue.Queue) to provide a cleaner
interface to the SysV functionality. 

SysV message queues are used for interprocess communication, and thus
avoid the hassle of posix threads. Why is an interface not included in
the standard Python distribution? Would such a package be accepted for
inclusion?

It would be much simpler for me if I could submit a patch to the
standard distribution, as I don't want to have to deal with building
and installing a Python C module in my project.

For the record, the following functions are made AFAIK fully
accessible from Python by the C module:

        ftok
        msgget
        msgsnd
        msgrcv

The msgctl syscall is broken up into three logical functions:

        msgctl_rm
        msgctl_stat
        msgctl_set

And the public fields of the msgqid_ds stucture are made accessible.

The SysVQueue class provides the functionality of the Queue class,
except that it is impossible to set a maximum size, objects added to
it have to be pickleable, and the "full" method is missing.

Only tested on Linux 2.4.
-- 
BTW, I'm looking for a summer job in Europe.

	http://ape.n3.net


From noreply@sourceforge.net  Mon May 14 23:34:16 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 14 May 2001 15:34:16 -0700
Subject: [Patches] [ python-Patches-418147 ] Fixes to allow compiling w/ Borland
Message-ID: <E14zQuu-0005S7-00@usw-sf-web1.sourceforge.net>

Patches item #418147, was updated on 2001-04-22 23:59
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=418147&group_id=5470

Category: Build
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Stephen Hansen (ixokai)
Assigned to: Tim Peters (tim_one)
Summary: Fixes to allow compiling w/ Borland

Initial Comment:
This patch supercedes the following bugs that I 
submitted before realizing it'd be better to just 
submit one big patch:

417802, 417949, 417952

So if someone wants to close them, they can :)

Now, an explaination of the changes I found that 
needed to be done:

In pyport.h, I put a couple #defines to make rename 
chsize/setmode to _chsize/_setmode.. why there? I 
really couldn't think of a better place to put it, and 
it seemed better then surrounding the calls 
to '_chsize/_setmode' with #ifdef __BORLANDC_'s.

Posixmodule needed a lot of fixes. Borland obviousely 
doesn't support Unixish *id's, firstly. Secondly, io.h 
defines chmod as 'chmod(const char *, int amode)', and 
we called an 'extern chmod(const char *, mode_t)', so 
that needed to be altered. Later, it needed to include 
__BORLANDC__ in the places where it 
names 'posixmodule' as 'nt'.

In Timemodule, we have some renamings to do again. I 
put them here instead of pyport.h, since it already 
had most of them for Win16, even though I don't know 
if that was best or not. Further, Borland needs to 
keep HAVE_CLOCK, so I had to make it so Mark Hammond's 
clock code didn't replace the built in one.

Config.h needed a few changes. I moved 
HAVE_SYS_UTIME_H up by HAVE_HYPOT, so it could be 
defined for everything still, and just have Borland 
#undef it... So I basically copied what they did with 
HAVE_HYPOT.

Okay, so all of the above was actually rather self-
explainatory from the patch. Oh well. :)

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-05-14 15:34

Message:
Logged In: YES 
user_id=31435

Thank you, Stephen!  The patch has been checked in:

Include/pyport.h; new revision: 2.27
Misc/NEWS; new revision: 1.171
Modules/posixmodule.c; new revision: 2.190
Modules/timemodule.c; new revision: 2.111
PC/config.h; new revision: 1.52


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-04-30 15:16

Message:
Logged In: YES 
user_id=31435

Assigned to me.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=418147&group_id=5470


From noreply@sourceforge.net  Tue May 15 20:54:04 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 15 May 2001 12:54:04 -0700
Subject: [Patches] [ python-Patches-424335 ] richcompare for strings
Message-ID: <E14zktQ-0001R6-00@usw-sf-web3.sourceforge.net>

Patches item #424335, was updated on 2001-05-15 12:54
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=424335&group_id=5470

Category: core (C code)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Martin v. Löwis (loewis)
Assigned to: Nobody/Anonymous (nobody)
Summary: richcompare for strings

Initial Comment:
This patch implements the tp_richcompare slot for
string objects. It shows a 8% speed-up on selected test
cases.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=424335&group_id=5470


From noreply@sourceforge.net  Wed May 16 09:07:07 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 16 May 2001 01:07:07 -0700
Subject: [Patches] [ python-Patches-424475 ] Speed-up tp_compare usage
Message-ID: <E14zwKp-0002gi-00@usw-sf-web2.sourceforge.net>

Patches item #424475, was updated on 2001-05-16 01:07
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=424475&group_id=5470

Category: core (C code)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Martin v. Löwis (loewis)
Assigned to: Nobody/Anonymous (nobody)
Summary: Speed-up tp_compare usage

Initial Comment:
This patch tries to optimize PyObject_RichCompare for
the common case of objects with equal types which
support tp_compare. It gives a speed-up of roughly 7%
for comparing strings in a loop.

The patch also gives type objects a tp_compare
function, so that they can make use of the improvement.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=424475&group_id=5470


From noreply@sourceforge.net  Wed May 16 09:07:58 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 16 May 2001 01:07:58 -0700
Subject: [Patches] [ python-Patches-423394 ] Fix pulldom to preserve ns attributes
Message-ID: <E14zwLe-0002hA-00@usw-sf-web2.sourceforge.net>

Patches item #423394, was updated on 2001-05-11 11:04
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=423394&group_id=5470

Category: XML
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Martin v. Löwis (loewis)
Summary: Fix pulldom to preserve ns attributes

Initial Comment:
Here is a fix for pulldom.py that preserves 
xmlns attributes that declare namespaces. 

The current pulldom / minidom captures xml namespace 
information in elements and attributes, but the 
actual namespace declaration attributes 
(xmlns:foo="...") are not preserved on the element 
where they appear. 

This makes it impossible for 
certain applications that do more complex name 
dereferencing (XMLSchema is an example) that 
requires not only namespace uris but 
also the prefixes used and the original scope 
information.

The current patch preserves xmlns="" and 
xmlns:foo="" as *non-namespace qualified* 
attributes, which appears to be the norm in other 
DOM implementations.

Pls let me know if you have any questions.

-Brian (brian@digicool.com)

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=423394&group_id=5470


From tsaritsino@newacropol.ru  Wed May 16 10:36:15 2001
From: tsaritsino@newacropol.ru (tsaritsino@newacropol.ru)
Date: 16 May 2001 09:36:15 -0000
Subject: [Patches] ðïíïçéôå òåûéôø ðòïâìåíõ üëïìïçéé ÷ ãáòéãùîï!
Message-ID: <20010516093615.33156.qmail@mu.pair.com>

This is a MIME encoded message.

--b102382cbf1c8fe2a562c783c479a9df4
Content-Type: text/html ;	charset="windows-1251"
Content-Transfer-Encoding: base64

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv
L0VOIj4NCg0KPGh0bWw+DQo8aGVhZD4NCgk8dGl0bGU+zcUg1c7XxdLR3yDB29LcINDAws3OxNPY
zdvMPC90aXRsZT4NCjwvaGVhZD4NCg0KPGJvZHk+DQo8ZGl2IGFsaWduPSJDRU5URVIiPjxmb250
IGZhY2U9IiIgY29sb3I9IkJsdWUiPjxoMj7NxSDVztfF0tHfIMHb0twg0MDCzc7E09jN28w8L2gy
PjwvZm9udD48L2Rpdj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO8ru4+Tg
IOz7IPHr+/jo7CDx6+7i7iAi/eru6+7j6P8iLCDy7iDk8+zg5ewsIPfy7iD98u4g4+TlLfLuIOTg
6+Xq7jogwPDg6/zx6u7lIOzu8OUsIMHg6erg6ywg7eX08v/t++Ug6uDy4PHy8O70+4UgzuTt4Oru
IP3q7uvu4+j35fHq6OUg7/Du4evl7Psg7urw8+bg/vIg7eDxIO/u4vHl5O3l4u3uLiDKIOzz8e7w
8yDoIOPw/+foIOLu6vDz4yDs+yDz5uUg5ODi7e4g7/Do4vvq6+gsIOgg5ODm5SDt5SDi5fDo8vH/
LCD38u4g4u7n7O7m7e4g9/LuLfLuIOjn7OXt6PL8LiDP4PDq6CDoIOzl8fLgIO7y5Pv14CDv7vDu
6SDt4O/u7Ojt4P7yIOzz8e7w7fvlIPHi4Ovq6C4gwvHlIOzl7fz45SDx8uDt7uLo8vH/IOzl8fIs
IOPk5SDv8Oj/8u3uIO/w7uLl8fLoIOL79e7k7e7pIOTl7fwuPGJyPg0KJm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ze4g8ejy8+D26P8g7eUg4eXn7eDk5ebt4CEgzuH65eTo7eXt
7fvlIPPx6Ovo/yDr/uTl6Swg6u7y7vD75SDw5eDr/O3uIPXu8v/yIPfy7i3y7iDo5+zl7ejy/Cwg
8e/u8e7h7fsg8uLu8Ojy/CD38+Tl8eAuINLg6iwgMjkg4O/w5ev/IDIwMDEg4+7k4CDt4CD96u7r
7uPo9+Xx6u7pIODq9ujoIOIg7+Dw6uUgPGEgaHJlZj0iaHR0cDovL3d3dy5uZXdhY3JvcG9sLnJ1
L21haW4wXzBfMC5waHAzP2lkMT10c2FyaXRzaW5vX2hpc3QiPiLW4PDo9vvt7iI8L2E+IOIgzO7x
6uLlLCDu8OPg7ejn7uLg7e3u6SDoIO/w7uLl5OXt7e7pIMrz6/zy8/Dt++wg9uXt8vDu7CA8YSBo
cmVmPSJodHRwOi8vd3d3Lm5ld2Fjcm9wb2wucnUgIj4ize7i++kgwOrw7u/u6/wiPC9hPiwg4fvr
7iDx7uHw4O3uIOHu6+XlIDE1LfLoIPLu7e0g7PPx7vDgIDxhIGhyZWY9Imh0dHA6Ly93d3cucGhv
dG90YXNzLnJ1L25ld3NfaW5mby5hc3A/bmV3c19pZD0xMTg2MDEgIj4o/fLuIOHu6+XlIDkwMCDx
8u7r6PLw7uL79SDs5fjq7uIpPC9hPi4gyiAyNTAg9+vl7eDsIMrz6/zy8/Dt7uPuIPbl7fLw4CDv
8Ojx7uXk6O3o6+7x/CA8YSBocmVmPSJodHRwOi8vd3d3LnBob3RvdGFzcy5ydS9uZXdzX2luZm8u
YXNwP25ld3NfaWQ9MTE4NjAzIj4g7uru6+4gMTUwIO/u8eXy6PLl6+XpPC9hPiAg7+Dw6uAuINHr
8/fg6e375SDv8O717ubo5SDy4Orm5SDt5SDu8fLg6+jx/CDiIPHy7vDu7eUuPGJyPg0KJm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7zuTt4OruIO7k6O0g8ODnIO736PHy6PL8IO/g
8Oog7ODr7iAtIOzz8e7wIO/u/+Lo8vH/IOLt7uL8LiDCICLW4PDo9vvt7iIsIOjx8u7w6Pfl8eru
7CA8YSBocmVmPSJodHRwOi8vd3d3LnBob3RvdGFzcy5ydS9uZXdzX2luZm8uYXNwP25ld3NfaWQ9
MTE4NjAwIj7v4PDq5S3z8eDk/OHlPC9hPiAsIP3r5ezl7fLg8O3uIO3l8iDz8O0sIOgg7+798u7s
8yDiIPXu5OUg4Or26Ogg4fvr6CDz8fLg7e7i6+Xt+yDv5fDi++UgMTAg8/DtLCDw4Ofw4OHu8uDt
7fvlIO/uIPHv5fbo4Ov87e7s8yDv8O7l6vLzICjv7uTw7uHt5eUg8ezu8vDo8uUgPGEgaHJlZj0i
aHR0cDovL3d3dy5uZXdhY3JvcG9sLnJ1L21haW4wXzBfMC5waHAzP2lkMT10c2FyaXRzaW5vX2lu
ZiI+5+Tl8fw8L2E+KSDoIOL77+7r7eXt7fvlIOIg4PD16PLl6vLz8O3u7CDx8ujr5SDv4PDq4C4g
wvHl4+4g7+Dw6vMg8vDl4fPl8vH/IOHu6+XlIDUwLfLoIPLg6uj1IPPw7SDoIPHy4Pbo7u3g8O37
5SDq7u3y5ent5fD7IOTr/yDx4e7w4CDs8/Hu8OAuIDxicj4NCsrz6/zy8/Dt++kg9uXt8vAgIs3u
4vvpIMDq8O7v7uv8IiDj7vLu4iDi5//y/CDt4CDx5eH/IOjn4+7y7uLr5e3o5SDz8O0g6CDk5ebz
8PHy4u4g7+4g8eHu8PMg6CDi++Lu5/Mg7PPx7vDgIOjnIO/g8OrgLCDt7iDt5SDs7ubl8iD06O3g
7fHo8O7i4PL8IP3y8yDk5f/y5ev87e7x8vwuIM/w6Ozl8O3g/yDx7OXy7eD/IPHy7ujs7vHy/CDv
8OXk8fLu//no9SDw4OHu8joNCg0KPHRhYmxlIGJnY29sb3I9ImJsYWNrIiBib3JkZXI9IjAiIGNl
bGxwYWRkaW5nPSI1IiBjZWxsc3BhY2luZz0iMSI+DQo8dHIgYmdjb2xvcj0id2hpdGUiPg0KCTx0
ZD48L3RkPg0KCTx0ZD7W5e3gLCDw8+EuPC90ZD4NCgk8dGQgYWxpZ249IlJJR0hUIj7K7ust4u48
L3RkPg0KCTx0ZD7R8+zs4Cwg8PPhLjwvdGQ+DQo8L3RyPg0KPHRyIGJnY29sb3I9IndoaXRlIj4N
Cgk8dGQ+yOfj7vLu4uvl7ejlIPPw7fssIPDg5+7i7jwvdGQ+DQoJPHRkIGFsaWduPSJSSUdIVCI+
ODUwPC90ZD4NCgk8dGQgYWxpZ249IkNFTlRFUiI+NTA8L3RkPg0KCTx0ZCBhbGlnbj0iUklHSFQi
PjQyIDUwMDwvdGQ+DQo8L3RyPg0KPHRyIGJnY29sb3I9IndoaXRlIj4NCgk8dGQ+z+7q8+/q4CDq
7u3y5ent5fDgLCDw4Ofu4u48L3RkPg0KCTx0ZCBhbGlnbj0iUklHSFQiPjggMDAwPC90ZD4NCgk8
dGQgYWxpZ249IkNFTlRFUiI+MjwvdGQ+DQoJPHRkIGFsaWduPSJSSUdIVCI+MTYgMDAwPC90ZD4N
CjwvdHI+DQo8dHIgYmdjb2xvcj0id2hpdGUiPg0KCTx0ZD7C++Lu5yDs8/Hu8OAsIOIg7OXx//Yg
KOfg6uDnIOru7fLl6e3l8OApPC90ZD4NCgk8dGQgYWxpZ249IlJJR0hUIj4xIDUwMDwvdGQ+DQoJ
PHRkIGFsaWduPSJDRU5URVIiPjI8L3RkPg0KCTx0ZCBhbGlnbj0iUklHSFQiPjMgMDAwPC90ZD4N
CjwvdHI+DQo8dHIgYmdjb2xvcj0id2hpdGUiPg0KCTx0ZD7M8/Hu8O375SDv4Orl8vssIOIg7OXx
//Y8L3RkPg0KCTx0ZCBhbGlnbj0iUklHSFQiPjI8L3RkPg0KCTx0ZCBhbGlnbj0iQ0VOVEVSIj42
NTA8L3RkPg0KCTx0ZCBhbGlnbj0iUklHSFQiPjEgMzAwPC90ZD4NCjwvdHI+DQo8dHIgYmdjb2xv
cj0id2hpdGUiPg0KCTx0ZCBjb2xzcGFuPSIzIj7I8u7j7iwg8ODn7uLuIO3l7uH17uTo7O48L3Rk
Pg0KCQ0KCTx0ZCBhbGlnbj0iUklHSFQiPjU4IDUwMDwvdGQ+DQo8L3RyPg0KPHRyIGJnY29sb3I9
IndoaXRlIj4NCgk8dGQgY29sc3Bhbj0iMyI+xebl7OXx//ft++Ug8ODx9e7k+yDx7vHy4OL/8jwv
dGQ+DQoJDQoJPHRkIGFsaWduPSJSSUdIVCI+NCAzMDA8L3RkPg0KPC90cj4NCjwvdGFibGU+DQo8
YnI+DQo8Zm9udCBmYWNlPSIiIHNpemU9IisxIiBjb2xvcj0iUmVkIj4NCiZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwO8z7IO7h8OD54OXs8f8g6u4g4vHl7Cwg6u7s8yDt5eHl5/Dg
5+vo9+37IPfo8fLu8uAg6CDv7vD/5O7qIOIg7eD45ewg4+7w7uTlLCDxIDxhIGhyZWY9Imh0dHA6
Ly93d3cubmV3YWNyb3BvbC5ydS9tYWluMF8wXzAucGhwMz9pZDE9dHNhcml0c2lub19pbmYiPu/w
7vH84e7pICDuIPTo7eDt8e7i7ukg7+7s7vnoPC9hPi4gwfPk5ewg7/Do5+3g8uXr/O37IOfgIOv+
4fP+IPHz7OzzLCDv5fDl9+jx6+Xt7fP+IO3gIPHr5eTz/vno6SDx9+XyOjwvZm9udD48YnI+PGJy
Pg0KDQo8Yj7AyiAizO7x6u7i8ero6SDM8+3o9ujv4Ov87fvpIMHg7eogLSDB4O3qIMzu8eri+yIg
4y7M7vHq4uA8YnI+DQrByMogMDQ0NTI1MjE5PGJyPg0K6u7w8C4g8ffl8iAzMDEwMTgxMDUwMDAw
MDAwMDIxOTxicj4NCvDg8fcuIPH35fIgNDA3MDM4MTAwMzgwNjAxMDAzNzQ8YnI+DQrP7uvz9+Dy
5ev8OiDNzyDK1iAgIs3u4vvpIMDq8O7v7uv8Ijxicj4NCsjNzSA3NzM3MTE2MjMyPGJyPg0KzeDn
7eD35e3o5SDv6+Dy5ebgOiDt4CDz6/P3+OXt6OUg/eru6+7j6Ogg7+Dw6uAgItbg8Oj2++3uIjwv
Yj48YnI+PGJyPg0KDQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDvM+yDj7vLu
4vsg7/Dl5O7x8uDi6//y/CDu8vfl8vsg7iDw4PH17uTu4uDt6Ogg7+7x8vPv6OL46PUg7eAg8ffl
8iDx8OXk8fLiLiDE6/8g/fLu4+4g7/Du8fzh4CDv4PDg6+vl6/zt7iDx7u7h+eDy/CDuIO/l8OX3
6PHr5e3o6CDk5e3l4yDt4CDg5PDl8SA8YSBocmVmPSJtYWlsdG86dHNhcml0c2lub0BuZXdhY3Jv
cG9sLnJ1Ij50c2FyaXRzaW5vQG5ld2Fjcm9wb2wucnU8L2E+IOjr6CDv7iDy5evl9O7t4Owg4iDM
7vHq4uU6PGJyPjxicj4NCjxiPjxkaXYgYWxpZ249IkNFTlRFUiI+MzkxLTE4LTA0LCAzOTEtMTgt
MTQ8L2Rpdj48L2I+PGJyPg0KCQ0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
wvHl7CDx7+7t8e7w4Owg4fPk8/Ig7/Dl5O7x8uDi6+Xt+yDh6+Dj7uTg8PHy4uXt7fvlIO/o8fzs
4CDu8iDK8+v88vPw7e7j7iD25e3y8OAg6CDg5Ozo7ejx8vDg9ujoIO/g8OrgLfPx4OT84fsuIMz7
IOPu8u7i+yDu4fHz5Ojy/CDr/uH75SDo7fvlIPTu8Oz7IPHu8vDz5O3o9+Xx8uLgLCDq7vLu8Pvl
IOzu4/PyIPHv7vHu4fHy4u7i4PL8IPDl+OXt6P4g/eru6+7j6Pfl8ero9SDv8O7h6+XsIO/g8Org
Ljxicj48YnI+PGJyPjxicj48YnI+DQo8Zm9udCBzaXplPSItMSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A70+Hl5Ojy5ev87e4g7/Du8ejsIO3lIPH36PLg8vwg5ODt7e7lIO/o
8fzs7iDt5fHg7er26O7t6PDu4uDt7e7pIPDg8fH76+ru6Swg8uDqIOrg6iDl4+4g9uXr/P4g7eUg
/+Lr/+Xy8f8g6Ofi6+X35e3o5SDq4Oru6S3r6OHuIOL74+7k+yDk6/8g7eDxLiDC4Pgg4OTw5fEg
4fvrIO/u6/P35e0g6Ocg7vTo9ujg6/zt7uPuIOjx8u737ejq4CDoLCDiIOv+4e7sIPHr8/fg5Swg
7+7i8u7w7fv1IO/o8eXsIO3lIOHz5OXyLiA8L2ZvbnQ+DQoNCjwvYm9keT4NCjwvaHRtbD4NCg==

--b102382cbf1c8fe2a562c783c479a9df4--





From noreply@sourceforge.net  Wed May 16 16:12:46 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 16 May 2001 08:12:46 -0700
Subject: [Patches] [ python-Patches-424554 ] pythonrun.c: bag the  _Py_AskYesNo call
Message-ID: <E1502yk-00080a-00@usw-sf-web3.sourceforge.net>

Patches item #424554, was updated on 2001-05-16 08:12
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=424554&group_id=5470

Category: core (C code)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Nobody/Anonymous (nobody)
Summary: pythonrun.c: bag the  _Py_AskYesNo call

Initial Comment:
Currently, on Unix-like systems if Py_TRACE_REFS is
defined,
the Python interpreter asks at the end of the run if
remaining
references should be dumped.  If you are trying to
debug
Python or its interaction with other packages that use
it this
can cause problems.  Case in point, the configure
script for the
PyGtk2 package runs the python interpreter to check
that its
version number is >= 2.0.  If you need Py_DEBUG enabled
to
build a version of PyGtk2 with that stuff turned on,
you need
it to not ask about printing references.  I think the
better
solution is just to have the reference dumping
dependent on
the presence of the PYTHONDUMPREFS environment
variable,
which is currently only used under Windows.  A patch to
fix
this problem is attached.



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=424554&group_id=5470


From noreply@sourceforge.net  Wed May 16 19:19:07 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 16 May 2001 11:19:07 -0700
Subject: [Patches] [ python-Patches-424606 ] (string|unicode).(|r|l)strip
Message-ID: <E1505t5-0000FZ-00@usw-sf-web1.sourceforge.net>

Patches item #424606, was updated on 2001-05-16 11:19
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=424606&group_id=5470

Category: Windows
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Walter Dörwald (doerwalter)
Assigned to: Nobody/Anonymous (nobody)
Summary: (string|unicode).(|r|l)strip

Initial Comment:
This patch adds an optional parameter to the six 
methods (string|unicode).(|r|l)strip: This parameter, 
when given (and not None) specifies which string 
should be stripped (this works analogous to 
(string|unicode).split where the separator can be 
specified).

Example
"  spam  \r\n\r\n".rstrip("\r\n") => "  spam  "

When the parameter is not specified or None, the
behaviour is the old one: Strip any whitespace 
character.

The functionality is exposed on the C level as two
functions:

PyString_Strip(PyOb *self, PyOb *strip, int left, int 
right)
PyUnicode_Strip(PyOb *self, PyOb *strip, int left, int 
right)

("spam".strip(u"m") yields u"spa", which is the 
analogous behaviour of string.split: "spam eggs".split
(u" ") yields [u"spam", u"eggs"])

string.py and UserString.py are updated accordingly.

A patch to the documentation and additional test cases
in Lib/test/test_string.py and 
Lib/test/test_unicode.py are included.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=424606&group_id=5470


From noreply@sourceforge.net  Wed May 16 19:23:01 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 16 May 2001 11:23:01 -0700
Subject: [Patches] [ python-Patches-424606 ] (string|unicode).(|r|l)strip
Message-ID: <E1505wr-0002Dt-00@usw-sf-web3.sourceforge.net>

Patches item #424606, was updated on 2001-05-16 11:19
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=424606&group_id=5470

Category: Windows
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Walter Dörwald (doerwalter)
Assigned to: Nobody/Anonymous (nobody)
Summary: (string|unicode).(|r|l)strip

Initial Comment:
This patch adds an optional parameter to the six 
methods (string|unicode).(|r|l)strip: This parameter, 
when given (and not None) specifies which string 
should be stripped (this works analogous to 
(string|unicode).split where the separator can be 
specified).

Example
"  spam  \r\n\r\n".rstrip("\r\n") => "  spam  "

When the parameter is not specified or None, the
behaviour is the old one: Strip any whitespace 
character.

The functionality is exposed on the C level as two
functions:

PyString_Strip(PyOb *self, PyOb *strip, int left, int 
right)
PyUnicode_Strip(PyOb *self, PyOb *strip, int left, int 
right)

("spam".strip(u"m") yields u"spa", which is the 
analogous behaviour of string.split: "spam eggs".split
(u" ") yields [u"spam", u"eggs"])

string.py and UserString.py are updated accordingly.

A patch to the documentation and additional test cases
in Lib/test/test_string.py and 
Lib/test/test_unicode.py are included.


----------------------------------------------------------------------

>Comment By: Walter Dörwald (doerwalter)
Date: 2001-05-16 11:23

Message:
Logged In: YES 
user_id=89016

Uups, the first patch had the function declarations in the 
wrong files.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=424606&group_id=5470


From noreply@sourceforge.net  Thu May 17 13:53:53 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 17 May 2001 05:53:53 -0700
Subject: [Patches] [ python-Patches-419648 ] Carbon support for distutils on Mac
Message-ID: <E150NHt-0001iJ-00@usw-sf-web1.sourceforge.net>

Patches item #419648, was updated on 2001-04-27 15:15
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=419648&group_id=5470

Category: distutils
Group: 2.0.1 bugfix
Status: Open
Resolution: None
Priority: 7
Submitted By: Jack Jansen (jackjansen)
>Assigned to: Jack Jansen (jackjansen)
Summary: Carbon support for distutils on Mac

Initial Comment:
Carbon support for distutils on the mac was somehow not checked in. MacPython from 2.1
onwards needs this.


----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2001-05-17 05:53

Message:
Logged In: YES 
user_id=45365

These have been sitting here for 3 weeks now. I'll just grab them back and check them in.


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2001-05-11 06:37

Message:
Logged In: YES 
user_id=31392

I'll assign to Greg so that he knows you're waiting for his
review.


----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2001-05-11 01:05

Message:
Logged In: YES 
user_id=45365

Well, when I started porting distutils to the Mac Greg said
he'd prefer me to supply patches than check in things
myself.

I'll give him (or anyone else) a few days more and then I'll
apply it myself.

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2001-05-09 09:14

Message:
Logged In: YES 
user_id=31392

Is there a reason you don't check this in yourself, Jack?


----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2001-04-27 15:43

Message:
Logged In: YES 
user_id=45365




----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=419648&group_id=5470


From noreply@sourceforge.net  Thu May 17 13:55:27 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 17 May 2001 05:55:27 -0700
Subject: [Patches] [ python-Patches-419648 ] Carbon support for distutils on Mac
Message-ID: <E150NJP-0001kc-00@usw-sf-web1.sourceforge.net>

Patches item #419648, was updated on 2001-04-27 15:15
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=419648&group_id=5470

Category: distutils
Group: 2.0.1 bugfix
>Status: Closed
Resolution: None
Priority: 7
Submitted By: Jack Jansen (jackjansen)
Assigned to: Jack Jansen (jackjansen)
Summary: Carbon support for distutils on Mac

Initial Comment:
Carbon support for distutils on the mac was somehow not checked in. MacPython from 2.1
onwards needs this.


----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2001-05-17 05:55

Message:
Logged In: YES 
user_id=45365

Applied.


----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2001-05-17 05:53

Message:
Logged In: YES 
user_id=45365

These have been sitting here for 3 weeks now. I'll just grab them back and check them in.


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2001-05-11 06:37

Message:
Logged In: YES 
user_id=31392

I'll assign to Greg so that he knows you're waiting for his
review.


----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2001-05-11 01:05

Message:
Logged In: YES 
user_id=45365

Well, when I started porting distutils to the Mac Greg said
he'd prefer me to supply patches than check in things
myself.

I'll give him (or anyone else) a few days more and then I'll
apply it myself.

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2001-05-09 09:14

Message:
Logged In: YES 
user_id=31392

Is there a reason you don't check this in yourself, Jack?


----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2001-04-27 15:43

Message:
Logged In: YES 
user_id=45365




----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=419648&group_id=5470


From noreply@sourceforge.net  Thu May 17 15:33:11 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 17 May 2001 07:33:11 -0700
Subject: [Patches] [ python-Patches-424856 ] Better way to read files from ZipFiles
Message-ID: <E150Opz-0003Rc-00@usw-sf-web1.sourceforge.net>

Patches item #424856, was updated on 2001-05-17 07:33
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=424856&group_id=5470

Category: library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Itamar Shtull-Trauring (itamar)
Assigned to: Nobody/Anonymous (nobody)
Summary: Better way to read files from ZipFiles

Initial Comment:
RIght now, reading a file from a ZipFile loads the
whole file into memory and returns it as a string. This
makes the module useless for large files.

My patch allows you to get a file-like object for each
entry in the zip, so you can do:

  f = z.readfile("largfile")
  print f.read(500)

Instead of the current method:

  s = z.read("largefile")
  print s[:500]

Much nicer if "largefile" is a 10MB file...


I added a function ZipFile.readfile, two classes for
the file-like objects (uncompressed and deflated), and
reimplemented ZipFile.read to use ZipFile.readfile. I
also added a small test to test_zipfile.py, although
some more extensive testing would be better, as usual.
I will be using this code in a project, which'll
provide additional testing.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=424856&group_id=5470


From noreply@sourceforge.net  Thu May 17 15:36:09 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 17 May 2001 07:36:09 -0700
Subject: [Patches] [ python-Patches-401647 ] adds SSL server socket support to socketmodule.c
Message-ID: <E150Osr-00010b-00@usw-sf-web3.sourceforge.net>

Patches item #401647, was updated on 2000-09-25 09:34
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=401647&group_id=5470

Category: Modules
Group: None
Status: Closed
Resolution: Rejected
Priority: 5
Submitted By: Andrew Csillag (drew_csillag)
Assigned to: Guido van Rossum (gvanrossum)
Summary: adds SSL server socket support to socketmodule.c

Initial Comment:
 

----------------------------------------------------------------------

Comment By: Ilya Etingof (elie)
Date: 2001-05-17 07:36

Message:
Logged In: YES 
user_id=106050

So, what is the fate of the socket.ssl stuff? Is it safe to
rely on SSL support of socket module or it will be dropped?

Thanks,
ilya

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-02-09 06:56

Message:
Rejected.  Drew agrees after re-educating himself about M2Crypto.

----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2001-02-08 08:33

Message:
Drew provided instructions for creating a test key and certificate, but I couldn't make them work.  Given that:

* this SSL support is undocumented
* it seems difficult to make it work
* OpenSSL is a big API, and only very basic support is in socketmodule.c
* M2Crypto already exists, and offers more complete support.

I'd suggest dropping SSL support from 2.1. 

Reassigning to GvR; I can't test this code if I can't even make a client connection work!



----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2001-01-24 19:04

Message:
newServerSSLObject() is a near-duplicate of newSSLobject().  Rather than just cut-and-paste the code into a new function, newSSLobject() should take a fourth argument, and perform either the client or server initialization.  

I've already modified the patch to do this.  Before uploading the modified version,  I'd like to test it, but can't figure out what it wants for the key and cert arguments.  Drew, do you have a test program you used to test the code?  Can you please e-mail it to me, or add it as a comment to this
patch?



----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-01-24 12:05

Message:
OK, Andrew, it's all yours.

(But I disagree with your last point: client-only SSL support is still a lot better than no SSL support! :-)

----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2001-01-24 11:24

Message:
Guido, want me to re-open this patch and take it over?  IMHO, if the SSL support is left in, then this patch should be added; no point in having only half-working support.


----------------------------------------------------------------------

Comment By: Andrew Csillag (drew_csillag)
Date: 2001-01-24 11:06

Message:
Sorry for the no-reply...  Anyhoo, the ssl stuff currently in the socket module only allows ssl on client connections (i.e. where you connect to somebody else) as opposed to server connections (i.e. where somebody connects to you).

For example, you have a cheesy SSL socket client:

from socket import *
s = socket(AF_INET, SOCK_STREAM)
s.connect(('',9999))
ss = ssl(s,None,None)
ss.write("foo!\n")

The patch is required in order to be able to write the corresponding server, as such:

from socket import *
s = socket(AF_INET, SOCK_STREAM)
s.bind(('',9999))
s.listen(5)
f,a = s.accept()
ss = sslserv(f, "keyfilename", "certfilename")
print ss.read(5)


If you try to just use the ssl function on both sides and it
doesn't work.



----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-11-13 11:41

Message:
Still no reply. I'll reject the patch now, for lack of sufficient motivation.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-10-25 13:54

Message:
Drew, could you provide an example of how this is used? If I can't test it I can't add it. It doesn't have to be a test module (although a test module for all the SSL support is sorely needed) but I would like to see a little motivation for why this is useful. Also note that the SSL support in the socket module is controversial; there are some who believe that a different approach is needed, e.g. based on M2crypto.

----------------------------------------------------------------------

Comment By: Naris Siamwalla (naris)
Date: 2000-09-27 03:51

Message:
too late ?  this patch solves world hunger and brings world peace!

such a valuable patch, but i guess deadlines are deadlines :-(

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2000-09-25 09:41

Message:
too late for 2.0

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=401647&group_id=5470


From noreply@sourceforge.net  Thu May 17 15:51:29 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 17 May 2001 07:51:29 -0700
Subject: [Patches] [ python-Patches-401647 ] adds SSL server socket support to socketmodule.c
Message-ID: <E150P7h-0003n4-00@usw-sf-web1.sourceforge.net>

Patches item #401647, was updated on 2000-09-25 09:34
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=401647&group_id=5470

Category: Modules
Group: None
Status: Closed
Resolution: Rejected
Priority: 5
Submitted By: Andrew Csillag (drew_csillag)
Assigned to: Guido van Rossum (gvanrossum)
Summary: adds SSL server socket support to socketmodule.c

Initial Comment:
 

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-05-17 07:51

Message:
Logged In: YES 
user_id=6380

The existing socket.ssl() support will remain in existence,
or a backwards compatibility solution will be provided.

----------------------------------------------------------------------

Comment By: Ilya Etingof (elie)
Date: 2001-05-17 07:36

Message:
Logged In: YES 
user_id=106050

So, what is the fate of the socket.ssl stuff? Is it safe to
rely on SSL support of socket module or it will be dropped?

Thanks,
ilya

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-02-09 06:56

Message:
Rejected.  Drew agrees after re-educating himself about M2Crypto.

----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2001-02-08 08:33

Message:
Drew provided instructions for creating a test key and certificate, but I couldn't make them work.  Given that:

* this SSL support is undocumented
* it seems difficult to make it work
* OpenSSL is a big API, and only very basic support is in socketmodule.c
* M2Crypto already exists, and offers more complete support.

I'd suggest dropping SSL support from 2.1. 

Reassigning to GvR; I can't test this code if I can't even make a client connection work!



----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2001-01-24 19:04

Message:
newServerSSLObject() is a near-duplicate of newSSLobject().  Rather than just cut-and-paste the code into a new function, newSSLobject() should take a fourth argument, and perform either the client or server initialization.  

I've already modified the patch to do this.  Before uploading the modified version,  I'd like to test it, but can't figure out what it wants for the key and cert arguments.  Drew, do you have a test program you used to test the code?  Can you please e-mail it to me, or add it as a comment to this
patch?



----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-01-24 12:05

Message:
OK, Andrew, it's all yours.

(But I disagree with your last point: client-only SSL support is still a lot better than no SSL support! :-)

----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2001-01-24 11:24

Message:
Guido, want me to re-open this patch and take it over?  IMHO, if the SSL support is left in, then this patch should be added; no point in having only half-working support.


----------------------------------------------------------------------

Comment By: Andrew Csillag (drew_csillag)
Date: 2001-01-24 11:06

Message:
Sorry for the no-reply...  Anyhoo, the ssl stuff currently in the socket module only allows ssl on client connections (i.e. where you connect to somebody else) as opposed to server connections (i.e. where somebody connects to you).

For example, you have a cheesy SSL socket client:

from socket import *
s = socket(AF_INET, SOCK_STREAM)
s.connect(('',9999))
ss = ssl(s,None,None)
ss.write("foo!\n")

The patch is required in order to be able to write the corresponding server, as such:

from socket import *
s = socket(AF_INET, SOCK_STREAM)
s.bind(('',9999))
s.listen(5)
f,a = s.accept()
ss = sslserv(f, "keyfilename", "certfilename")
print ss.read(5)


If you try to just use the ssl function on both sides and it
doesn't work.



----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-11-13 11:41

Message:
Still no reply. I'll reject the patch now, for lack of sufficient motivation.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-10-25 13:54

Message:
Drew, could you provide an example of how this is used? If I can't test it I can't add it. It doesn't have to be a test module (although a test module for all the SSL support is sorely needed) but I would like to see a little motivation for why this is useful. Also note that the SSL support in the socket module is controversial; there are some who believe that a different approach is needed, e.g. based on M2crypto.

----------------------------------------------------------------------

Comment By: Naris Siamwalla (naris)
Date: 2000-09-27 03:51

Message:
too late ?  this patch solves world hunger and brings world peace!

such a valuable patch, but i guess deadlines are deadlines :-(

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2000-09-25 09:41

Message:
too late for 2.0

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=401647&group_id=5470


From noreply@sourceforge.net  Thu May 17 15:59:03 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 17 May 2001 07:59:03 -0700
Subject: [Patches] [ python-Patches-401647 ] adds SSL server socket support to socketmodule.c
Message-ID: <E150PF1-0006AJ-00@usw-sf-web2.sourceforge.net>

Patches item #401647, was updated on 2000-09-25 09:34
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=401647&group_id=5470

Category: Modules
Group: None
Status: Closed
Resolution: Rejected
Priority: 5
Submitted By: Andrew Csillag (drew_csillag)
Assigned to: Guido van Rossum (gvanrossum)
Summary: adds SSL server socket support to socketmodule.c

Initial Comment:
 

----------------------------------------------------------------------

Comment By: Ilya Etingof (elie)
Date: 2001-05-17 07:59

Message:
Logged In: YES 
user_id=106050

That is great!

Are you planning to commit the ssl-server-socket patch into
the socket module to make the latter
suitable for building SSL servers?

Thanks,
ilya

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-05-17 07:51

Message:
Logged In: YES 
user_id=6380

The existing socket.ssl() support will remain in existence,
or a backwards compatibility solution will be provided.

----------------------------------------------------------------------

Comment By: Ilya Etingof (elie)
Date: 2001-05-17 07:36

Message:
Logged In: YES 
user_id=106050

So, what is the fate of the socket.ssl stuff? Is it safe to
rely on SSL support of socket module or it will be dropped?

Thanks,
ilya

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-02-09 06:56

Message:
Rejected.  Drew agrees after re-educating himself about M2Crypto.

----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2001-02-08 08:33

Message:
Drew provided instructions for creating a test key and certificate, but I couldn't make them work.  Given that:

* this SSL support is undocumented
* it seems difficult to make it work
* OpenSSL is a big API, and only very basic support is in socketmodule.c
* M2Crypto already exists, and offers more complete support.

I'd suggest dropping SSL support from 2.1. 

Reassigning to GvR; I can't test this code if I can't even make a client connection work!



----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2001-01-24 19:04

Message:
newServerSSLObject() is a near-duplicate of newSSLobject().  Rather than just cut-and-paste the code into a new function, newSSLobject() should take a fourth argument, and perform either the client or server initialization.  

I've already modified the patch to do this.  Before uploading the modified version,  I'd like to test it, but can't figure out what it wants for the key and cert arguments.  Drew, do you have a test program you used to test the code?  Can you please e-mail it to me, or add it as a comment to this
patch?



----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-01-24 12:05

Message:
OK, Andrew, it's all yours.

(But I disagree with your last point: client-only SSL support is still a lot better than no SSL support! :-)

----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2001-01-24 11:24

Message:
Guido, want me to re-open this patch and take it over?  IMHO, if the SSL support is left in, then this patch should be added; no point in having only half-working support.


----------------------------------------------------------------------

Comment By: Andrew Csillag (drew_csillag)
Date: 2001-01-24 11:06

Message:
Sorry for the no-reply...  Anyhoo, the ssl stuff currently in the socket module only allows ssl on client connections (i.e. where you connect to somebody else) as opposed to server connections (i.e. where somebody connects to you).

For example, you have a cheesy SSL socket client:

from socket import *
s = socket(AF_INET, SOCK_STREAM)
s.connect(('',9999))
ss = ssl(s,None,None)
ss.write("foo!\n")

The patch is required in order to be able to write the corresponding server, as such:

from socket import *
s = socket(AF_INET, SOCK_STREAM)
s.bind(('',9999))
s.listen(5)
f,a = s.accept()
ss = sslserv(f, "keyfilename", "certfilename")
print ss.read(5)


If you try to just use the ssl function on both sides and it
doesn't work.



----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-11-13 11:41

Message:
Still no reply. I'll reject the patch now, for lack of sufficient motivation.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-10-25 13:54

Message:
Drew, could you provide an example of how this is used? If I can't test it I can't add it. It doesn't have to be a test module (although a test module for all the SSL support is sorely needed) but I would like to see a little motivation for why this is useful. Also note that the SSL support in the socket module is controversial; there are some who believe that a different approach is needed, e.g. based on M2crypto.

----------------------------------------------------------------------

Comment By: Naris Siamwalla (naris)
Date: 2000-09-27 03:51

Message:
too late ?  this patch solves world hunger and brings world peace!

such a valuable patch, but i guess deadlines are deadlines :-(

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2000-09-25 09:41

Message:
too late for 2.0

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=401647&group_id=5470


From noreply@sourceforge.net  Thu May 17 16:02:27 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 17 May 2001 08:02:27 -0700
Subject: [Patches] [ python-Patches-401647 ] adds SSL server socket support to socketmodule.c
Message-ID: <E150PIJ-0006D9-00@usw-sf-web2.sourceforge.net>

Patches item #401647, was updated on 2000-09-25 09:34
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=401647&group_id=5470

Category: Modules
Group: None
Status: Closed
Resolution: Rejected
Priority: 5
Submitted By: Andrew Csillag (drew_csillag)
Assigned to: Guido van Rossum (gvanrossum)
Summary: adds SSL server socket support to socketmodule.c

Initial Comment:
 

----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2001-05-17 08:02

Message:
Logged In: YES 
user_id=11375

No, which is why this patch is marked as "Rejected".  Use 
M2Crypto if you want to write SSL servers.


----------------------------------------------------------------------

Comment By: Ilya Etingof (elie)
Date: 2001-05-17 07:59

Message:
Logged In: YES 
user_id=106050

That is great!

Are you planning to commit the ssl-server-socket patch into
the socket module to make the latter
suitable for building SSL servers?

Thanks,
ilya

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-05-17 07:51

Message:
Logged In: YES 
user_id=6380

The existing socket.ssl() support will remain in existence,
or a backwards compatibility solution will be provided.

----------------------------------------------------------------------

Comment By: Ilya Etingof (elie)
Date: 2001-05-17 07:36

Message:
Logged In: YES 
user_id=106050

So, what is the fate of the socket.ssl stuff? Is it safe to
rely on SSL support of socket module or it will be dropped?

Thanks,
ilya

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-02-09 06:56

Message:
Rejected.  Drew agrees after re-educating himself about M2Crypto.

----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2001-02-08 08:33

Message:
Drew provided instructions for creating a test key and certificate, but I couldn't make them work.  Given that:

* this SSL support is undocumented
* it seems difficult to make it work
* OpenSSL is a big API, and only very basic support is in socketmodule.c
* M2Crypto already exists, and offers more complete support.

I'd suggest dropping SSL support from 2.1. 

Reassigning to GvR; I can't test this code if I can't even make a client connection work!



----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2001-01-24 19:04

Message:
newServerSSLObject() is a near-duplicate of newSSLobject().  Rather than just cut-and-paste the code into a new function, newSSLobject() should take a fourth argument, and perform either the client or server initialization.  

I've already modified the patch to do this.  Before uploading the modified version,  I'd like to test it, but can't figure out what it wants for the key and cert arguments.  Drew, do you have a test program you used to test the code?  Can you please e-mail it to me, or add it as a comment to this
patch?



----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-01-24 12:05

Message:
OK, Andrew, it's all yours.

(But I disagree with your last point: client-only SSL support is still a lot better than no SSL support! :-)

----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2001-01-24 11:24

Message:
Guido, want me to re-open this patch and take it over?  IMHO, if the SSL support is left in, then this patch should be added; no point in having only half-working support.


----------------------------------------------------------------------

Comment By: Andrew Csillag (drew_csillag)
Date: 2001-01-24 11:06

Message:
Sorry for the no-reply...  Anyhoo, the ssl stuff currently in the socket module only allows ssl on client connections (i.e. where you connect to somebody else) as opposed to server connections (i.e. where somebody connects to you).

For example, you have a cheesy SSL socket client:

from socket import *
s = socket(AF_INET, SOCK_STREAM)
s.connect(('',9999))
ss = ssl(s,None,None)
ss.write("foo!\n")

The patch is required in order to be able to write the corresponding server, as such:

from socket import *
s = socket(AF_INET, SOCK_STREAM)
s.bind(('',9999))
s.listen(5)
f,a = s.accept()
ss = sslserv(f, "keyfilename", "certfilename")
print ss.read(5)


If you try to just use the ssl function on both sides and it
doesn't work.



----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-11-13 11:41

Message:
Still no reply. I'll reject the patch now, for lack of sufficient motivation.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-10-25 13:54

Message:
Drew, could you provide an example of how this is used? If I can't test it I can't add it. It doesn't have to be a test module (although a test module for all the SSL support is sorely needed) but I would like to see a little motivation for why this is useful. Also note that the SSL support in the socket module is controversial; there are some who believe that a different approach is needed, e.g. based on M2crypto.

----------------------------------------------------------------------

Comment By: Naris Siamwalla (naris)
Date: 2000-09-27 03:51

Message:
too late ?  this patch solves world hunger and brings world peace!

such a valuable patch, but i guess deadlines are deadlines :-(

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2000-09-25 09:41

Message:
too late for 2.0

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=401647&group_id=5470


From noreply@sourceforge.net  Thu May 17 16:19:35 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 17 May 2001 08:19:35 -0700
Subject: [Patches] [ python-Patches-401647 ] adds SSL server socket support to socketmodule.c
Message-ID: <E150PYt-0001bz-00@usw-sf-web3.sourceforge.net>

Patches item #401647, was updated on 2000-09-25 09:34
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=401647&group_id=5470

Category: Modules
Group: None
Status: Closed
Resolution: Rejected
Priority: 5
Submitted By: Andrew Csillag (drew_csillag)
Assigned to: Guido van Rossum (gvanrossum)
Summary: adds SSL server socket support to socketmodule.c

Initial Comment:
 

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-05-17 08:19

Message:
Logged In: YES 
user_id=6380

No, no, no!  We won't be adding new functionality.

----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2001-05-17 08:02

Message:
Logged In: YES 
user_id=11375

No, which is why this patch is marked as "Rejected".  Use 
M2Crypto if you want to write SSL servers.


----------------------------------------------------------------------

Comment By: Ilya Etingof (elie)
Date: 2001-05-17 07:59

Message:
Logged In: YES 
user_id=106050

That is great!

Are you planning to commit the ssl-server-socket patch into
the socket module to make the latter
suitable for building SSL servers?

Thanks,
ilya

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-05-17 07:51

Message:
Logged In: YES 
user_id=6380

The existing socket.ssl() support will remain in existence,
or a backwards compatibility solution will be provided.

----------------------------------------------------------------------

Comment By: Ilya Etingof (elie)
Date: 2001-05-17 07:36

Message:
Logged In: YES 
user_id=106050

So, what is the fate of the socket.ssl stuff? Is it safe to
rely on SSL support of socket module or it will be dropped?

Thanks,
ilya

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-02-09 06:56

Message:
Rejected.  Drew agrees after re-educating himself about M2Crypto.

----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2001-02-08 08:33

Message:
Drew provided instructions for creating a test key and certificate, but I couldn't make them work.  Given that:

* this SSL support is undocumented
* it seems difficult to make it work
* OpenSSL is a big API, and only very basic support is in socketmodule.c
* M2Crypto already exists, and offers more complete support.

I'd suggest dropping SSL support from 2.1. 

Reassigning to GvR; I can't test this code if I can't even make a client connection work!



----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2001-01-24 19:04

Message:
newServerSSLObject() is a near-duplicate of newSSLobject().  Rather than just cut-and-paste the code into a new function, newSSLobject() should take a fourth argument, and perform either the client or server initialization.  

I've already modified the patch to do this.  Before uploading the modified version,  I'd like to test it, but can't figure out what it wants for the key and cert arguments.  Drew, do you have a test program you used to test the code?  Can you please e-mail it to me, or add it as a comment to this
patch?



----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-01-24 12:05

Message:
OK, Andrew, it's all yours.

(But I disagree with your last point: client-only SSL support is still a lot better than no SSL support! :-)

----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2001-01-24 11:24

Message:
Guido, want me to re-open this patch and take it over?  IMHO, if the SSL support is left in, then this patch should be added; no point in having only half-working support.


----------------------------------------------------------------------

Comment By: Andrew Csillag (drew_csillag)
Date: 2001-01-24 11:06

Message:
Sorry for the no-reply...  Anyhoo, the ssl stuff currently in the socket module only allows ssl on client connections (i.e. where you connect to somebody else) as opposed to server connections (i.e. where somebody connects to you).

For example, you have a cheesy SSL socket client:

from socket import *
s = socket(AF_INET, SOCK_STREAM)
s.connect(('',9999))
ss = ssl(s,None,None)
ss.write("foo!\n")

The patch is required in order to be able to write the corresponding server, as such:

from socket import *
s = socket(AF_INET, SOCK_STREAM)
s.bind(('',9999))
s.listen(5)
f,a = s.accept()
ss = sslserv(f, "keyfilename", "certfilename")
print ss.read(5)


If you try to just use the ssl function on both sides and it
doesn't work.



----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-11-13 11:41

Message:
Still no reply. I'll reject the patch now, for lack of sufficient motivation.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-10-25 13:54

Message:
Drew, could you provide an example of how this is used? If I can't test it I can't add it. It doesn't have to be a test module (although a test module for all the SSL support is sorely needed) but I would like to see a little motivation for why this is useful. Also note that the SSL support in the socket module is controversial; there are some who believe that a different approach is needed, e.g. based on M2crypto.

----------------------------------------------------------------------

Comment By: Naris Siamwalla (naris)
Date: 2000-09-27 03:51

Message:
too late ?  this patch solves world hunger and brings world peace!

such a valuable patch, but i guess deadlines are deadlines :-(

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2000-09-25 09:41

Message:
too late for 2.0

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=401647&group_id=5470


From noreply@sourceforge.net  Fri May 18 16:29:08 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 18 May 2001 08:29:08 -0700
Subject: [Patches] [ python-Patches-401196 ] IPv6 patch against 2.0 CVS tree, as of 20001230
Message-ID: <E150mBg-00039a-00@usw-sf-web1.sourceforge.net>

Patches item #401196, was updated on 2000-08-16 05:53
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=401196&group_id=5470

Category: core (C code)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jun-ichiro itojun Hagino (itojun)
>Assigned to: Nobody/Anonymous (nobody)
Summary: IPv6 patch against 2.0 CVS tree, as of 20001230

Initial Comment:
 

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-05-18 08:29

Message:
Logged In: YES 
user_id=6380

See
http://mail.python.org/pipermail/python-dev/2001-May/014889.html
for comments from MvL.

I'm unassigning this from Fred, he has nothing to do with
this.

----------------------------------------------------------------------

Comment By: Jun-ichiro itojun Hagino (itojun)
Date: 2001-02-26 02:24

Message:
Logged In: YES 
user_id=63767

about /usr/bin/test argument: does linux /usr/bin/test have
-d <dir> support?  if not, we may need to change
configure.in slightly.

you are correct that fallback getaddrinfo/getnameinfo.c was
missing in the patch.  sorry.  a question i need to ask is,
do we need to supply Python function Socket.getaddrinfo on
platforms that do not have getaddrinfo(3)?

HAVE_ADDRINFO is used in Include/addrinfo.h, which is also
missing in the patch set i have submitted.

i've put the missing files into
http://www.itojun.org/diary/20001230/missing.shar.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2001-02-23 23:58

Message:
After a shallow review of this patch, I found the following issues:

configure.in does not need to list both enable and disable options.
 
When running configure, I got the following error message on Linux
checking whether to enable ipv6... yes
checking ipv6 stack type... linux-glibc
./configure: test: too many arguments
using libc

The call to /usr/bin/test should be corrected; I could not find out which specific  invocation caused the problem.

HAVE_ADDRINFO is not used. Perhaps getaddrinfo.c/getnameinfo.c is missing in the patch?


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-01-04 07:51

Message:
A new patch is available.  I've changed the subject accordingly.

Due to upload size restrictions, the patch is now at

http://www.itojun.org/diary/20001230/python-2.0-v6-20001230.diff.gz

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2000-12-30 07:25

Message:
I got *many* rejects when trying to apply this patch to today's CVS tree. I recommend that patches for generated files (config.h.in, configure) are not included in the patch because they outdate too easily.
A number of changes in this patch have already been done by somebody else; others just don't fit into the current code anymore (perhaps due to indentation changes?).
Anyway, I'll mark the patch as out-of-date. Please let me know when you upload a new version.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2000-08-16 07:00

Message:
Postponed until Python 2.1 -- there's not enough time to review this and get it sufficiently tested on enough IPv6-connected platforms in time for 2.0, and we're already in feature freeze.  This should go into the tree very quickly once Python 2.0 has been released.

Assigned to myself to open it back up after Python 2.0.

----------------------------------------------------------------------

Comment By: Moshe Zadka (moshez)
Date: 2000-08-16 06:07

Message:
Assigned to Tim, since he's in charge of postponing
new features. I'm to timid to postpone it myself.

----------------------------------------------------------------------

Comment By: Jun-ichiro itojun Hagino (itojun)
Date: 2000-08-16 05:59

Message:
this is revised version of patch #101186 (now with my SourceForge accout...
i'm not familiar with the system here, so forgive my possible mistake).

1.6b1 patch applied mostly clean to 2.0.
It is confirmed that:
- 1.6b1 + IPv6 patch works fine on NetBSD 1.4.2 + KAME, and NetBSD 1.5
- 1.6b1 + IPv6 patch works fine on NetBSD 1.4.2 (NOT an IPv6 ready machine)
- 2.0 CVS tree + IPv6 patch works fine on NetBSD + KAME

forgot to attach the following into the diff - so i attach it (README.v6)
here as comment.  I have submitted the patch for 1.5.1, 1.5.2 and 1.6b1,
all hit a bad timing - bad luck.

contact: core@kame.net, or itojun@kame.net


---
IPv6-ready python 1.6
KAME Project
$KAME: README.v6,v 1.9 2000/08/15 02:40:38 itojun Exp $


This patchkit enables python 1.6 to perform AF_INET6 socket operations.
The only affected module is Modules/socketmodule.c.

Modules/socketmodule.c
	In most cases, IPv6 address can be placed where IPv4 address fits.

    sockaddr
	sockaddr tuple is formatted as follows:
	    IPv4: (host, port)
	    IPv6: socket class methods always generate
		    (host, port, flowinfo, scopeid).
		  socket class methods will accept 2, 3, or 4 tuple
		  (for backward compatibility).

	Compatibility warning: Some of the scripts assume that the sockaddr
	structure is 2 tuple, like:
	    host, port = sock.getpeername()
	this will fail if you are connected to IPv6 node.

    socket.getaddrinfo(host, port [, family, socktype, proto, flags])
	host: String or None
	port: String, Int or None
	family, socktype, proto, flags: Int, can be omitted

	Perform getaddrinfo(3).  Returns List of the following 5 tuple:
	    (family, socktype, proto, canonname, sockaddr)
	    family: Int
	    socktype: Int
	    proto: Int
	    canonname: String
	    sockaddr: sockaddr (see above)

	See Lib/httplib.py for typical usage on the client side.

    socket.getnameinfo(sockaddr, flags)
	sockaddr: sockaddr
	flags: Int

	Perform getnameinfo(3).  Returns the following 2 tuple:
	    host: String, numeric or hostname depending on flgags
	    port: String, numeric or portname depending on flgags

    socket.gethostbyname2(host, af)
	host: String
	af: Int

	Performs gethostbyname2(3).  Returns numeric address representation
	for "host".

    socket.gethostbyaddr(addr) (behavior change if IPv6 support is compiled in)
	addr: String

	Performs gethostbyaddr(3).  Returns string address representation for
	"addr".

	The function can take IPv6 numeric address as well.  This behavior
	is not problematical, because
	- if you pass numeric "addr" parameter, we can always identify address
	  family for it
	- return value is string address reprsentation, where IPv6 and IPv4
	  are not distinguishable.

     socket.bind(sa), socket.connect(sa) and others.
	(No behavior change, but be careful)

	See above for sockaddr format change.

	With Python "addr" portion of sockaddr (first element) can be string
	hostname.  When the string hostname resolved to numeric address, it
	will obey address family of the socket (which was specified when
	socket.socket() was called).
	If you give some string that does not give matching address family,
	you will get some error.
		s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
		# this is okay, if 'localhost' resolves to both IPv4/v6
		s.connect('localhost', 80)
		# this is not okay, of course
		s.connect('::1', 80)
		# this is not okay, as v6only.kame.net will not resolve to IPv4
		s.connect('v6only.kame.net', 80)

Lib/httplib.py
	IPv6 ready.  "host" in HTTP(host) will accept the following 3 forms:
		[host]:port
		host:port	there must be only single colon
		host
	This is to allow IPv6 numeric URL (http://[host]:port/) in documents.

	IMHO "host:port" parsing should be implemented in urllib.py, not here.

Lib/ftplib.py
	IPv6 ready.  This uses EPSV/EPRT on IPv6 ftp.  See RFC2428 for
	protocol details.

Lib/SocketServer.py
	IPv6 ready.  Wildcard bind on TCPServer, i.e. TCPServer(('', port)),
	will bind to wildcard socket on TCPServer.address_family.
	TCPServer.addresss_family is set to AF_INET by default, so ('', port)
	will usually bind AF_INET.

Lib/smtplib.py, Lib/telnetlib.py, Lib/poplib.py
	IPv6 ready.  Not much to say about protocol details - they just use
	TCP over IPv6.

configure
	Configure has extra option, --enable-ipv6 and --disable-ipv6.
	The option controls IPv6 support feature.

dynamic link issues in Modules/socketmodule.c
	Modules/socketmodule.c can be dynamically loaded only in the following
	situations:
	- getaddrinfo(3) and getnameinfo(3) are supplied by OS vendor in
	  libc, and libc is dynamic link library.
	- OS vendor is NOT supplying getaddrinfo(3) nor getnameinfo(3), and
	  You are configuring this package with --disable-ipv6.  In this case,
	  you'll be using missing/get{addr,name}info.c and they will refer to
	  gethostby{name,addr}.  gethostnameby{name,addr} can usually be found
	  in dynamic-linking libc.

	In other situations, such as the following, please link
	Modules/socketmodule.c into python itself.
	- getaddrinfo(3) and getnameinfo(3) are supplied by OS vendor, but
	  they are in statically linked library like libinet6.a.
	  (KAME falls into this category)

	python usually links Modules/socketmodule.c into python itself
	(due to its popularity) so there should be no problem.

restrictions
	- The patched tree will not use gethostbyname_r and other
	  thread-ready libraries.  Instead, it will use getaddrinfo() and
	  getnameinfo() throughout the operation.

todo
	- Patch bunch of library files in Lib/*.py.

compatibility issues with existing scripts
	If you disable IPv6 support (./configure --disable-ipv6), the
	patched code is mostly compatible with original Python
	(except files in "Lib" directory modified for dual stack support).

	User script may choke if:
	- IPv4/v6 dualstack libc is supplied, python is compiled for dual
	  stack, and script assumes some of IPv4-only behavior (especially
	  sockaddr)
	- IPv4/v6 dualstack libc is supplied, python is compiled for IPv4 only,
	  and script assumes some of IPv4-only behavior.
	  In this case, Python socket class itself does not support IPv6,
	  however, name resolution functions can return IPv6 names since
	  they use IPv6-ready libc functions!  I do not recommend this
	  configuration.
	- script assumes certain IPv4-only version behavior in Lib/*.py.

compilation
	If you use IPv6 features, it is assumed that you have working
	getaddrinfo() and getnameinfo() library functions.  We have noticed
	that some of IPv6 stack is shipped with broken getaddrinfo().  In
	such cases, use missing/get{addr,name}info.c instead (but then, you
	need to have working getipnodeby{name,addr}).

	If you compile this on IPv4-only machine without get{addr,name}info,
	missing/get{addr,name}info.c will be used.  They are from KAME IPv6
	distribution and is #ifdef'ed for IPv4 only support.  They are
	fairly complete implementation and you don't need to bother with
	bind 8.2 (bind 8.2 get{addr,name}info() has bugs).

	When compiling this kit on IPv6 node, you may need to specify some
	additional library paths or cpp defs. (like -linet6 or -DINET6)
	--enable-ipv6 will give you some warning, if the IPv6 stack is unknown
	to the "configure" script.  Currently, the following IPv6 stacks
	are officially supported (i.e. we've checked that the package works
	well):
	- KAME IPv6 stack, http://www.kame.net/

References
	RFC2553, for getaddrinfo(3) and getnameinfo(3).

Author contacts
	http://www.kame.net/
	mailto:core@kame.net


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=401196&group_id=5470


From noreply@sourceforge.net  Fri May 18 18:13:09 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 18 May 2001 10:13:09 -0700
Subject: [Patches] [ python-Patches-416262 ] 2.1c1: make setup.py check zlib version
Message-ID: <E150noL-0004tG-00@usw-sf-web1.sourceforge.net>

Patches item #416262, was updated on 2001-04-15 06:14
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416262&group_id=5470

Category: Build
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Mark Favas (mfavas)
Assigned to: M.-A. Lemburg (lemburg)
Summary: 2.1c1: make setup.py check zlib version

Initial Comment:
Currently, setup.py will build the zlib module without
checking whether the version of zlib on the target
system is up to date (or at least 1.1.3). The module
will thus be built on a stock SGI system where the zlib
version is 1.0.4. WHen the zlib test is run, a core
dump results. The patch below checks the version of
zlib, and only builds if >= 1.1.3

*** setup.py.orig       Sun Apr 15 20:59:34 2001
--- setup.py    Sun Apr 15 21:00:53 2001
***************
*** 449,457 ****
          # Andrew Kuchling's zlib module.
          # This require zlib 1.1.3 (or later).
          # See http://www.cdrom.com/pub/infozip/zlib/
!         if (self.compiler.find_library_file(lib_dirs,
'z')):
!             exts.append( Extension('zlib',
['zlibmodule.c'],
!                                    libraries = ['z'])
)
  
          # Interface to the Expat XML parser
          #
--- 449,471 ----
          # Andrew Kuchling's zlib module.
          # This require zlib 1.1.3 (or later).
          # See http://www.cdrom.com/pub/infozip/zlib/
!         zlib_inc = find_file('zlib.h', [], inc_dirs)
!         if zlib_inc is not None:
!             zlib_h = zlib_inc[0] + '/zlib.h'
!             version = '"0.0.0"'
!             version_req = '"1.1.3"'
!             fp = open(zlib_h)
!             while 1:
!                 line = fp.readline()
!                 if not line:
!                     break
!                 if line.find('#define ZLIB_VERSION',
0) == 0:
!                     version = line.split()[2]
!                     break
!             if version >= version_req:
!                 if
(self.compiler.find_library_file(lib_dirs, 'z')):
!                     exts.append( Extension('zlib',
['zlibmodule.c'],
!                                            libraries
= ['z']) )
  
          # Interface to the Expat XML parser
          #


----------------------------------------------------------------------

>Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-18 10:13

Message:
Logged In: YES 
user_id=38388

This is already in Python 2.1.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416262&group_id=5470


From noreply@sourceforge.net  Fri May 18 18:15:18 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 18 May 2001 10:15:18 -0700
Subject: [Patches] [ python-Patches-425242 ] Patch which "inlines" small dictionaries
Message-ID: <E150nqQ-0004i6-00@usw-sf-web3.sourceforge.net>

Patches item #425242, was updated on 2001-05-18 10:15
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=425242&group_id=5470

Category: core (C code)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: M.-A. Lemburg (lemburg)
Assigned to: Tim Peters (tim_one)
Summary: Patch which "inlines" small dictionaries

Initial Comment:
As discussed on python-dev, this patch inlines small
dictionary tables directly in the dictionary object.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=425242&group_id=5470


From noreply@sourceforge.net  Fri May 18 18:21:32 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 18 May 2001 10:21:32 -0700
Subject: [Patches] [ python-Patches-425242 ] Patch which "inlines" small dictionaries
Message-ID: <E150nwS-00051i-00@usw-sf-web1.sourceforge.net>

Patches item #425242, was updated on 2001-05-18 10:15
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=425242&group_id=5470

Category: core (C code)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: M.-A. Lemburg (lemburg)
Assigned to: Tim Peters (tim_one)
>Summary: Patch which "inlines" small dictionaries

Initial Comment:
As discussed on python-dev, this patch inlines small
dictionary tables directly in the dictionary object.

----------------------------------------------------------------------

>Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-18 10:21

Message:
Logged In: YES 
user_id=38388

This is just a quick update of the original patch which I
prepared for Python 1.5 some years ago. Since the dictionary
implementation has evolved somewhat since then, I'm not sure
whether it still works as robust as it does for Python 1.5
(I've been using this for years without any problem).

Running the test suite, their appears to be a hanger due to
some endless loop which occurrs for test_popen2. I'm not
sure where Python hangs, but it could well be that the
resize routines have to adapted a little for the current
dict implementation.



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=425242&group_id=5470


From noreply@sourceforge.net  Fri May 18 20:01:49 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 18 May 2001 12:01:49 -0700
Subject: [Patches] [ python-Patches-401394 ] lookdict optimizations
Message-ID: <E150pVV-0007p2-00@usw-sf-web2.sourceforge.net>

Patches item #401394, was updated on 2000-09-01 14:13
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=401394&group_id=5470

Category: core (C code)
Group: None
Status: Open
>Resolution: Out of Date
Priority: 5
Submitted By: Vladimir Marangozov (marangoz)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: lookdict optimizations

Initial Comment:
 

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-05-18 12:01

Message:
Logged In: YES 
user_id=31435

Marked Out of Date:  I've fiddled the dict code quite a bit 
in the meantime.  Changing the computation of the initial 
table index reduced the # of collisions, so the case this 
is aiming at is probably less frequent now.  The guts of 
the loop have been reordered to check for dummy last in 
every case, so "inlining the first collision probe" 
probably doesn't buy anything anymore.  Using a length 
check is probably still helpful:  you're effectively 
creating a Py_EQ string richcmp here, but inlined.  It will 
be less helpful once strings grow a tp_richcompare slot, 
because that will almost certainly do a Py_EQ length check 
too (e.g., Martin's pending patch does).

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-02-19 13:19

Message:
This patch optimizes what appears to be a small corner case (string keys in a string-only dict that have hash collisions), but the cause can indeed come up.

I need to spend a little time instrumenting the code to determine how often this corner case occurs, and haven't had time to do that yet.

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2001-02-09 16:11

Message:
Is this patch still revelant?


----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2000-09-25 18:52

Message:
It's postponed since I've not had time to run performance tests to measure the corner case it aims to improve.  It turns out that generating the test data I need takes a long time (I need hash collisions of identifier-like strings).  I just need to be able to let my generator run for a long time (it was generating more collisions than I'd expected, but I don't know how many off-hand).

Another interesting metric would be to examine the .pyc files generated from the standard library and find out if there are any string hash collisions there -- if not, or if very few, it's not worth the added complexity.

----------------------------------------------------------------------

Comment By: Thomas Wouters (twouters)
Date: 2000-09-25 14:38

Message:
Shouldn't this patch be either postponed or checked in?

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-09-15 11:18

Message:
Accepted. Assuming you've tested this, it looks fine to me.
Can you time this a bit?

There's one niggling issue: some people think that before you do memcmp() you should manually compare the first character. Others think that's unnecessary (since a good compiler can inline memcmp anyway). (It's also a bit scary if the size is zero.) So please ignore this but keep it in mind for timing experiments. :)

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2000-09-14 13:51

Message:
Guido, please review (since Vladimir's away).

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2000-09-14 09:26

Message:
Revised patch:
Instead of defining a function to do the fast string comparison, use a macro, but let it use the documented string object API (PyString_GET_SIZE(), PyString_AS_STRING()) instead of breaking the encapsulation in the code.  This avoids all function calls to do the string compare, except memcmp() (which good compilers can inline anyway).

Vladimir, take a look at this; if you're happy, I'm happy, and you can check it in.  Thanks!

----------------------------------------------------------------------

Comment By: Vladimir Marangozov (marangoz)
Date: 2000-09-05 06:08

Message:
Argh! These Web interfaces strike again - forgot to login.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2000-09-05 06:05

Message:
Correct!

But then, aren't the current "else" if(cmp == 0) clauses risky after
PyObject_Compare()? An exception may be set in external code
while making Object_Compare() to return 0! Perhaps not in Python
source, but in buggy extensions. lookdict() will then overlook this "hit".

Patch updated, without "else" clauses and with the 1st char check in
string_compare_equal().

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-09-04 06:45

Message:
Quick comments: we should *always* call PyErr_Occurred() after PyObject_Compare() (and PyErr_Clear() if PyErr_Occurred() returned true). PyErr_Compare() really doesn't expect a pending exception coming in and so *not* clearing the error might break the *next* PyErr_Compare() call. (This doesn't happen typically but PyObject_Compare() can execute arbitrary code, some of which might call PyErr_Occurred() without calling PyErr_Clear() first.)

----------------------------------------------------------------------

Comment By: Vladimir Marangozov (marangoz)
Date: 2000-09-03 21:09

Message:
Let's add a comment, although this has been raised on python-dev.
This patch proposes a couple of ideas for optimizing & speeding dict
lookups -- not all of them need to be applied though.

- clear the eventual errors from Object_Compare only on need
   (this logic needs to be double-checked once again to see whether it
   really works)
- defer variable initializations after the most common return cases
- specialize string_compare() for lookdict_string. The test comparing
   the first char, before calling memcmp(), can be added too.
- inline the first item probe in PyDict_GetItem. This saves a func call
   for the most common case (common to lookdict & lookdict_string).

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=401394&group_id=5470


From noreply@sourceforge.net  Fri May 18 20:03:49 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 18 May 2001 12:03:49 -0700
Subject: [Patches] [ python-Patches-401394 ] lookdict optimizations
Message-ID: <E150pXR-0006mV-00@usw-sf-web1.sourceforge.net>

Patches item #401394, was updated on 2000-09-01 14:13
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=401394&group_id=5470

Category: core (C code)
Group: None
Status: Open
Resolution: Out of Date
Priority: 5
Submitted By: Vladimir Marangozov (marangoz)
>Assigned to: Tim Peters (tim_one)
Summary: lookdict optimizations

Initial Comment:
 

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-05-18 12:03

Message:
Logged In: YES 
user_id=6380

Assigning to Tim, who (by the fact that he is reviewing it
:-) is more qualified to own this patch than Fred.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-18 12:01

Message:
Logged In: YES 
user_id=31435

Marked Out of Date:  I've fiddled the dict code quite a bit 
in the meantime.  Changing the computation of the initial 
table index reduced the # of collisions, so the case this 
is aiming at is probably less frequent now.  The guts of 
the loop have been reordered to check for dummy last in 
every case, so "inlining the first collision probe" 
probably doesn't buy anything anymore.  Using a length 
check is probably still helpful:  you're effectively 
creating a Py_EQ string richcmp here, but inlined.  It will 
be less helpful once strings grow a tp_richcompare slot, 
because that will almost certainly do a Py_EQ length check 
too (e.g., Martin's pending patch does).

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-02-19 13:19

Message:
This patch optimizes what appears to be a small corner case (string keys in a string-only dict that have hash collisions), but the cause can indeed come up.

I need to spend a little time instrumenting the code to determine how often this corner case occurs, and haven't had time to do that yet.

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2001-02-09 16:11

Message:
Is this patch still revelant?


----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2000-09-25 18:52

Message:
It's postponed since I've not had time to run performance tests to measure the corner case it aims to improve.  It turns out that generating the test data I need takes a long time (I need hash collisions of identifier-like strings).  I just need to be able to let my generator run for a long time (it was generating more collisions than I'd expected, but I don't know how many off-hand).

Another interesting metric would be to examine the .pyc files generated from the standard library and find out if there are any string hash collisions there -- if not, or if very few, it's not worth the added complexity.

----------------------------------------------------------------------

Comment By: Thomas Wouters (twouters)
Date: 2000-09-25 14:38

Message:
Shouldn't this patch be either postponed or checked in?

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-09-15 11:18

Message:
Accepted. Assuming you've tested this, it looks fine to me.
Can you time this a bit?

There's one niggling issue: some people think that before you do memcmp() you should manually compare the first character. Others think that's unnecessary (since a good compiler can inline memcmp anyway). (It's also a bit scary if the size is zero.) So please ignore this but keep it in mind for timing experiments. :)

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2000-09-14 13:51

Message:
Guido, please review (since Vladimir's away).

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2000-09-14 09:26

Message:
Revised patch:
Instead of defining a function to do the fast string comparison, use a macro, but let it use the documented string object API (PyString_GET_SIZE(), PyString_AS_STRING()) instead of breaking the encapsulation in the code.  This avoids all function calls to do the string compare, except memcmp() (which good compilers can inline anyway).

Vladimir, take a look at this; if you're happy, I'm happy, and you can check it in.  Thanks!

----------------------------------------------------------------------

Comment By: Vladimir Marangozov (marangoz)
Date: 2000-09-05 06:08

Message:
Argh! These Web interfaces strike again - forgot to login.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2000-09-05 06:05

Message:
Correct!

But then, aren't the current "else" if(cmp == 0) clauses risky after
PyObject_Compare()? An exception may be set in external code
while making Object_Compare() to return 0! Perhaps not in Python
source, but in buggy extensions. lookdict() will then overlook this "hit".

Patch updated, without "else" clauses and with the 1st char check in
string_compare_equal().

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-09-04 06:45

Message:
Quick comments: we should *always* call PyErr_Occurred() after PyObject_Compare() (and PyErr_Clear() if PyErr_Occurred() returned true). PyErr_Compare() really doesn't expect a pending exception coming in and so *not* clearing the error might break the *next* PyErr_Compare() call. (This doesn't happen typically but PyObject_Compare() can execute arbitrary code, some of which might call PyErr_Occurred() without calling PyErr_Clear() first.)

----------------------------------------------------------------------

Comment By: Vladimir Marangozov (marangoz)
Date: 2000-09-03 21:09

Message:
Let's add a comment, although this has been raised on python-dev.
This patch proposes a couple of ideas for optimizing & speeding dict
lookups -- not all of them need to be applied though.

- clear the eventual errors from Object_Compare only on need
   (this logic needs to be double-checked once again to see whether it
   really works)
- defer variable initializations after the most common return cases
- specialize string_compare() for lookdict_string. The test comparing
   the first char, before calling memcmp(), can be added too.
- inline the first item probe in PyDict_GetItem. This saves a func call
   for the most common case (common to lookdict & lookdict_string).

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=401394&group_id=5470


From noreply@sourceforge.net  Sun May 20 04:40:15 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 19 May 2001 20:40:15 -0700
Subject: [Patches] [ python-Patches-425242 ] Patch which "inlines" small dictionaries
Message-ID: <E151K4l-0003UX-00@usw-sf-web1.sourceforge.net>

Patches item #425242, was updated on 2001-05-18 10:15
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=425242&group_id=5470

Category: core (C code)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: M.-A. Lemburg (lemburg)
>Assigned to: Jeremy Hylton (jhylton)
>Summary: Patch which "inlines" small dictionaries

Initial Comment:
As discussed on python-dev, this patch inlines small
dictionary tables directly in the dictionary object.

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-05-19 20:40

Message:
Logged In: YES 
user_id=31435

Assigned to Jeremy since he's been timing stuff lately 
too:  care to give it a try?

timdict.patch is in some ways more aggressive than MAL's 
patch, taking advantage of that we always have *some* 
memory to point to now, thus allowing to get rid of a bunch 
of table==NULL? tests and associated gotos and labels.

The newer patch passes all the tests I've thrown at it, in 
debug and release builds.  It was a major bitch to get 
working correctly, due to an excruciating interaction among 
PyDict_Clear() and garbage collection and module 
finalization and the special treatment of __builtins__ (who 
would have guessed that allocating a tuple could cause a 
module to finalize!?).

I never figured out why MAL's patch died, and after 
spending 10 hours figuring out why mine did, don't intend 
to waste the rest of the weekend trying <wink>.


----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-18 10:21

Message:
Logged In: YES 
user_id=38388

This is just a quick update of the original patch which I
prepared for Python 1.5 some years ago. Since the dictionary
implementation has evolved somewhat since then, I'm not sure
whether it still works as robust as it does for Python 1.5
(I've been using this for years without any problem).

Running the test suite, their appears to be a hanger due to
some endless loop which occurrs for test_popen2. I'm not
sure where Python hangs, but it could well be that the
resize routines have to adapted a little for the current
dict implementation.



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=425242&group_id=5470


From noreply@sourceforge.net  Sun May 20 23:30:38 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 20 May 2001 15:30:38 -0700
Subject: [Patches] [ python-Patches-425242 ] Patch which "inlines" small dictionaries
Message-ID: <E151big-0005lL-00@usw-sf-web2.sourceforge.net>

Patches item #425242, was updated on 2001-05-18 10:15
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=425242&group_id=5470

Category: core (C code)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: M.-A. Lemburg (lemburg)
Assigned to: Jeremy Hylton (jhylton)
>Summary: Patch which "inlines" small dictionaries

Initial Comment:
As discussed on python-dev, this patch inlines small
dictionary tables directly in the dictionary object.

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-05-20 15:30

Message:
Logged In: YES 
user_id=31435

timdict2.patch is more aggressive about iterating until 
we've seen fill non-virgin entries go by rather than the 
table size.  This is never slower but is sometimes a 
surprising win!  For example, dicts keyed by a contiguous 
range of small integers tend to fill a solid initial 
segment of the dict.  When resizing or copying, after the 
patch it's common for the loop to get out, e.g., after ~170 
iterations instead of (the current, and always) 256.

Also added some desperately needed comments about what the 
GF(2^n-{0}) business means in pragmatic terms; + a few 
assorted cleanups.

I think this is ready for prime time, but do have concerns 
about the increased memory use (embedding an 8-slot table 
in every dict object means every dict bites another 8*3*4 
== 96 bytes on a 32-bit box; OTOH, dicts with up to and 
including 5 entries never need more space than that, and 
dicts with 3, 4 or 5 entries were actually larger before 
due to the malloc overhead tagging along with their 
dynamically allocated 8-slot table).

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-19 20:40

Message:
Logged In: YES 
user_id=31435

Assigned to Jeremy since he's been timing stuff lately 
too:  care to give it a try?

timdict.patch is in some ways more aggressive than MAL's 
patch, taking advantage of that we always have *some* 
memory to point to now, thus allowing to get rid of a bunch 
of table==NULL? tests and associated gotos and labels.

The newer patch passes all the tests I've thrown at it, in 
debug and release builds.  It was a major bitch to get 
working correctly, due to an excruciating interaction among 
PyDict_Clear() and garbage collection and module 
finalization and the special treatment of __builtins__ (who 
would have guessed that allocating a tuple could cause a 
module to finalize!?).

I never figured out why MAL's patch died, and after 
spending 10 hours figuring out why mine did, don't intend 
to waste the rest of the weekend trying <wink>.


----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-18 10:21

Message:
Logged In: YES 
user_id=38388

This is just a quick update of the original patch which I
prepared for Python 1.5 some years ago. Since the dictionary
implementation has evolved somewhat since then, I'm not sure
whether it still works as robust as it does for Python 1.5
(I've been using this for years without any problem).

Running the test suite, their appears to be a hanger due to
some endless loop which occurrs for test_popen2. I'm not
sure where Python hangs, but it could well be that the
resize routines have to adapted a little for the current
dict implementation.



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=425242&group_id=5470


From noreply@sourceforge.net  Sun May 20 23:31:15 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 20 May 2001 15:31:15 -0700
Subject: [Patches] [ python-Patches-425242 ] Patch which "inlines" small dictionaries
Message-ID: <E151bjH-0005lr-00@usw-sf-web2.sourceforge.net>

Patches item #425242, was updated on 2001-05-18 10:15
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=425242&group_id=5470

Category: core (C code)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: M.-A. Lemburg (lemburg)
Assigned to: Jeremy Hylton (jhylton)
>Summary: Patch which "inlines" small dictionaries

Initial Comment:
As discussed on python-dev, this patch inlines small
dictionary tables directly in the dictionary object.

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-05-20 15:31

Message:
Logged In: YES 
user_id=31435

Just deleted my first patch.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-20 15:30

Message:
Logged In: YES 
user_id=31435

timdict2.patch is more aggressive about iterating until 
we've seen fill non-virgin entries go by rather than the 
table size.  This is never slower but is sometimes a 
surprising win!  For example, dicts keyed by a contiguous 
range of small integers tend to fill a solid initial 
segment of the dict.  When resizing or copying, after the 
patch it's common for the loop to get out, e.g., after ~170 
iterations instead of (the current, and always) 256.

Also added some desperately needed comments about what the 
GF(2^n-{0}) business means in pragmatic terms; + a few 
assorted cleanups.

I think this is ready for prime time, but do have concerns 
about the increased memory use (embedding an 8-slot table 
in every dict object means every dict bites another 8*3*4 
== 96 bytes on a 32-bit box; OTOH, dicts with up to and 
including 5 entries never need more space than that, and 
dicts with 3, 4 or 5 entries were actually larger before 
due to the malloc overhead tagging along with their 
dynamically allocated 8-slot table).

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-19 20:40

Message:
Logged In: YES 
user_id=31435

Assigned to Jeremy since he's been timing stuff lately 
too:  care to give it a try?

timdict.patch is in some ways more aggressive than MAL's 
patch, taking advantage of that we always have *some* 
memory to point to now, thus allowing to get rid of a bunch 
of table==NULL? tests and associated gotos and labels.

The newer patch passes all the tests I've thrown at it, in 
debug and release builds.  It was a major bitch to get 
working correctly, due to an excruciating interaction among 
PyDict_Clear() and garbage collection and module 
finalization and the special treatment of __builtins__ (who 
would have guessed that allocating a tuple could cause a 
module to finalize!?).

I never figured out why MAL's patch died, and after 
spending 10 hours figuring out why mine did, don't intend 
to waste the rest of the weekend trying <wink>.


----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-18 10:21

Message:
Logged In: YES 
user_id=38388

This is just a quick update of the original patch which I
prepared for Python 1.5 some years ago. Since the dictionary
implementation has evolved somewhat since then, I'm not sure
whether it still works as robust as it does for Python 1.5
(I've been using this for years without any problem).

Running the test suite, their appears to be a hanger due to
some endless loop which occurrs for test_popen2. I'm not
sure where Python hangs, but it could well be that the
resize routines have to adapted a little for the current
dict implementation.



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=425242&group_id=5470


From noreply@sourceforge.net  Mon May 21 06:12:45 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 20 May 2001 22:12:45 -0700
Subject: [Patches] [ python-Patches-425821 ] pygettext.py sorted output
Message-ID: <E151hzp-0002Ue-00@usw-sf-web1.sourceforge.net>

Patches item #425821, was updated on 2001-05-20 22:12
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=425821&group_id=5470

Category: demos and tools
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Tokio Kikuchi (tkikuchi)
Assigned to: Nobody/Anonymous (nobody)
Summary: pygettext.py sorted output

Initial Comment:
Sort the output of pygettext.py by filename/linenumber order. 
Both solaris and GNU formats are retained but no more random output.
Some nice feature of packing the GNU style location is lost for easier coding.



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=425821&group_id=5470


From noreply@sourceforge.net  Mon May 21 09:25:42 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 21 May 2001 01:25:42 -0700
Subject: [Patches] [ python-Patches-425242 ] Patch which "inlines" small dictionaries
Message-ID: <E151l0Y-0008Ns-00@usw-sf-web3.sourceforge.net>

Patches item #425242, was updated on 2001-05-18 10:15
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=425242&group_id=5470

Category: core (C code)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: M.-A. Lemburg (lemburg)
Assigned to: Jeremy Hylton (jhylton)
>Summary: Patch which "inlines" small dictionaries

Initial Comment:
As discussed on python-dev, this patch inlines small
dictionary tables directly in the dictionary object.

----------------------------------------------------------------------

>Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-21 01:25

Message:
Logged In: YES 
user_id=38388

Hmm, timdict2.patch seems to be a completly different
solution. What I am missing in that patch is the ability to
tune the implementation... what happens if I want to bump
MINSIZE to some higher value ? I think the patch should at
least include an explanation of how this can be done.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-20 15:31

Message:
Logged In: YES 
user_id=31435

Just deleted my first patch.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-20 15:30

Message:
Logged In: YES 
user_id=31435

timdict2.patch is more aggressive about iterating until 
we've seen fill non-virgin entries go by rather than the 
table size.  This is never slower but is sometimes a 
surprising win!  For example, dicts keyed by a contiguous 
range of small integers tend to fill a solid initial 
segment of the dict.  When resizing or copying, after the 
patch it's common for the loop to get out, e.g., after ~170 
iterations instead of (the current, and always) 256.

Also added some desperately needed comments about what the 
GF(2^n-{0}) business means in pragmatic terms; + a few 
assorted cleanups.

I think this is ready for prime time, but do have concerns 
about the increased memory use (embedding an 8-slot table 
in every dict object means every dict bites another 8*3*4 
== 96 bytes on a 32-bit box; OTOH, dicts with up to and 
including 5 entries never need more space than that, and 
dicts with 3, 4 or 5 entries were actually larger before 
due to the malloc overhead tagging along with their 
dynamically allocated 8-slot table).

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-19 20:40

Message:
Logged In: YES 
user_id=31435

Assigned to Jeremy since he's been timing stuff lately 
too:  care to give it a try?

timdict.patch is in some ways more aggressive than MAL's 
patch, taking advantage of that we always have *some* 
memory to point to now, thus allowing to get rid of a bunch 
of table==NULL? tests and associated gotos and labels.

The newer patch passes all the tests I've thrown at it, in 
debug and release builds.  It was a major bitch to get 
working correctly, due to an excruciating interaction among 
PyDict_Clear() and garbage collection and module 
finalization and the special treatment of __builtins__ (who 
would have guessed that allocating a tuple could cause a 
module to finalize!?).

I never figured out why MAL's patch died, and after 
spending 10 hours figuring out why mine did, don't intend 
to waste the rest of the weekend trying <wink>.


----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-18 10:21

Message:
Logged In: YES 
user_id=38388

This is just a quick update of the original patch which I
prepared for Python 1.5 some years ago. Since the dictionary
implementation has evolved somewhat since then, I'm not sure
whether it still works as robust as it does for Python 1.5
(I've been using this for years without any problem).

Running the test suite, their appears to be a hanger due to
some endless loop which occurrs for test_popen2. I'm not
sure where Python hangs, but it could well be that the
resize routines have to adapted a little for the current
dict implementation.



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=425242&group_id=5470


From noreply@sourceforge.net  Mon May 21 10:07:31 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 21 May 2001 02:07:31 -0700
Subject: [Patches] [ python-Patches-425242 ] Patch which "inlines" small dictionaries
Message-ID: <E151lf1-0006Eu-00@usw-sf-web1.sourceforge.net>

Patches item #425242, was updated on 2001-05-18 10:15
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=425242&group_id=5470

Category: core (C code)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: M.-A. Lemburg (lemburg)
Assigned to: Jeremy Hylton (jhylton)
>Summary: Patch which "inlines" small dictionaries

Initial Comment:
As discussed on python-dev, this patch inlines small
dictionary tables directly in the dictionary object.

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-05-21 02:07

Message:
Logged In: YES 
user_id=31435

There's more explanation about how to bump MINSIZE in the 
patch than in current dictobject.c.  Read the new 
comments!  You have to choose a power of 2 and fiddle the 
polys[] vector to match.  That's all.

The code defines a ma_smalltable member just as yours did.  
The rest is details.  Primarily it's more aggressive about 
exploiting the new member, because I found it was more 
efficient to avoid undue work in the empty case by looping 
on the ma_fill count rather than by continuing to 
constantly fiddle around with NULL-pointer checks all over 
dictobject.c (they've been replaced by asserts).  It does 
pay for a memset() of the ma_smalltable member during 
creation, though.

It would be interesting to try both patches, but I spent 
too much time on this already to debug your patch too.  It 
would be good if you could upload a new version of your 
patch.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-21 01:25

Message:
Logged In: YES 
user_id=38388

Hmm, timdict2.patch seems to be a completly different
solution. What I am missing in that patch is the ability to
tune the implementation... what happens if I want to bump
MINSIZE to some higher value ? I think the patch should at
least include an explanation of how this can be done.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-20 15:31

Message:
Logged In: YES 
user_id=31435

Just deleted my first patch.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-20 15:30

Message:
Logged In: YES 
user_id=31435

timdict2.patch is more aggressive about iterating until 
we've seen fill non-virgin entries go by rather than the 
table size.  This is never slower but is sometimes a 
surprising win!  For example, dicts keyed by a contiguous 
range of small integers tend to fill a solid initial 
segment of the dict.  When resizing or copying, after the 
patch it's common for the loop to get out, e.g., after ~170 
iterations instead of (the current, and always) 256.

Also added some desperately needed comments about what the 
GF(2^n-{0}) business means in pragmatic terms; + a few 
assorted cleanups.

I think this is ready for prime time, but do have concerns 
about the increased memory use (embedding an 8-slot table 
in every dict object means every dict bites another 8*3*4 
== 96 bytes on a 32-bit box; OTOH, dicts with up to and 
including 5 entries never need more space than that, and 
dicts with 3, 4 or 5 entries were actually larger before 
due to the malloc overhead tagging along with their 
dynamically allocated 8-slot table).

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-19 20:40

Message:
Logged In: YES 
user_id=31435

Assigned to Jeremy since he's been timing stuff lately 
too:  care to give it a try?

timdict.patch is in some ways more aggressive than MAL's 
patch, taking advantage of that we always have *some* 
memory to point to now, thus allowing to get rid of a bunch 
of table==NULL? tests and associated gotos and labels.

The newer patch passes all the tests I've thrown at it, in 
debug and release builds.  It was a major bitch to get 
working correctly, due to an excruciating interaction among 
PyDict_Clear() and garbage collection and module 
finalization and the special treatment of __builtins__ (who 
would have guessed that allocating a tuple could cause a 
module to finalize!?).

I never figured out why MAL's patch died, and after 
spending 10 hours figuring out why mine did, don't intend 
to waste the rest of the weekend trying <wink>.


----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-18 10:21

Message:
Logged In: YES 
user_id=38388

This is just a quick update of the original patch which I
prepared for Python 1.5 some years ago. Since the dictionary
implementation has evolved somewhat since then, I'm not sure
whether it still works as robust as it does for Python 1.5
(I've been using this for years without any problem).

Running the test suite, their appears to be a hanger due to
some endless loop which occurrs for test_popen2. I'm not
sure where Python hangs, but it could well be that the
resize routines have to adapted a little for the current
dict implementation.



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=425242&group_id=5470


From noreply@sourceforge.net  Mon May 21 14:53:58 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 21 May 2001 06:53:58 -0700
Subject: [Patches] [ python-Patches-425242 ] Patch which "inlines" small dictionaries
Message-ID: <E151q8E-0004H8-00@usw-sf-web3.sourceforge.net>

Patches item #425242, was updated on 2001-05-18 10:15
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=425242&group_id=5470

Category: core (C code)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: M.-A. Lemburg (lemburg)
Assigned to: Jeremy Hylton (jhylton)
>Summary: Patch which "inlines" small dictionaries

Initial Comment:
As discussed on python-dev, this patch inlines small
dictionary tables directly in the dictionary object.

----------------------------------------------------------------------

>Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-21 06:53

Message:
Logged In: YES 
user_id=38388

I've tested both patches against the unpatched CVS version
with pystone. The results are surprising: CVS benchmarks at
2300 pystones while your patch runs at 2200 pystones and my
patch at 2100 pystones.

I think we need to put some more thought into this...

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-21 02:07

Message:
Logged In: YES 
user_id=31435

There's more explanation about how to bump MINSIZE in the 
patch than in current dictobject.c.  Read the new 
comments!  You have to choose a power of 2 and fiddle the 
polys[] vector to match.  That's all.

The code defines a ma_smalltable member just as yours did.  
The rest is details.  Primarily it's more aggressive about 
exploiting the new member, because I found it was more 
efficient to avoid undue work in the empty case by looping 
on the ma_fill count rather than by continuing to 
constantly fiddle around with NULL-pointer checks all over 
dictobject.c (they've been replaced by asserts).  It does 
pay for a memset() of the ma_smalltable member during 
creation, though.

It would be interesting to try both patches, but I spent 
too much time on this already to debug your patch too.  It 
would be good if you could upload a new version of your 
patch.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-21 01:25

Message:
Logged In: YES 
user_id=38388

Hmm, timdict2.patch seems to be a completly different
solution. What I am missing in that patch is the ability to
tune the implementation... what happens if I want to bump
MINSIZE to some higher value ? I think the patch should at
least include an explanation of how this can be done.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-20 15:31

Message:
Logged In: YES 
user_id=31435

Just deleted my first patch.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-20 15:30

Message:
Logged In: YES 
user_id=31435

timdict2.patch is more aggressive about iterating until 
we've seen fill non-virgin entries go by rather than the 
table size.  This is never slower but is sometimes a 
surprising win!  For example, dicts keyed by a contiguous 
range of small integers tend to fill a solid initial 
segment of the dict.  When resizing or copying, after the 
patch it's common for the loop to get out, e.g., after ~170 
iterations instead of (the current, and always) 256.

Also added some desperately needed comments about what the 
GF(2^n-{0}) business means in pragmatic terms; + a few 
assorted cleanups.

I think this is ready for prime time, but do have concerns 
about the increased memory use (embedding an 8-slot table 
in every dict object means every dict bites another 8*3*4 
== 96 bytes on a 32-bit box; OTOH, dicts with up to and 
including 5 entries never need more space than that, and 
dicts with 3, 4 or 5 entries were actually larger before 
due to the malloc overhead tagging along with their 
dynamically allocated 8-slot table).

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-19 20:40

Message:
Logged In: YES 
user_id=31435

Assigned to Jeremy since he's been timing stuff lately 
too:  care to give it a try?

timdict.patch is in some ways more aggressive than MAL's 
patch, taking advantage of that we always have *some* 
memory to point to now, thus allowing to get rid of a bunch 
of table==NULL? tests and associated gotos and labels.

The newer patch passes all the tests I've thrown at it, in 
debug and release builds.  It was a major bitch to get 
working correctly, due to an excruciating interaction among 
PyDict_Clear() and garbage collection and module 
finalization and the special treatment of __builtins__ (who 
would have guessed that allocating a tuple could cause a 
module to finalize!?).

I never figured out why MAL's patch died, and after 
spending 10 hours figuring out why mine did, don't intend 
to waste the rest of the weekend trying <wink>.


----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-18 10:21

Message:
Logged In: YES 
user_id=38388

This is just a quick update of the original patch which I
prepared for Python 1.5 some years ago. Since the dictionary
implementation has evolved somewhat since then, I'm not sure
whether it still works as robust as it does for Python 1.5
(I've been using this for years without any problem).

Running the test suite, their appears to be a hanger due to
some endless loop which occurrs for test_popen2. I'm not
sure where Python hangs, but it could well be that the
resize routines have to adapted a little for the current
dict implementation.



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=425242&group_id=5470


From noreply@sourceforge.net  Mon May 21 16:33:33 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 21 May 2001 08:33:33 -0700
Subject: [Patches] [ python-Patches-424335 ] richcompare for strings
Message-ID: <E151rgb-0008H8-00@usw-sf-web2.sourceforge.net>

Patches item #424335, was updated on 2001-05-15 12:54
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=424335&group_id=5470

Category: core (C code)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Martin v. Löwis (loewis)
Assigned to: Nobody/Anonymous (nobody)
Summary: richcompare for strings

Initial Comment:
This patch implements the tp_richcompare slot for
string objects. It shows a 8% speed-up on selected test
cases.

----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2001-05-21 08:33

Message:
Logged In: YES 
user_id=21627

The new revision of the patch entirely removes tp_compare
for string, following discussions on python-dev. The only
direct user of string_compare has been changed to use the
new function _PyString_Eq instead.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=424335&group_id=5470


From noreply@sourceforge.net  Mon May 21 16:34:11 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 21 May 2001 08:34:11 -0700
Subject: [Patches] [ python-Patches-425821 ] pygettext.py sorted output
Message-ID: <E151rhD-0008Hj-00@usw-sf-web2.sourceforge.net>

Patches item #425821, was updated on 2001-05-20 22:12
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=425821&group_id=5470

Category: demos and tools
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Tokio Kikuchi (tkikuchi)
>Assigned to: Barry Warsaw (bwarsaw)
Summary: pygettext.py sorted output

Initial Comment:
Sort the output of pygettext.py by filename/linenumber order. 
Both solaris and GNU formats are retained but no more random output.
Some nice feature of packing the GNU style location is lost for easier coding.



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=425821&group_id=5470


From noreply@sourceforge.net  Mon May 21 17:57:52 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 21 May 2001 09:57:52 -0700
Subject: [Patches] [ python-Patches-424475 ] Speed-up tp_compare usage
Message-ID: <E151t0C-0006tI-00@usw-sf-web3.sourceforge.net>

Patches item #424475, was updated on 2001-05-16 01:07
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=424475&group_id=5470

Category: core (C code)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Martin v. Löwis (loewis)
Assigned to: Nobody/Anonymous (nobody)
Summary: Speed-up tp_compare usage

Initial Comment:
This patch tries to optimize PyObject_RichCompare for
the common case of objects with equal types which
support tp_compare. It gives a speed-up of roughly 7%
for comparing strings in a loop.

The patch also gives type objects a tp_compare
function, so that they can make use of the improvement.

----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2001-05-21 09:57

Message:
Logged In: YES 
user_id=21627

The revised patch prefers tp_compare over tp_richcompare in
do_cmp if both are available. It also restores
UserList.__cmp__ from deprecation.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=424475&group_id=5470


From noreply@sourceforge.net  Mon May 21 20:22:02 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 21 May 2001 12:22:02 -0700
Subject: [Patches] [ python-Patches-425821 ] pygettext.py sorted output
Message-ID: <E151vFi-0008Oy-00@usw-sf-web1.sourceforge.net>

Patches item #425821, was updated on 2001-05-20 22:12
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=425821&group_id=5470

Category: demos and tools
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Tokio Kikuchi (tkikuchi)
Assigned to: Barry Warsaw (bwarsaw)
Summary: pygettext.py sorted output

Initial Comment:
Sort the output of pygettext.py by filename/linenumber order. 
Both solaris and GNU formats are retained but no more random output.
Some nice feature of packing the GNU style location is lost for easier coding.



----------------------------------------------------------------------

>Comment By: Barry Warsaw (bwarsaw)
Date: 2001-05-21 12:22

Message:
Logged In: YES 
user_id=12800

Here's a slightly different version of the patch, which
retains packed GNU style format, but still sorts by filename
and then by linenumber.

Note that this also fixes a bug with duplicate entries.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=425821&group_id=5470


From noreply@sourceforge.net  Mon May 21 20:34:44 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 21 May 2001 12:34:44 -0700
Subject: [Patches] [ python-Patches-425821 ] pygettext.py sorted output
Message-ID: <E151vS0-0002lP-00@usw-sf-web2.sourceforge.net>

Patches item #425821, was updated on 2001-05-20 22:12
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=425821&group_id=5470

Category: demos and tools
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Tokio Kikuchi (tkikuchi)
Assigned to: Barry Warsaw (bwarsaw)
Summary: pygettext.py sorted output

Initial Comment:
Sort the output of pygettext.py by filename/linenumber order. 
Both solaris and GNU formats are retained but no more random output.
Some nice feature of packing the GNU style location is lost for easier coding.



----------------------------------------------------------------------

>Comment By: Barry Warsaw (bwarsaw)
Date: 2001-05-21 12:34

Message:
Logged In: YES 
user_id=12800

This patch is included in pygettext.py 1.14

----------------------------------------------------------------------

Comment By: Barry Warsaw (bwarsaw)
Date: 2001-05-21 12:22

Message:
Logged In: YES 
user_id=12800

Here's a slightly different version of the patch, which
retains packed GNU style format, but still sorts by filename
and then by linenumber.

Note that this also fixes a bug with duplicate entries.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=425821&group_id=5470


From noreply@sourceforge.net  Mon May 21 20:58:08 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 21 May 2001 12:58:08 -0700
Subject: [Patches] [ python-Patches-402223 ] --default-domain fix for Tools/i18n/pygettext.py
Message-ID: <E151voe-0000tc-00@usw-sf-web3.sourceforge.net>

Patches item #402223, was updated on 2000-11-02 03:06
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=402223&group_id=5470

Category: demos and tools
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Bastian Kleineidam (calvin)
Assigned to: Barry Warsaw (bwarsaw)
Summary: --default-domain fix for Tools/i18n/pygettext.py

Initial Comment:
 

----------------------------------------------------------------------

>Comment By: Barry Warsaw (bwarsaw)
Date: 2001-05-21 12:58

Message:
Logged In: YES 
user_id=12800

Finally got around to applying this patch (to pygettext.py
1.16).  Thanks!

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=402223&group_id=5470


From noreply@sourceforge.net  Mon May 21 21:32:01 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 21 May 2001 13:32:01 -0700
Subject: [Patches] [ python-Patches-423830 ] Spurious Install Warning
Message-ID: <E151wLR-0003Pn-00@usw-sf-web2.sourceforge.net>

Patches item #423830, was updated on 2001-05-13 18:48
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=423830&group_id=5470

Category: Build
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Kurt B. Kaiser (kbk)
Assigned to: Nobody/Anonymous (nobody)
Summary: Spurious Install Warning

Initial Comment:
During installation setup.py install is generating a
warning that the lib-dynload directory is not in
sys.path. While that is true for the instance of Python
doing the installation, the installed Python will have
the correct path. Suppress the warning during
installation.

Ref: Bug 232619, Bug 417472

----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2001-05-21 13:32

Message:
Logged In: YES 
user_id=11375

This has been fixed in a different way.  I don't want to 
add more magical behaviour to the install command by 
making it initialize differently depending on whether 
we're building Python or not. 

Instead, Python's setup.py has been changed to suppress the
message.

Thanks anyway!


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=423830&group_id=5470


From noreply@sourceforge.net  Mon May 21 21:38:24 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 21 May 2001 13:38:24 -0700
Subject: [Patches] [ python-Patches-425242 ] Patch which "inlines" small dictionaries
Message-ID: <E151wRc-0001S6-00@usw-sf-web3.sourceforge.net>

Patches item #425242, was updated on 2001-05-18 10:15
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=425242&group_id=5470

Category: core (C code)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: M.-A. Lemburg (lemburg)
Assigned to: Jeremy Hylton (jhylton)
>Summary: Patch which "inlines" small dictionaries

Initial Comment:
As discussed on python-dev, this patch inlines small
dictionary tables directly in the dictionary object.

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-05-21 13:38

Message:
Logged In: YES 
user_id=31435

On my WinTel Win2K box at work, current CVS is ~12350 
pystone w/o my patch and ~12500 with it.  Jeremy's timings 
on his Linux+gcc box show small but reproducible 
improvements on some other "realer" programs.  I'm not 
surprised if it actually slows things on *some* platforms, 
because that's the nature of low-level optimization work.  
But the changes simplify the code on frequent paths, 
reducing the start-to-finish operation counts, and over 
time that's the only thing that reliably improves x-
platform performance.

BTW, the pystone results suggest you could get a factor of 
6 improvement in an hour by buying a midrange new machine 
<wink>.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-21 06:53

Message:
Logged In: YES 
user_id=38388

I've tested both patches against the unpatched CVS version
with pystone. The results are surprising: CVS benchmarks at
2300 pystones while your patch runs at 2200 pystones and my
patch at 2100 pystones.

I think we need to put some more thought into this...

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-21 02:07

Message:
Logged In: YES 
user_id=31435

There's more explanation about how to bump MINSIZE in the 
patch than in current dictobject.c.  Read the new 
comments!  You have to choose a power of 2 and fiddle the 
polys[] vector to match.  That's all.

The code defines a ma_smalltable member just as yours did.  
The rest is details.  Primarily it's more aggressive about 
exploiting the new member, because I found it was more 
efficient to avoid undue work in the empty case by looping 
on the ma_fill count rather than by continuing to 
constantly fiddle around with NULL-pointer checks all over 
dictobject.c (they've been replaced by asserts).  It does 
pay for a memset() of the ma_smalltable member during 
creation, though.

It would be interesting to try both patches, but I spent 
too much time on this already to debug your patch too.  It 
would be good if you could upload a new version of your 
patch.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-21 01:25

Message:
Logged In: YES 
user_id=38388

Hmm, timdict2.patch seems to be a completly different
solution. What I am missing in that patch is the ability to
tune the implementation... what happens if I want to bump
MINSIZE to some higher value ? I think the patch should at
least include an explanation of how this can be done.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-20 15:31

Message:
Logged In: YES 
user_id=31435

Just deleted my first patch.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-20 15:30

Message:
Logged In: YES 
user_id=31435

timdict2.patch is more aggressive about iterating until 
we've seen fill non-virgin entries go by rather than the 
table size.  This is never slower but is sometimes a 
surprising win!  For example, dicts keyed by a contiguous 
range of small integers tend to fill a solid initial 
segment of the dict.  When resizing or copying, after the 
patch it's common for the loop to get out, e.g., after ~170 
iterations instead of (the current, and always) 256.

Also added some desperately needed comments about what the 
GF(2^n-{0}) business means in pragmatic terms; + a few 
assorted cleanups.

I think this is ready for prime time, but do have concerns 
about the increased memory use (embedding an 8-slot table 
in every dict object means every dict bites another 8*3*4 
== 96 bytes on a 32-bit box; OTOH, dicts with up to and 
including 5 entries never need more space than that, and 
dicts with 3, 4 or 5 entries were actually larger before 
due to the malloc overhead tagging along with their 
dynamically allocated 8-slot table).

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-19 20:40

Message:
Logged In: YES 
user_id=31435

Assigned to Jeremy since he's been timing stuff lately 
too:  care to give it a try?

timdict.patch is in some ways more aggressive than MAL's 
patch, taking advantage of that we always have *some* 
memory to point to now, thus allowing to get rid of a bunch 
of table==NULL? tests and associated gotos and labels.

The newer patch passes all the tests I've thrown at it, in 
debug and release builds.  It was a major bitch to get 
working correctly, due to an excruciating interaction among 
PyDict_Clear() and garbage collection and module 
finalization and the special treatment of __builtins__ (who 
would have guessed that allocating a tuple could cause a 
module to finalize!?).

I never figured out why MAL's patch died, and after 
spending 10 hours figuring out why mine did, don't intend 
to waste the rest of the weekend trying <wink>.


----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-18 10:21

Message:
Logged In: YES 
user_id=38388

This is just a quick update of the original patch which I
prepared for Python 1.5 some years ago. Since the dictionary
implementation has evolved somewhat since then, I'm not sure
whether it still works as robust as it does for Python 1.5
(I've been using this for years without any problem).

Running the test suite, their appears to be a hanger due to
some endless loop which occurrs for test_popen2. I'm not
sure where Python hangs, but it could well be that the
resize routines have to adapted a little for the current
dict implementation.



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=425242&group_id=5470


From noreply@sourceforge.net  Mon May 21 21:42:40 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 21 May 2001 13:42:40 -0700
Subject: [Patches] [ python-Patches-402313 ] shar output support
Message-ID: <E151wVk-0001PK-00@usw-sf-web1.sourceforge.net>

Patches item #402313, was updated on 2000-11-07 11:16
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=402313&group_id=5470

Category: distutils
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Greg Ward (gward)
>Assigned to: Barry Warsaw (bwarsaw)
Summary: shar output support

Initial Comment:
 

----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2001-05-21 13:42

Message:
Logged In: YES 
user_id=11375

Thinking about this some more, shar output seems of 
doubtful usefulness.  I'm tempted to ignore this patch.

Barry, do you want to argue for supporting shar?  
Reassign this patch to me if you still want it applied, 
or just close it if you want to forget about it.



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=402313&group_id=5470


From noreply@sourceforge.net  Mon May 21 21:43:22 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 21 May 2001 13:43:22 -0700
Subject: [Patches] [ python-Patches-403678 ] setup.py.in
Message-ID: <E151wWQ-0001WV-00@usw-sf-web3.sourceforge.net>

Patches item #403678, was updated on 2001-02-07 22:39
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403678&group_id=5470

Category: Build
Group: None
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Donn Cave (donnc)
Assigned to: A.M. Kuchling (akuchling)
Summary: setup.py.in

Initial Comment:
(Obsoletes part of #103487)  Use the "configure" procedure for platform
specific values in setup.py.  Build setup.py from setup.py.in - setup.cfg.in
was a nuisance anyway.  The particular configure options for setup.py in
this patch are for BeOS, but it would be worth a look to see if some or all
of the USE_xxx options there should get in there, especially if controlled
by --with-xxx flags.

----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2001-05-21 13:43

Message:
Logged In: YES 
user_id=11375

Now irrelevant.


----------------------------------------------------------------------

Comment By: The Written Word (china) (tww-china)
Date: 2001-03-01 01:17

Message:
Logged In: YES 
user_id=119770

I agree with donnc. We should definitely try and remove
platform-specific items, hard-coded paths, etc. from
setup.py. Let autoconf handle that. setup.py should be dumb
and driven by autoconf. We just ran into a situation where
we tried building 2.1CVS and wanted to feed -DUSE_SSL to
Modules/socketmodule.c. We're on a Solaris machine which
doesn't have libssl and libcrypto in the system linker
search path. So, we have to add -I<path> and -L<path>
options to the cc and ld line when Modules/socketmodule.c is
built. How do we do this with setup.py? Dunno. We currently
have a hack around this. I'd like a --with-ssl=<path> to
configure this at ./configure time and have that get passed
on to setup.py. Ditto for tk.

And, hard-coding /usr/local/include and /usr/local/lib is
just ugly.

Also, termios does not build "out of the box" under Solaris.
How do we disable this module?

----------------------------------------------------------------------

Comment By: Donn Cave (donnc)
Date: 2001-02-23 10:22

Message:
Yes, it's still waiting to be resolved.  The patch
at least illustrates the problems (and of course it
would also solve them if applied.)  I have been hoping
that you would put some thought into it, since your
sense of direction on it is at least clear enough to
know that it's different from where I would go.  Since
there's plenty of specific information about what needs
to be done, I would prefer that you do at least something
for it, in setup.py.  Then after you have wrestled with
the issues, I can check it out and see what you came up
with, and if necessary straighten out anything that doesn't
actually work.

If you want, I might be able to take a look at what it
would take to remove every single directory path literal
('/usr/X11R5', '/usr/lib/termcap', etc.), every platform
literal ('aix', 'sunos5', etc.) and every reference to a
platform specific flag ("linker_so + ' -shared' - what's
up with that?) and put it in configure if it's really
needed at all.  Don't know if I could get that done for
2.1a3, but the sooner that gets cleaned up the better.

----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2001-02-23 08:37

Message:
Donn, is this patch still relevant?  Do there remain BeOS-specific
issues to fix?  Probably separate patches and bugs should 
be opened to handle any outstanding problems.


----------------------------------------------------------------------

Comment By: Donn Cave (donnc)
Date: 2001-02-08 15:43

Message:
Not worried, just was trying to point out the good side of a
throw-away system for the dirty business of platform warts.
Anyway, with all that stuff to get done in setup.py, obviously
the release is a ways off yet.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-02-08 14:51

Message:
Na, it's  not higher, only in this case, the design is going in the
wrong direction. The new setup.py mechanism was meant to
allow as much automatic configuration as possible (previously
people had to edit Modules/Setup which was not difficult,
but obscure enough to keep people from enabling important
add-ons such as Tkinter). Now with the setup.py auto-detection
mechanisms in place, there should be much less user interaction
required to get a fully functional system.

As for the other patches: many of the Python core team are
currently out of town so there's a natural delay there. Nothing
to worry about though.

----------------------------------------------------------------------

Comment By: Donn Cave (donnc)
Date: 2001-02-08 11:16

Message:
I would be happy with extra symbols in Makefile, for
setup.py to use.  I think this system will be somewhat
obscure for someone trying to figure out how to make
a build work, so some pointer comments at the top of
setup.py would be good.  The last point there is not
so clear to me -- it sounds like there's an intent
to move a lot of logic from "configure" to setup.py.
I look forward to seeing whether that does give us much
more power and flexibility.  It will put some pressure
on the Python code base, though - I already have changes
in for distutils and even os.py, to get through the build,
not to mention the two unsuccessful attempts to get changes
into setup.py.  In 2.0, I came along pretty late in the beta
with changes that make it build for BeOS.  Here I am right
at the beginning of 2.1 alpha, but the hurdle seems a lot
higher.

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2001-02-08 10:45

Message:
One more reason for not using step.py.in or setup.cfg.in: 
The Makefile is available to distutils when building
extension modules after the source is gone (ie. its 
installed in lib).

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-02-08 10:29

Message:
I'd prefer if you'd put all the code into setup.py -- the tools are
all there. If you need extra symbols, then have configure place
them in the Makefile or config.h. Both are available for distutils
to use. Platform specifica can then be dealt with under Python's
control which gives you much more power and flexibility.

----------------------------------------------------------------------

Comment By: Donn Cave (donnc)
Date: 2001-02-08 10:12

Message:
That's OK with me, all I need is a place where I can
deal with platform specific issues, and it doesn't
matter a bit to me where.  setup.py.in, Makefile,
setup.cfg, write the stuff right into setup.py
(e.g., if platform == 'Darwin').  What do you like?

----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2001-02-08 08:38

Message:
Agreed; generating Makefiles from the configure script is bad enough, and generating executable scripts is worse still.  Reintroducing setup.cfg.in would be better, if that proves necessary.


----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-02-08 05:01

Message:
Using setup.py.in is the wrong strategy here: you should consider
placing the symbols into the generated Makefile or config.h
and then have setup.py parse these files (the tools for this
are all there in distutils).

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403678&group_id=5470


From noreply@sourceforge.net  Mon May 21 21:45:16 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 21 May 2001 13:45:16 -0700
Subject: [Patches] [ python-Patches-402313 ] shar output support
Message-ID: <E151wYG-0001TL-00@usw-sf-web1.sourceforge.net>

Patches item #402313, was updated on 2000-11-07 11:16
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=402313&group_id=5470

Category: distutils
Group: None
>Status: Closed
>Resolution: Rejected
Priority: 5
Submitted By: Greg Ward (gward)
Assigned to: Barry Warsaw (bwarsaw)
Summary: shar output support

Initial Comment:
 

----------------------------------------------------------------------

>Comment By: Barry Warsaw (bwarsaw)
Date: 2001-05-21 13:45

Message:
Logged In: YES 
user_id=12800

I agree that it is of doubtful usefulness, so I'm closing
it.  Also, because of the semantics of shar's options, it
turned out to be not very easy to integrate it with
distutils.


----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2001-05-21 13:42

Message:
Logged In: YES 
user_id=11375

Thinking about this some more, shar output seems of 
doubtful usefulness.  I'm tempted to ignore this patch.

Barry, do you want to argue for supporting shar?  
Reassign this patch to me if you still want it applied, 
or just close it if you want to forget about it.



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=402313&group_id=5470


From noreply@sourceforge.net  Mon May 21 21:48:27 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 21 May 2001 13:48:27 -0700
Subject: [Patches] [ python-Patches-411055 ] Delete unimportable extensions
Message-ID: <E151wbL-0001bC-00@usw-sf-web3.sourceforge.net>

Patches item #411055, was updated on 2001-03-24 08:13
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=411055&group_id=5470

Category: Build
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Martin v. Löwis (loewis)
Assigned to: A.M. Kuchling (akuchling)
Summary: Delete unimportable extensions

Initial Comment:
If building an extension module succeeds, the module
may still be unimportable, e.g. because not all symbols
can be resolved. This patch arranges to import every
module after it has been built, and removes those for
which importing fails.

----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2001-05-21 13:48

Message:
Logged In: YES 
user_id=11375

Accepted and checked in; thanks!


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=411055&group_id=5470


From noreply@sourceforge.net  Mon May 21 22:01:51 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 21 May 2001 14:01:51 -0700
Subject: [Patches] [ python-Patches-425242 ] Patch which "inlines" small dictionaries
Message-ID: <E151woJ-0001nF-00@usw-sf-web3.sourceforge.net>

Patches item #425242, was updated on 2001-05-18 10:15
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=425242&group_id=5470

Category: core (C code)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: M.-A. Lemburg (lemburg)
Assigned to: Jeremy Hylton (jhylton)
>Summary: Patch which "inlines" small dictionaries

Initial Comment:
As discussed on python-dev, this patch inlines small
dictionary tables directly in the dictionary object.

----------------------------------------------------------------------

>Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-21 14:01

Message:
Logged In: YES 
user_id=38388

I was a bit surprised at my timings, since I would have
expected a speedup too (I did get a speedup for Python 1.5
back in the old days). I think this has to do with CPU
caches and branch prediction.

In any case, a new machine is in the making :-) This old box
just aint no fun any more...


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-21 13:38

Message:
Logged In: YES 
user_id=31435

On my WinTel Win2K box at work, current CVS is ~12350 
pystone w/o my patch and ~12500 with it.  Jeremy's timings 
on his Linux+gcc box show small but reproducible 
improvements on some other "realer" programs.  I'm not 
surprised if it actually slows things on *some* platforms, 
because that's the nature of low-level optimization work.  
But the changes simplify the code on frequent paths, 
reducing the start-to-finish operation counts, and over 
time that's the only thing that reliably improves x-
platform performance.

BTW, the pystone results suggest you could get a factor of 
6 improvement in an hour by buying a midrange new machine 
<wink>.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-21 06:53

Message:
Logged In: YES 
user_id=38388

I've tested both patches against the unpatched CVS version
with pystone. The results are surprising: CVS benchmarks at
2300 pystones while your patch runs at 2200 pystones and my
patch at 2100 pystones.

I think we need to put some more thought into this...

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-21 02:07

Message:
Logged In: YES 
user_id=31435

There's more explanation about how to bump MINSIZE in the 
patch than in current dictobject.c.  Read the new 
comments!  You have to choose a power of 2 and fiddle the 
polys[] vector to match.  That's all.

The code defines a ma_smalltable member just as yours did.  
The rest is details.  Primarily it's more aggressive about 
exploiting the new member, because I found it was more 
efficient to avoid undue work in the empty case by looping 
on the ma_fill count rather than by continuing to 
constantly fiddle around with NULL-pointer checks all over 
dictobject.c (they've been replaced by asserts).  It does 
pay for a memset() of the ma_smalltable member during 
creation, though.

It would be interesting to try both patches, but I spent 
too much time on this already to debug your patch too.  It 
would be good if you could upload a new version of your 
patch.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-21 01:25

Message:
Logged In: YES 
user_id=38388

Hmm, timdict2.patch seems to be a completly different
solution. What I am missing in that patch is the ability to
tune the implementation... what happens if I want to bump
MINSIZE to some higher value ? I think the patch should at
least include an explanation of how this can be done.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-20 15:31

Message:
Logged In: YES 
user_id=31435

Just deleted my first patch.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-20 15:30

Message:
Logged In: YES 
user_id=31435

timdict2.patch is more aggressive about iterating until 
we've seen fill non-virgin entries go by rather than the 
table size.  This is never slower but is sometimes a 
surprising win!  For example, dicts keyed by a contiguous 
range of small integers tend to fill a solid initial 
segment of the dict.  When resizing or copying, after the 
patch it's common for the loop to get out, e.g., after ~170 
iterations instead of (the current, and always) 256.

Also added some desperately needed comments about what the 
GF(2^n-{0}) business means in pragmatic terms; + a few 
assorted cleanups.

I think this is ready for prime time, but do have concerns 
about the increased memory use (embedding an 8-slot table 
in every dict object means every dict bites another 8*3*4 
== 96 bytes on a 32-bit box; OTOH, dicts with up to and 
including 5 entries never need more space than that, and 
dicts with 3, 4 or 5 entries were actually larger before 
due to the malloc overhead tagging along with their 
dynamically allocated 8-slot table).

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-19 20:40

Message:
Logged In: YES 
user_id=31435

Assigned to Jeremy since he's been timing stuff lately 
too:  care to give it a try?

timdict.patch is in some ways more aggressive than MAL's 
patch, taking advantage of that we always have *some* 
memory to point to now, thus allowing to get rid of a bunch 
of table==NULL? tests and associated gotos and labels.

The newer patch passes all the tests I've thrown at it, in 
debug and release builds.  It was a major bitch to get 
working correctly, due to an excruciating interaction among 
PyDict_Clear() and garbage collection and module 
finalization and the special treatment of __builtins__ (who 
would have guessed that allocating a tuple could cause a 
module to finalize!?).

I never figured out why MAL's patch died, and after 
spending 10 hours figuring out why mine did, don't intend 
to waste the rest of the weekend trying <wink>.


----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-18 10:21

Message:
Logged In: YES 
user_id=38388

This is just a quick update of the original patch which I
prepared for Python 1.5 some years ago. Since the dictionary
implementation has evolved somewhat since then, I'm not sure
whether it still works as robust as it does for Python 1.5
(I've been using this for years without any problem).

Running the test suite, their appears to be a hanger due to
some endless loop which occurrs for test_popen2. I'm not
sure where Python hangs, but it could well be that the
resize routines have to adapted a little for the current
dict implementation.



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=425242&group_id=5470


From noreply@sourceforge.net  Mon May 21 22:11:36 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 21 May 2001 14:11:36 -0700
Subject: [Patches] [ python-Patches-401842 ] Localization of calendar module.
Message-ID: <E151wxk-0001wm-00@usw-sf-web3.sourceforge.net>

Patches item #401842, was updated on 2000-10-09 01:23
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=401842&group_id=5470

Category: library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Denis S. Otkidach (ods)
>Assigned to: Martin v. Löwis (loewis)
Summary: Localization of calendar module.

Initial Comment:
 

----------------------------------------------------------------------

>Comment By: Barry Warsaw (bwarsaw)
Date: 2001-05-21 14:11

Message:
Logged In: YES 
user_id=12800

Sorry for leaving this patch unreviewed for so long.

Attached is a slightly different approach which retains the
property that day_name, day_abbr, month_name, and month_abbr
are actually list objects of the same size as before the
patch.  I don't know if this is a property worth keeping,
since those variables aren't described in the library manual
(but OTOH aren't prefixed with and underscore to
deliberately mark them as private to the module).

The only testing I've done is to make sure that that stuff
is the same on my `en' Linux box.  I haven't got any way to
test them for other locales, and there's no test suite for
the calendar module.

I'm assigning to Martin for his opinion.  Martin, if it
looks okay to you, reassign to me and I'll commit the
changes.  Thanks.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-10-09 05:46

Message:
This seems a little too much code while we're in a feature freeze. Let's do this after 2.0final is released.

----------------------------------------------------------------------

Comment By: Denis S. Otkidach (ods)
Date: 2000-10-09 01:34

Message:
This work fine for all locales on NT, but may work a bit strange with some locales (e.g. ru_RU) on some platforms with buggy (IMHO) L10n of strftime (e.g. RedHat Linux).

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=401842&group_id=5470


From noreply@sourceforge.net  Mon May 21 22:29:49 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 21 May 2001 14:29:49 -0700
Subject: [Patches] [ python-Patches-426072 ] special case "O" in PyArg_ParseTuple()
Message-ID: <E151xFN-00045k-00@usw-sf-web2.sourceforge.net>

Patches item #426072, was updated on 2001-05-21 14:29
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=426072&group_id=5470

Category: core (C code)
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Jeremy Hylton (jhylton)
Assigned to: Tim Peters (tim_one)
Summary: special case "O" in PyArg_ParseTuple()

Initial Comment:
The most common argument passed to PyArg_ParseTuple() 
is one or more Os. Special-case Os to make this go a
bit faster.

Also eliminate the convertsimple(), convertsimple1()
two-step, since it's adding an extra function call to
all cases to handle the error cases.  Instead, call the
extra function only when an error occurs.

Note that the indentation in this patch is a bit messy.

The speedup is modest.  On the parsetuple-intensive
benchmarks like pybench's BuiltinFunctionCalls, this
patch reduces the cost of PyArg_ParseTuple() by almost
40%.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=426072&group_id=5470


From noreply@sourceforge.net  Tue May 22 06:29:37 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 21 May 2001 22:29:37 -0700
Subject: [Patches] [ python-Patches-425242 ] Patch which "inlines" small dictionaries
Message-ID: <E1524jh-0008H7-00@usw-sf-web3.sourceforge.net>

Patches item #425242, was updated on 2001-05-18 10:15
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=425242&group_id=5470

Category: core (C code)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: M.-A. Lemburg (lemburg)
Assigned to: Jeremy Hylton (jhylton)
>Summary: Patch which "inlines" small dictionaries

Initial Comment:
As discussed on python-dev, this patch inlines small
dictionary tables directly in the dictionary object.

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-05-21 22:29

Message:
Logged In: YES 
user_id=31435

I don't know, but I'd guess you're also using different 
releases of compilers, libraries and an OS since you first 
did this under 1.5.  Any of those could account for it too 
(e.g., in my Win9x days I traced many timing surprises to 
bizarre system malloc() behavior); the Python codebase is 
simply larger now too, thanks to mounds of useless new 
stuff like Unicode <wink>.

BTW, bump the priority on getting that new box:  I finally 
did that myself earlier this year, and it's still a joy 
that *everything* runs 5x faster.  My old machine wasn't 
quite quick enough to run Tomb Raider in high resolution, 
but now I can do that and test Python at the same time.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-21 14:01

Message:
Logged In: YES 
user_id=38388

I was a bit surprised at my timings, since I would have
expected a speedup too (I did get a speedup for Python 1.5
back in the old days). I think this has to do with CPU
caches and branch prediction.

In any case, a new machine is in the making :-) This old box
just aint no fun any more...


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-21 13:38

Message:
Logged In: YES 
user_id=31435

On my WinTel Win2K box at work, current CVS is ~12350 
pystone w/o my patch and ~12500 with it.  Jeremy's timings 
on his Linux+gcc box show small but reproducible 
improvements on some other "realer" programs.  I'm not 
surprised if it actually slows things on *some* platforms, 
because that's the nature of low-level optimization work.  
But the changes simplify the code on frequent paths, 
reducing the start-to-finish operation counts, and over 
time that's the only thing that reliably improves x-
platform performance.

BTW, the pystone results suggest you could get a factor of 
6 improvement in an hour by buying a midrange new machine 
<wink>.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-21 06:53

Message:
Logged In: YES 
user_id=38388

I've tested both patches against the unpatched CVS version
with pystone. The results are surprising: CVS benchmarks at
2300 pystones while your patch runs at 2200 pystones and my
patch at 2100 pystones.

I think we need to put some more thought into this...

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-21 02:07

Message:
Logged In: YES 
user_id=31435

There's more explanation about how to bump MINSIZE in the 
patch than in current dictobject.c.  Read the new 
comments!  You have to choose a power of 2 and fiddle the 
polys[] vector to match.  That's all.

The code defines a ma_smalltable member just as yours did.  
The rest is details.  Primarily it's more aggressive about 
exploiting the new member, because I found it was more 
efficient to avoid undue work in the empty case by looping 
on the ma_fill count rather than by continuing to 
constantly fiddle around with NULL-pointer checks all over 
dictobject.c (they've been replaced by asserts).  It does 
pay for a memset() of the ma_smalltable member during 
creation, though.

It would be interesting to try both patches, but I spent 
too much time on this already to debug your patch too.  It 
would be good if you could upload a new version of your 
patch.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-21 01:25

Message:
Logged In: YES 
user_id=38388

Hmm, timdict2.patch seems to be a completly different
solution. What I am missing in that patch is the ability to
tune the implementation... what happens if I want to bump
MINSIZE to some higher value ? I think the patch should at
least include an explanation of how this can be done.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-20 15:31

Message:
Logged In: YES 
user_id=31435

Just deleted my first patch.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-20 15:30

Message:
Logged In: YES 
user_id=31435

timdict2.patch is more aggressive about iterating until 
we've seen fill non-virgin entries go by rather than the 
table size.  This is never slower but is sometimes a 
surprising win!  For example, dicts keyed by a contiguous 
range of small integers tend to fill a solid initial 
segment of the dict.  When resizing or copying, after the 
patch it's common for the loop to get out, e.g., after ~170 
iterations instead of (the current, and always) 256.

Also added some desperately needed comments about what the 
GF(2^n-{0}) business means in pragmatic terms; + a few 
assorted cleanups.

I think this is ready for prime time, but do have concerns 
about the increased memory use (embedding an 8-slot table 
in every dict object means every dict bites another 8*3*4 
== 96 bytes on a 32-bit box; OTOH, dicts with up to and 
including 5 entries never need more space than that, and 
dicts with 3, 4 or 5 entries were actually larger before 
due to the malloc overhead tagging along with their 
dynamically allocated 8-slot table).

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-19 20:40

Message:
Logged In: YES 
user_id=31435

Assigned to Jeremy since he's been timing stuff lately 
too:  care to give it a try?

timdict.patch is in some ways more aggressive than MAL's 
patch, taking advantage of that we always have *some* 
memory to point to now, thus allowing to get rid of a bunch 
of table==NULL? tests and associated gotos and labels.

The newer patch passes all the tests I've thrown at it, in 
debug and release builds.  It was a major bitch to get 
working correctly, due to an excruciating interaction among 
PyDict_Clear() and garbage collection and module 
finalization and the special treatment of __builtins__ (who 
would have guessed that allocating a tuple could cause a 
module to finalize!?).

I never figured out why MAL's patch died, and after 
spending 10 hours figuring out why mine did, don't intend 
to waste the rest of the weekend trying <wink>.


----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-18 10:21

Message:
Logged In: YES 
user_id=38388

This is just a quick update of the original patch which I
prepared for Python 1.5 some years ago. Since the dictionary
implementation has evolved somewhat since then, I'm not sure
whether it still works as robust as it does for Python 1.5
(I've been using this for years without any problem).

Running the test suite, their appears to be a hanger due to
some endless loop which occurrs for test_popen2. I'm not
sure where Python hangs, but it could well be that the
resize routines have to adapted a little for the current
dict implementation.



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=425242&group_id=5470


From noreply@sourceforge.net  Tue May 22 09:06:21 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 22 May 2001 01:06:21 -0700
Subject: [Patches] [ python-Patches-426208 ] Fun with Floating Point
Message-ID: <E1527BN-00046W-00@usw-sf-web1.sourceforge.net>

Patches item #426208, was updated on 2001-05-22 01:06
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=426208&group_id=5470

Category: documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Fun with Floating Point

Initial Comment:
I suggest this as an Appendix.  For Michel Pelletier's 
benefit, it contains no equation <wink>.  Alas for 
you, for my benefit it contains no LaTeX markup 
either.  Season to taste!


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=426208&group_id=5470


From noreply@sourceforge.net  Tue May 22 09:48:42 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 22 May 2001 01:48:42 -0700
Subject: [Patches] [ python-Patches-401842 ] Localization of calendar module.
Message-ID: <E1527qM-0004mN-00@usw-sf-web1.sourceforge.net>

Patches item #401842, was updated on 2000-10-09 01:23
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=401842&group_id=5470

Category: library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Denis S. Otkidach (ods)
Assigned to: Martin v. Löwis (loewis)
Summary: Localization of calendar module.

Initial Comment:
 

----------------------------------------------------------------------

>Comment By: Denis S. Otkidach (ods)
Date: 2001-05-22 01:48

Message:
Logged In: YES 
user_id=63454

When using real list objects we need to set locale before
*importing* the module. I'm not sure this is a good
solution. Such feature should be properly documented at
least.

----------------------------------------------------------------------

Comment By: Barry Warsaw (bwarsaw)
Date: 2001-05-21 14:11

Message:
Logged In: YES 
user_id=12800

Sorry for leaving this patch unreviewed for so long.

Attached is a slightly different approach which retains the
property that day_name, day_abbr, month_name, and month_abbr
are actually list objects of the same size as before the
patch.  I don't know if this is a property worth keeping,
since those variables aren't described in the library manual
(but OTOH aren't prefixed with and underscore to
deliberately mark them as private to the module).

The only testing I've done is to make sure that that stuff
is the same on my `en' Linux box.  I haven't got any way to
test them for other locales, and there's no test suite for
the calendar module.

I'm assigning to Martin for his opinion.  Martin, if it
looks okay to you, reassign to me and I'll commit the
changes.  Thanks.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-10-09 05:46

Message:
This seems a little too much code while we're in a feature freeze. Let's do this after 2.0final is released.

----------------------------------------------------------------------

Comment By: Denis S. Otkidach (ods)
Date: 2000-10-09 01:34

Message:
This work fine for all locales on NT, but may work a bit strange with some locales (e.g. ru_RU) on some platforms with buggy (IMHO) L10n of strftime (e.g. RedHat Linux).

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=401842&group_id=5470


From noreply@sourceforge.net  Tue May 22 10:28:22 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 22 May 2001 02:28:22 -0700
Subject: [Patches] [ python-Patches-401842 ] Localization of calendar module.
Message-ID: <E1528Sk-0005OZ-00@usw-sf-web1.sourceforge.net>

Patches item #401842, was updated on 2000-10-09 01:23
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=401842&group_id=5470

Category: library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Denis S. Otkidach (ods)
>Assigned to: Barry Warsaw (bwarsaw)
Summary: Localization of calendar module.

Initial Comment:
 

----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2001-05-22 02:28

Message:
Logged In: YES 
user_id=21627

Barry, the problem with your version is that it does nothing
unless locale.setlocale has been called *before the calendar
module is imported*.
To get a version that changes when setlocale is called, you
either need to intercept locale.setlocale and update the
calender constants, or use Denis' approach.
I'm not sure whether it is really required that the
constants stay current even after setlocale calls; if
Barry's patch is used, it should be documented that
setlocale must be called before calendar is imported to make
use of the locale-specific constants.
Re-assigned back to Barry.

----------------------------------------------------------------------

Comment By: Denis S. Otkidach (ods)
Date: 2001-05-22 01:48

Message:
Logged In: YES 
user_id=63454

When using real list objects we need to set locale before
*importing* the module. I'm not sure this is a good
solution. Such feature should be properly documented at
least.

----------------------------------------------------------------------

Comment By: Barry Warsaw (bwarsaw)
Date: 2001-05-21 14:11

Message:
Logged In: YES 
user_id=12800

Sorry for leaving this patch unreviewed for so long.

Attached is a slightly different approach which retains the
property that day_name, day_abbr, month_name, and month_abbr
are actually list objects of the same size as before the
patch.  I don't know if this is a property worth keeping,
since those variables aren't described in the library manual
(but OTOH aren't prefixed with and underscore to
deliberately mark them as private to the module).

The only testing I've done is to make sure that that stuff
is the same on my `en' Linux box.  I haven't got any way to
test them for other locales, and there's no test suite for
the calendar module.

I'm assigning to Martin for his opinion.  Martin, if it
looks okay to you, reassign to me and I'll commit the
changes.  Thanks.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-10-09 05:46

Message:
This seems a little too much code while we're in a feature freeze. Let's do this after 2.0final is released.

----------------------------------------------------------------------

Comment By: Denis S. Otkidach (ods)
Date: 2000-10-09 01:34

Message:
This work fine for all locales on NT, but may work a bit strange with some locales (e.g. ru_RU) on some platforms with buggy (IMHO) L10n of strftime (e.g. RedHat Linux).

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=401842&group_id=5470


From noreply@sourceforge.net  Tue May 22 10:54:12 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 22 May 2001 02:54:12 -0700
Subject: [Patches] [ python-Patches-425242 ] Patch which "inlines" small dictionaries
Message-ID: <E1528rk-00035b-00@usw-sf-web3.sourceforge.net>

Patches item #425242, was updated on 2001-05-18 10:15
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=425242&group_id=5470

Category: core (C code)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: M.-A. Lemburg (lemburg)
Assigned to: Jeremy Hylton (jhylton)
Summary: Patch which "inlines" small dictionaries

Initial Comment:
As discussed on python-dev, this patch inlines small
dictionary tables directly in the dictionary object.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-22 02:54

Message:
Logged In: YES 
user_id=38388

I think I better leave the timing to Jeremy then. It'll be
another week or two before I get the new machine up and
running.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-21 22:29

Message:
Logged In: YES 
user_id=31435

I don't know, but I'd guess you're also using different 
releases of compilers, libraries and an OS since you first 
did this under 1.5.  Any of those could account for it too 
(e.g., in my Win9x days I traced many timing surprises to 
bizarre system malloc() behavior); the Python codebase is 
simply larger now too, thanks to mounds of useless new 
stuff like Unicode <wink>.

BTW, bump the priority on getting that new box:  I finally 
did that myself earlier this year, and it's still a joy 
that *everything* runs 5x faster.  My old machine wasn't 
quite quick enough to run Tomb Raider in high resolution, 
but now I can do that and test Python at the same time.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-21 14:01

Message:
Logged In: YES 
user_id=38388

I was a bit surprised at my timings, since I would have
expected a speedup too (I did get a speedup for Python 1.5
back in the old days). I think this has to do with CPU
caches and branch prediction.

In any case, a new machine is in the making :-) This old box
just aint no fun any more...


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-21 13:38

Message:
Logged In: YES 
user_id=31435

On my WinTel Win2K box at work, current CVS is ~12350 
pystone w/o my patch and ~12500 with it.  Jeremy's timings 
on his Linux+gcc box show small but reproducible 
improvements on some other "realer" programs.  I'm not 
surprised if it actually slows things on *some* platforms, 
because that's the nature of low-level optimization work.  
But the changes simplify the code on frequent paths, 
reducing the start-to-finish operation counts, and over 
time that's the only thing that reliably improves x-
platform performance.

BTW, the pystone results suggest you could get a factor of 
6 improvement in an hour by buying a midrange new machine 
<wink>.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-21 06:53

Message:
Logged In: YES 
user_id=38388

I've tested both patches against the unpatched CVS version
with pystone. The results are surprising: CVS benchmarks at
2300 pystones while your patch runs at 2200 pystones and my
patch at 2100 pystones.

I think we need to put some more thought into this...

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-21 02:07

Message:
Logged In: YES 
user_id=31435

There's more explanation about how to bump MINSIZE in the 
patch than in current dictobject.c.  Read the new 
comments!  You have to choose a power of 2 and fiddle the 
polys[] vector to match.  That's all.

The code defines a ma_smalltable member just as yours did.  
The rest is details.  Primarily it's more aggressive about 
exploiting the new member, because I found it was more 
efficient to avoid undue work in the empty case by looping 
on the ma_fill count rather than by continuing to 
constantly fiddle around with NULL-pointer checks all over 
dictobject.c (they've been replaced by asserts).  It does 
pay for a memset() of the ma_smalltable member during 
creation, though.

It would be interesting to try both patches, but I spent 
too much time on this already to debug your patch too.  It 
would be good if you could upload a new version of your 
patch.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-21 01:25

Message:
Logged In: YES 
user_id=38388

Hmm, timdict2.patch seems to be a completly different
solution. What I am missing in that patch is the ability to
tune the implementation... what happens if I want to bump
MINSIZE to some higher value ? I think the patch should at
least include an explanation of how this can be done.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-20 15:31

Message:
Logged In: YES 
user_id=31435

Just deleted my first patch.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-20 15:30

Message:
Logged In: YES 
user_id=31435

timdict2.patch is more aggressive about iterating until 
we've seen fill non-virgin entries go by rather than the 
table size.  This is never slower but is sometimes a 
surprising win!  For example, dicts keyed by a contiguous 
range of small integers tend to fill a solid initial 
segment of the dict.  When resizing or copying, after the 
patch it's common for the loop to get out, e.g., after ~170 
iterations instead of (the current, and always) 256.

Also added some desperately needed comments about what the 
GF(2^n-{0}) business means in pragmatic terms; + a few 
assorted cleanups.

I think this is ready for prime time, but do have concerns 
about the increased memory use (embedding an 8-slot table 
in every dict object means every dict bites another 8*3*4 
== 96 bytes on a 32-bit box; OTOH, dicts with up to and 
including 5 entries never need more space than that, and 
dicts with 3, 4 or 5 entries were actually larger before 
due to the malloc overhead tagging along with their 
dynamically allocated 8-slot table).

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-19 20:40

Message:
Logged In: YES 
user_id=31435

Assigned to Jeremy since he's been timing stuff lately 
too:  care to give it a try?

timdict.patch is in some ways more aggressive than MAL's 
patch, taking advantage of that we always have *some* 
memory to point to now, thus allowing to get rid of a bunch 
of table==NULL? tests and associated gotos and labels.

The newer patch passes all the tests I've thrown at it, in 
debug and release builds.  It was a major bitch to get 
working correctly, due to an excruciating interaction among 
PyDict_Clear() and garbage collection and module 
finalization and the special treatment of __builtins__ (who 
would have guessed that allocating a tuple could cause a 
module to finalize!?).

I never figured out why MAL's patch died, and after 
spending 10 hours figuring out why mine did, don't intend 
to waste the rest of the weekend trying <wink>.


----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-18 10:21

Message:
Logged In: YES 
user_id=38388

This is just a quick update of the original patch which I
prepared for Python 1.5 some years ago. Since the dictionary
implementation has evolved somewhat since then, I'm not sure
whether it still works as robust as it does for Python 1.5
(I've been using this for years without any problem).

Running the test suite, their appears to be a hanger due to
some endless loop which occurrs for test_popen2. I'm not
sure where Python hangs, but it could well be that the
resize routines have to adapted a little for the current
dict implementation.



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=425242&group_id=5470


From noreply@sourceforge.net  Tue May 22 16:45:26 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 22 May 2001 08:45:26 -0700
Subject: [Patches] [ python-Patches-425242 ] Patch which "inlines" small dictionaries
Message-ID: <E152ELe-0007Sf-00@usw-sf-web2.sourceforge.net>

Patches item #425242, was updated on 2001-05-18 10:15
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=425242&group_id=5470

Category: core (C code)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: M.-A. Lemburg (lemburg)
Assigned to: Jeremy Hylton (jhylton)
>Summary: Patch which "inlines" small dictionaries

Initial Comment:
As discussed on python-dev, this patch inlines small
dictionary tables directly in the dictionary object.

----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2001-05-22 08:45

Message:
Logged In: YES 
user_id=31392

Comparing three different dict impls on the same tests.

CVS -- Python 2.2 CVS repository as of May 21, 2001
TIM -- Tim's dict patches to inline small dicts
MAL -- MAL's dict patches to inline small dicts

Test machine: Jeremy's 800MHz PIII, 256MB RAM, Linux 2.2.17

Compiled with gcc 2.95.3 -O3

Tests:

pystone -- the standard pystone benchmark
mutants -- the test_mutants test from the Python regression
test
compile -- the compiler package compiling itself

Results

Results for macro benchmarks are median of 9 runs.

For the mutants and compile benchmarks, measurement is
combined user
and system time reported by Unix time utility.  For the
pystone
benchmark, result is time reported by pystone.

Result table

test              CVS      TIM      MAL
test_mutant       1.49     1.48     1.53
pystone           0.94     0.91     0.94 
compile          11.7     11.65    11.83

I tried running a few of the pybench tests with gprof
enabled, but
the time the runs took varied wildly -- a range of a few
seconds.



----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-22 02:54

Message:
Logged In: YES 
user_id=38388

I think I better leave the timing to Jeremy then. It'll be
another week or two before I get the new machine up and
running.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-21 22:29

Message:
Logged In: YES 
user_id=31435

I don't know, but I'd guess you're also using different 
releases of compilers, libraries and an OS since you first 
did this under 1.5.  Any of those could account for it too 
(e.g., in my Win9x days I traced many timing surprises to 
bizarre system malloc() behavior); the Python codebase is 
simply larger now too, thanks to mounds of useless new 
stuff like Unicode <wink>.

BTW, bump the priority on getting that new box:  I finally 
did that myself earlier this year, and it's still a joy 
that *everything* runs 5x faster.  My old machine wasn't 
quite quick enough to run Tomb Raider in high resolution, 
but now I can do that and test Python at the same time.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-21 14:01

Message:
Logged In: YES 
user_id=38388

I was a bit surprised at my timings, since I would have
expected a speedup too (I did get a speedup for Python 1.5
back in the old days). I think this has to do with CPU
caches and branch prediction.

In any case, a new machine is in the making :-) This old box
just aint no fun any more...


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-21 13:38

Message:
Logged In: YES 
user_id=31435

On my WinTel Win2K box at work, current CVS is ~12350 
pystone w/o my patch and ~12500 with it.  Jeremy's timings 
on his Linux+gcc box show small but reproducible 
improvements on some other "realer" programs.  I'm not 
surprised if it actually slows things on *some* platforms, 
because that's the nature of low-level optimization work.  
But the changes simplify the code on frequent paths, 
reducing the start-to-finish operation counts, and over 
time that's the only thing that reliably improves x-
platform performance.

BTW, the pystone results suggest you could get a factor of 
6 improvement in an hour by buying a midrange new machine 
<wink>.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-21 06:53

Message:
Logged In: YES 
user_id=38388

I've tested both patches against the unpatched CVS version
with pystone. The results are surprising: CVS benchmarks at
2300 pystones while your patch runs at 2200 pystones and my
patch at 2100 pystones.

I think we need to put some more thought into this...

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-21 02:07

Message:
Logged In: YES 
user_id=31435

There's more explanation about how to bump MINSIZE in the 
patch than in current dictobject.c.  Read the new 
comments!  You have to choose a power of 2 and fiddle the 
polys[] vector to match.  That's all.

The code defines a ma_smalltable member just as yours did.  
The rest is details.  Primarily it's more aggressive about 
exploiting the new member, because I found it was more 
efficient to avoid undue work in the empty case by looping 
on the ma_fill count rather than by continuing to 
constantly fiddle around with NULL-pointer checks all over 
dictobject.c (they've been replaced by asserts).  It does 
pay for a memset() of the ma_smalltable member during 
creation, though.

It would be interesting to try both patches, but I spent 
too much time on this already to debug your patch too.  It 
would be good if you could upload a new version of your 
patch.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-21 01:25

Message:
Logged In: YES 
user_id=38388

Hmm, timdict2.patch seems to be a completly different
solution. What I am missing in that patch is the ability to
tune the implementation... what happens if I want to bump
MINSIZE to some higher value ? I think the patch should at
least include an explanation of how this can be done.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-20 15:31

Message:
Logged In: YES 
user_id=31435

Just deleted my first patch.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-20 15:30

Message:
Logged In: YES 
user_id=31435

timdict2.patch is more aggressive about iterating until 
we've seen fill non-virgin entries go by rather than the 
table size.  This is never slower but is sometimes a 
surprising win!  For example, dicts keyed by a contiguous 
range of small integers tend to fill a solid initial 
segment of the dict.  When resizing or copying, after the 
patch it's common for the loop to get out, e.g., after ~170 
iterations instead of (the current, and always) 256.

Also added some desperately needed comments about what the 
GF(2^n-{0}) business means in pragmatic terms; + a few 
assorted cleanups.

I think this is ready for prime time, but do have concerns 
about the increased memory use (embedding an 8-slot table 
in every dict object means every dict bites another 8*3*4 
== 96 bytes on a 32-bit box; OTOH, dicts with up to and 
including 5 entries never need more space than that, and 
dicts with 3, 4 or 5 entries were actually larger before 
due to the malloc overhead tagging along with their 
dynamically allocated 8-slot table).

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-19 20:40

Message:
Logged In: YES 
user_id=31435

Assigned to Jeremy since he's been timing stuff lately 
too:  care to give it a try?

timdict.patch is in some ways more aggressive than MAL's 
patch, taking advantage of that we always have *some* 
memory to point to now, thus allowing to get rid of a bunch 
of table==NULL? tests and associated gotos and labels.

The newer patch passes all the tests I've thrown at it, in 
debug and release builds.  It was a major bitch to get 
working correctly, due to an excruciating interaction among 
PyDict_Clear() and garbage collection and module 
finalization and the special treatment of __builtins__ (who 
would have guessed that allocating a tuple could cause a 
module to finalize!?).

I never figured out why MAL's patch died, and after 
spending 10 hours figuring out why mine did, don't intend 
to waste the rest of the weekend trying <wink>.


----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-18 10:21

Message:
Logged In: YES 
user_id=38388

This is just a quick update of the original patch which I
prepared for Python 1.5 some years ago. Since the dictionary
implementation has evolved somewhat since then, I'm not sure
whether it still works as robust as it does for Python 1.5
(I've been using this for years without any problem).

Running the test suite, their appears to be a hanger due to
some endless loop which occurrs for test_popen2. I'm not
sure where Python hangs, but it could well be that the
resize routines have to adapted a little for the current
dict implementation.



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=425242&group_id=5470


From noreply@sourceforge.net  Tue May 22 16:51:33 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 22 May 2001 08:51:33 -0700
Subject: [Patches] [ python-Patches-401842 ] Localization of calendar module.
Message-ID: <E152ERZ-0007X8-00@usw-sf-web2.sourceforge.net>

Patches item #401842, was updated on 2000-10-09 01:23
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=401842&group_id=5470

Category: library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Denis S. Otkidach (ods)
Assigned to: Barry Warsaw (bwarsaw)
Summary: Localization of calendar module.

Initial Comment:
 

----------------------------------------------------------------------

>Comment By: Barry Warsaw (bwarsaw)
Date: 2001-05-22 08:51

Message:
Logged In: YES 
user_id=12800

Very good point.  It seems to me the convenience of calendar
tracking changes to the locale outweighs the need to keep
the same concrete type for these undocumented variables. 
I'll apply the original patch.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2001-05-22 02:28

Message:
Logged In: YES 
user_id=21627

Barry, the problem with your version is that it does nothing
unless locale.setlocale has been called *before the calendar
module is imported*.
To get a version that changes when setlocale is called, you
either need to intercept locale.setlocale and update the
calender constants, or use Denis' approach.
I'm not sure whether it is really required that the
constants stay current even after setlocale calls; if
Barry's patch is used, it should be documented that
setlocale must be called before calendar is imported to make
use of the locale-specific constants.
Re-assigned back to Barry.

----------------------------------------------------------------------

Comment By: Denis S. Otkidach (ods)
Date: 2001-05-22 01:48

Message:
Logged In: YES 
user_id=63454

When using real list objects we need to set locale before
*importing* the module. I'm not sure this is a good
solution. Such feature should be properly documented at
least.

----------------------------------------------------------------------

Comment By: Barry Warsaw (bwarsaw)
Date: 2001-05-21 14:11

Message:
Logged In: YES 
user_id=12800

Sorry for leaving this patch unreviewed for so long.

Attached is a slightly different approach which retains the
property that day_name, day_abbr, month_name, and month_abbr
are actually list objects of the same size as before the
patch.  I don't know if this is a property worth keeping,
since those variables aren't described in the library manual
(but OTOH aren't prefixed with and underscore to
deliberately mark them as private to the module).

The only testing I've done is to make sure that that stuff
is the same on my `en' Linux box.  I haven't got any way to
test them for other locales, and there's no test suite for
the calendar module.

I'm assigning to Martin for his opinion.  Martin, if it
looks okay to you, reassign to me and I'll commit the
changes.  Thanks.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-10-09 05:46

Message:
This seems a little too much code while we're in a feature freeze. Let's do this after 2.0final is released.

----------------------------------------------------------------------

Comment By: Denis S. Otkidach (ods)
Date: 2000-10-09 01:34

Message:
This work fine for all locales on NT, but may work a bit strange with some locales (e.g. ru_RU) on some platforms with buggy (IMHO) L10n of strftime (e.g. RedHat Linux).

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=401842&group_id=5470


From noreply@sourceforge.net  Tue May 22 16:58:52 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 22 May 2001 08:58:52 -0700
Subject: [Patches] [ python-Patches-401842 ] Localization of calendar module.
Message-ID: <E152EYe-00081X-00@usw-sf-web3.sourceforge.net>

Patches item #401842, was updated on 2000-10-09 01:23
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=401842&group_id=5470

Category: library
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Denis S. Otkidach (ods)
Assigned to: Barry Warsaw (bwarsaw)
Summary: Localization of calendar module.

Initial Comment:
 

----------------------------------------------------------------------

>Comment By: Barry Warsaw (bwarsaw)
Date: 2001-05-22 08:58

Message:
Logged In: YES 
user_id=12800

Applied to calendar.py 1.22

----------------------------------------------------------------------

Comment By: Barry Warsaw (bwarsaw)
Date: 2001-05-22 08:51

Message:
Logged In: YES 
user_id=12800

Very good point.  It seems to me the convenience of calendar
tracking changes to the locale outweighs the need to keep
the same concrete type for these undocumented variables. 
I'll apply the original patch.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2001-05-22 02:28

Message:
Logged In: YES 
user_id=21627

Barry, the problem with your version is that it does nothing
unless locale.setlocale has been called *before the calendar
module is imported*.
To get a version that changes when setlocale is called, you
either need to intercept locale.setlocale and update the
calender constants, or use Denis' approach.
I'm not sure whether it is really required that the
constants stay current even after setlocale calls; if
Barry's patch is used, it should be documented that
setlocale must be called before calendar is imported to make
use of the locale-specific constants.
Re-assigned back to Barry.

----------------------------------------------------------------------

Comment By: Denis S. Otkidach (ods)
Date: 2001-05-22 01:48

Message:
Logged In: YES 
user_id=63454

When using real list objects we need to set locale before
*importing* the module. I'm not sure this is a good
solution. Such feature should be properly documented at
least.

----------------------------------------------------------------------

Comment By: Barry Warsaw (bwarsaw)
Date: 2001-05-21 14:11

Message:
Logged In: YES 
user_id=12800

Sorry for leaving this patch unreviewed for so long.

Attached is a slightly different approach which retains the
property that day_name, day_abbr, month_name, and month_abbr
are actually list objects of the same size as before the
patch.  I don't know if this is a property worth keeping,
since those variables aren't described in the library manual
(but OTOH aren't prefixed with and underscore to
deliberately mark them as private to the module).

The only testing I've done is to make sure that that stuff
is the same on my `en' Linux box.  I haven't got any way to
test them for other locales, and there's no test suite for
the calendar module.

I'm assigning to Martin for his opinion.  Martin, if it
looks okay to you, reassign to me and I'll commit the
changes.  Thanks.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-10-09 05:46

Message:
This seems a little too much code while we're in a feature freeze. Let's do this after 2.0final is released.

----------------------------------------------------------------------

Comment By: Denis S. Otkidach (ods)
Date: 2000-10-09 01:34

Message:
This work fine for all locales on NT, but may work a bit strange with some locales (e.g. ru_RU) on some platforms with buggy (IMHO) L10n of strftime (e.g. RedHat Linux).

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=401842&group_id=5470


From noreply@sourceforge.net  Tue May 22 18:15:38 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 22 May 2001 10:15:38 -0700
Subject: [Patches] [ python-Patches-425242 ] Patch which "inlines" small dictionaries
Message-ID: <E152Fkw-0008Uz-00@usw-sf-web2.sourceforge.net>

Patches item #425242, was updated on 2001-05-18 10:15
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=425242&group_id=5470

Category: core (C code)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: M.-A. Lemburg (lemburg)
Assigned to: Jeremy Hylton (jhylton)
>Summary: Patch which "inlines" small dictionaries

Initial Comment:
As discussed on python-dev, this patch inlines small
dictionary tables directly in the dictionary object.

----------------------------------------------------------------------

>Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-22 10:15

Message:
Logged In: YES 
user_id=38388

Jeremy, I think you ought to test the patches against
benchmarks which actually make extensive use of dictionaries
(test_mutant only uses 2-3 dictionaries).

pybench's Instances.py looks like a good start....

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2001-05-22 08:45

Message:
Logged In: YES 
user_id=31392

Comparing three different dict impls on the same tests.

CVS -- Python 2.2 CVS repository as of May 21, 2001
TIM -- Tim's dict patches to inline small dicts
MAL -- MAL's dict patches to inline small dicts

Test machine: Jeremy's 800MHz PIII, 256MB RAM, Linux 2.2.17

Compiled with gcc 2.95.3 -O3

Tests:

pystone -- the standard pystone benchmark
mutants -- the test_mutants test from the Python regression
test
compile -- the compiler package compiling itself

Results

Results for macro benchmarks are median of 9 runs.

For the mutants and compile benchmarks, measurement is
combined user
and system time reported by Unix time utility.  For the
pystone
benchmark, result is time reported by pystone.

Result table

test              CVS      TIM      MAL
test_mutant       1.49     1.48     1.53
pystone           0.94     0.91     0.94 
compile          11.7     11.65    11.83

I tried running a few of the pybench tests with gprof
enabled, but
the time the runs took varied wildly -- a range of a few
seconds.



----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-22 02:54

Message:
Logged In: YES 
user_id=38388

I think I better leave the timing to Jeremy then. It'll be
another week or two before I get the new machine up and
running.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-21 22:29

Message:
Logged In: YES 
user_id=31435

I don't know, but I'd guess you're also using different 
releases of compilers, libraries and an OS since you first 
did this under 1.5.  Any of those could account for it too 
(e.g., in my Win9x days I traced many timing surprises to 
bizarre system malloc() behavior); the Python codebase is 
simply larger now too, thanks to mounds of useless new 
stuff like Unicode <wink>.

BTW, bump the priority on getting that new box:  I finally 
did that myself earlier this year, and it's still a joy 
that *everything* runs 5x faster.  My old machine wasn't 
quite quick enough to run Tomb Raider in high resolution, 
but now I can do that and test Python at the same time.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-21 14:01

Message:
Logged In: YES 
user_id=38388

I was a bit surprised at my timings, since I would have
expected a speedup too (I did get a speedup for Python 1.5
back in the old days). I think this has to do with CPU
caches and branch prediction.

In any case, a new machine is in the making :-) This old box
just aint no fun any more...


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-21 13:38

Message:
Logged In: YES 
user_id=31435

On my WinTel Win2K box at work, current CVS is ~12350 
pystone w/o my patch and ~12500 with it.  Jeremy's timings 
on his Linux+gcc box show small but reproducible 
improvements on some other "realer" programs.  I'm not 
surprised if it actually slows things on *some* platforms, 
because that's the nature of low-level optimization work.  
But the changes simplify the code on frequent paths, 
reducing the start-to-finish operation counts, and over 
time that's the only thing that reliably improves x-
platform performance.

BTW, the pystone results suggest you could get a factor of 
6 improvement in an hour by buying a midrange new machine 
<wink>.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-21 06:53

Message:
Logged In: YES 
user_id=38388

I've tested both patches against the unpatched CVS version
with pystone. The results are surprising: CVS benchmarks at
2300 pystones while your patch runs at 2200 pystones and my
patch at 2100 pystones.

I think we need to put some more thought into this...

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-21 02:07

Message:
Logged In: YES 
user_id=31435

There's more explanation about how to bump MINSIZE in the 
patch than in current dictobject.c.  Read the new 
comments!  You have to choose a power of 2 and fiddle the 
polys[] vector to match.  That's all.

The code defines a ma_smalltable member just as yours did.  
The rest is details.  Primarily it's more aggressive about 
exploiting the new member, because I found it was more 
efficient to avoid undue work in the empty case by looping 
on the ma_fill count rather than by continuing to 
constantly fiddle around with NULL-pointer checks all over 
dictobject.c (they've been replaced by asserts).  It does 
pay for a memset() of the ma_smalltable member during 
creation, though.

It would be interesting to try both patches, but I spent 
too much time on this already to debug your patch too.  It 
would be good if you could upload a new version of your 
patch.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-21 01:25

Message:
Logged In: YES 
user_id=38388

Hmm, timdict2.patch seems to be a completly different
solution. What I am missing in that patch is the ability to
tune the implementation... what happens if I want to bump
MINSIZE to some higher value ? I think the patch should at
least include an explanation of how this can be done.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-20 15:31

Message:
Logged In: YES 
user_id=31435

Just deleted my first patch.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-20 15:30

Message:
Logged In: YES 
user_id=31435

timdict2.patch is more aggressive about iterating until 
we've seen fill non-virgin entries go by rather than the 
table size.  This is never slower but is sometimes a 
surprising win!  For example, dicts keyed by a contiguous 
range of small integers tend to fill a solid initial 
segment of the dict.  When resizing or copying, after the 
patch it's common for the loop to get out, e.g., after ~170 
iterations instead of (the current, and always) 256.

Also added some desperately needed comments about what the 
GF(2^n-{0}) business means in pragmatic terms; + a few 
assorted cleanups.

I think this is ready for prime time, but do have concerns 
about the increased memory use (embedding an 8-slot table 
in every dict object means every dict bites another 8*3*4 
== 96 bytes on a 32-bit box; OTOH, dicts with up to and 
including 5 entries never need more space than that, and 
dicts with 3, 4 or 5 entries were actually larger before 
due to the malloc overhead tagging along with their 
dynamically allocated 8-slot table).

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-19 20:40

Message:
Logged In: YES 
user_id=31435

Assigned to Jeremy since he's been timing stuff lately 
too:  care to give it a try?

timdict.patch is in some ways more aggressive than MAL's 
patch, taking advantage of that we always have *some* 
memory to point to now, thus allowing to get rid of a bunch 
of table==NULL? tests and associated gotos and labels.

The newer patch passes all the tests I've thrown at it, in 
debug and release builds.  It was a major bitch to get 
working correctly, due to an excruciating interaction among 
PyDict_Clear() and garbage collection and module 
finalization and the special treatment of __builtins__ (who 
would have guessed that allocating a tuple could cause a 
module to finalize!?).

I never figured out why MAL's patch died, and after 
spending 10 hours figuring out why mine did, don't intend 
to waste the rest of the weekend trying <wink>.


----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-18 10:21

Message:
Logged In: YES 
user_id=38388

This is just a quick update of the original patch which I
prepared for Python 1.5 some years ago. Since the dictionary
implementation has evolved somewhat since then, I'm not sure
whether it still works as robust as it does for Python 1.5
(I've been using this for years without any problem).

Running the test suite, their appears to be a hanger due to
some endless loop which occurrs for test_popen2. I'm not
sure where Python hangs, but it could well be that the
resize routines have to adapted a little for the current
dict implementation.



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=425242&group_id=5470


From noreply@sourceforge.net  Tue May 22 20:03:40 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 22 May 2001 12:03:40 -0700
Subject: [Patches] [ python-Patches-425242 ] Patch which "inlines" small dictionaries
Message-ID: <E152HRU-0001N3-00@usw-sf-web2.sourceforge.net>

Patches item #425242, was updated on 2001-05-18 10:15
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=425242&group_id=5470

Category: core (C code)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: M.-A. Lemburg (lemburg)
Assigned to: Jeremy Hylton (jhylton)
>Summary: Patch which "inlines" small dictionaries

Initial Comment:
As discussed on python-dev, this patch inlines small
dictionary tables directly in the dictionary object.

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-05-22 12:03

Message:
Logged In: YES 
user_id=31435

You're suffering an off-by-10000x error <wink>:  
test_mutants as-is actually creates 100 pairs of dicts (so 
that's 200 dicts) of average size 50, and fills the keys 
and values of each with instances of class Horrid (so 
that's about 20,000 additional instance dicts).

If Jeremy is still keen to time things (I kinda doubt it:  
we're not seeing any surprises), I'd much rather time real 
programs now -- in real life dicts aren't just created and 
destroyed, they're also accessed, and the small-but-real 
getitem/setitem critical-path reductions are aimed at the 
latter.


----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-22 10:15

Message:
Logged In: YES 
user_id=38388

Jeremy, I think you ought to test the patches against
benchmarks which actually make extensive use of dictionaries
(test_mutant only uses 2-3 dictionaries).

pybench's Instances.py looks like a good start....

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2001-05-22 08:45

Message:
Logged In: YES 
user_id=31392

Comparing three different dict impls on the same tests.

CVS -- Python 2.2 CVS repository as of May 21, 2001
TIM -- Tim's dict patches to inline small dicts
MAL -- MAL's dict patches to inline small dicts

Test machine: Jeremy's 800MHz PIII, 256MB RAM, Linux 2.2.17

Compiled with gcc 2.95.3 -O3

Tests:

pystone -- the standard pystone benchmark
mutants -- the test_mutants test from the Python regression
test
compile -- the compiler package compiling itself

Results

Results for macro benchmarks are median of 9 runs.

For the mutants and compile benchmarks, measurement is
combined user
and system time reported by Unix time utility.  For the
pystone
benchmark, result is time reported by pystone.

Result table

test              CVS      TIM      MAL
test_mutant       1.49     1.48     1.53
pystone           0.94     0.91     0.94 
compile          11.7     11.65    11.83

I tried running a few of the pybench tests with gprof
enabled, but
the time the runs took varied wildly -- a range of a few
seconds.



----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-22 02:54

Message:
Logged In: YES 
user_id=38388

I think I better leave the timing to Jeremy then. It'll be
another week or two before I get the new machine up and
running.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-21 22:29

Message:
Logged In: YES 
user_id=31435

I don't know, but I'd guess you're also using different 
releases of compilers, libraries and an OS since you first 
did this under 1.5.  Any of those could account for it too 
(e.g., in my Win9x days I traced many timing surprises to 
bizarre system malloc() behavior); the Python codebase is 
simply larger now too, thanks to mounds of useless new 
stuff like Unicode <wink>.

BTW, bump the priority on getting that new box:  I finally 
did that myself earlier this year, and it's still a joy 
that *everything* runs 5x faster.  My old machine wasn't 
quite quick enough to run Tomb Raider in high resolution, 
but now I can do that and test Python at the same time.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-21 14:01

Message:
Logged In: YES 
user_id=38388

I was a bit surprised at my timings, since I would have
expected a speedup too (I did get a speedup for Python 1.5
back in the old days). I think this has to do with CPU
caches and branch prediction.

In any case, a new machine is in the making :-) This old box
just aint no fun any more...


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-21 13:38

Message:
Logged In: YES 
user_id=31435

On my WinTel Win2K box at work, current CVS is ~12350 
pystone w/o my patch and ~12500 with it.  Jeremy's timings 
on his Linux+gcc box show small but reproducible 
improvements on some other "realer" programs.  I'm not 
surprised if it actually slows things on *some* platforms, 
because that's the nature of low-level optimization work.  
But the changes simplify the code on frequent paths, 
reducing the start-to-finish operation counts, and over 
time that's the only thing that reliably improves x-
platform performance.

BTW, the pystone results suggest you could get a factor of 
6 improvement in an hour by buying a midrange new machine 
<wink>.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-21 06:53

Message:
Logged In: YES 
user_id=38388

I've tested both patches against the unpatched CVS version
with pystone. The results are surprising: CVS benchmarks at
2300 pystones while your patch runs at 2200 pystones and my
patch at 2100 pystones.

I think we need to put some more thought into this...

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-21 02:07

Message:
Logged In: YES 
user_id=31435

There's more explanation about how to bump MINSIZE in the 
patch than in current dictobject.c.  Read the new 
comments!  You have to choose a power of 2 and fiddle the 
polys[] vector to match.  That's all.

The code defines a ma_smalltable member just as yours did.  
The rest is details.  Primarily it's more aggressive about 
exploiting the new member, because I found it was more 
efficient to avoid undue work in the empty case by looping 
on the ma_fill count rather than by continuing to 
constantly fiddle around with NULL-pointer checks all over 
dictobject.c (they've been replaced by asserts).  It does 
pay for a memset() of the ma_smalltable member during 
creation, though.

It would be interesting to try both patches, but I spent 
too much time on this already to debug your patch too.  It 
would be good if you could upload a new version of your 
patch.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-21 01:25

Message:
Logged In: YES 
user_id=38388

Hmm, timdict2.patch seems to be a completly different
solution. What I am missing in that patch is the ability to
tune the implementation... what happens if I want to bump
MINSIZE to some higher value ? I think the patch should at
least include an explanation of how this can be done.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-20 15:31

Message:
Logged In: YES 
user_id=31435

Just deleted my first patch.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-20 15:30

Message:
Logged In: YES 
user_id=31435

timdict2.patch is more aggressive about iterating until 
we've seen fill non-virgin entries go by rather than the 
table size.  This is never slower but is sometimes a 
surprising win!  For example, dicts keyed by a contiguous 
range of small integers tend to fill a solid initial 
segment of the dict.  When resizing or copying, after the 
patch it's common for the loop to get out, e.g., after ~170 
iterations instead of (the current, and always) 256.

Also added some desperately needed comments about what the 
GF(2^n-{0}) business means in pragmatic terms; + a few 
assorted cleanups.

I think this is ready for prime time, but do have concerns 
about the increased memory use (embedding an 8-slot table 
in every dict object means every dict bites another 8*3*4 
== 96 bytes on a 32-bit box; OTOH, dicts with up to and 
including 5 entries never need more space than that, and 
dicts with 3, 4 or 5 entries were actually larger before 
due to the malloc overhead tagging along with their 
dynamically allocated 8-slot table).

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-19 20:40

Message:
Logged In: YES 
user_id=31435

Assigned to Jeremy since he's been timing stuff lately 
too:  care to give it a try?

timdict.patch is in some ways more aggressive than MAL's 
patch, taking advantage of that we always have *some* 
memory to point to now, thus allowing to get rid of a bunch 
of table==NULL? tests and associated gotos and labels.

The newer patch passes all the tests I've thrown at it, in 
debug and release builds.  It was a major bitch to get 
working correctly, due to an excruciating interaction among 
PyDict_Clear() and garbage collection and module 
finalization and the special treatment of __builtins__ (who 
would have guessed that allocating a tuple could cause a 
module to finalize!?).

I never figured out why MAL's patch died, and after 
spending 10 hours figuring out why mine did, don't intend 
to waste the rest of the weekend trying <wink>.


----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-18 10:21

Message:
Logged In: YES 
user_id=38388

This is just a quick update of the original patch which I
prepared for Python 1.5 some years ago. Since the dictionary
implementation has evolved somewhat since then, I'm not sure
whether it still works as robust as it does for Python 1.5
(I've been using this for years without any problem).

Running the test suite, their appears to be a hanger due to
some endless loop which occurrs for test_popen2. I'm not
sure where Python hangs, but it could well be that the
resize routines have to adapted a little for the current
dict implementation.



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=425242&group_id=5470


From noreply@sourceforge.net  Tue May 22 20:15:27 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 22 May 2001 12:15:27 -0700
Subject: [Patches] [ python-Patches-425242 ] Patch which "inlines" small dictionaries
Message-ID: <E152Hct-0001WR-00@usw-sf-web2.sourceforge.net>

Patches item #425242, was updated on 2001-05-18 10:15
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=425242&group_id=5470

Category: core (C code)
Group: None
Status: Open
>Resolution: Accepted
Priority: 5
Submitted By: M.-A. Lemburg (lemburg)
>Assigned to: Tim Peters (tim_one)
>Summary: Patch which "inlines" small dictionaries

Initial Comment:
As discussed on python-dev, this patch inlines small
dictionary tables directly in the dictionary object.

----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2001-05-22 12:15

Message:
Logged In: YES 
user_id=31392

timdict2.patch looks good on the few little tests and real
applications that I reported below.  So measurement suggests
it does no harm, and reason suggests it helps.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-22 12:03

Message:
Logged In: YES 
user_id=31435

You're suffering an off-by-10000x error <wink>:  
test_mutants as-is actually creates 100 pairs of dicts (so 
that's 200 dicts) of average size 50, and fills the keys 
and values of each with instances of class Horrid (so 
that's about 20,000 additional instance dicts).

If Jeremy is still keen to time things (I kinda doubt it:  
we're not seeing any surprises), I'd much rather time real 
programs now -- in real life dicts aren't just created and 
destroyed, they're also accessed, and the small-but-real 
getitem/setitem critical-path reductions are aimed at the 
latter.


----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-22 10:15

Message:
Logged In: YES 
user_id=38388

Jeremy, I think you ought to test the patches against
benchmarks which actually make extensive use of dictionaries
(test_mutant only uses 2-3 dictionaries).

pybench's Instances.py looks like a good start....

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2001-05-22 08:45

Message:
Logged In: YES 
user_id=31392

Comparing three different dict impls on the same tests.

CVS -- Python 2.2 CVS repository as of May 21, 2001
TIM -- Tim's dict patches to inline small dicts
MAL -- MAL's dict patches to inline small dicts

Test machine: Jeremy's 800MHz PIII, 256MB RAM, Linux 2.2.17

Compiled with gcc 2.95.3 -O3

Tests:

pystone -- the standard pystone benchmark
mutants -- the test_mutants test from the Python regression
test
compile -- the compiler package compiling itself

Results

Results for macro benchmarks are median of 9 runs.

For the mutants and compile benchmarks, measurement is
combined user
and system time reported by Unix time utility.  For the
pystone
benchmark, result is time reported by pystone.

Result table

test              CVS      TIM      MAL
test_mutant       1.49     1.48     1.53
pystone           0.94     0.91     0.94 
compile          11.7     11.65    11.83

I tried running a few of the pybench tests with gprof
enabled, but
the time the runs took varied wildly -- a range of a few
seconds.



----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-22 02:54

Message:
Logged In: YES 
user_id=38388

I think I better leave the timing to Jeremy then. It'll be
another week or two before I get the new machine up and
running.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-21 22:29

Message:
Logged In: YES 
user_id=31435

I don't know, but I'd guess you're also using different 
releases of compilers, libraries and an OS since you first 
did this under 1.5.  Any of those could account for it too 
(e.g., in my Win9x days I traced many timing surprises to 
bizarre system malloc() behavior); the Python codebase is 
simply larger now too, thanks to mounds of useless new 
stuff like Unicode <wink>.

BTW, bump the priority on getting that new box:  I finally 
did that myself earlier this year, and it's still a joy 
that *everything* runs 5x faster.  My old machine wasn't 
quite quick enough to run Tomb Raider in high resolution, 
but now I can do that and test Python at the same time.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-21 14:01

Message:
Logged In: YES 
user_id=38388

I was a bit surprised at my timings, since I would have
expected a speedup too (I did get a speedup for Python 1.5
back in the old days). I think this has to do with CPU
caches and branch prediction.

In any case, a new machine is in the making :-) This old box
just aint no fun any more...


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-21 13:38

Message:
Logged In: YES 
user_id=31435

On my WinTel Win2K box at work, current CVS is ~12350 
pystone w/o my patch and ~12500 with it.  Jeremy's timings 
on his Linux+gcc box show small but reproducible 
improvements on some other "realer" programs.  I'm not 
surprised if it actually slows things on *some* platforms, 
because that's the nature of low-level optimization work.  
But the changes simplify the code on frequent paths, 
reducing the start-to-finish operation counts, and over 
time that's the only thing that reliably improves x-
platform performance.

BTW, the pystone results suggest you could get a factor of 
6 improvement in an hour by buying a midrange new machine 
<wink>.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-21 06:53

Message:
Logged In: YES 
user_id=38388

I've tested both patches against the unpatched CVS version
with pystone. The results are surprising: CVS benchmarks at
2300 pystones while your patch runs at 2200 pystones and my
patch at 2100 pystones.

I think we need to put some more thought into this...

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-21 02:07

Message:
Logged In: YES 
user_id=31435

There's more explanation about how to bump MINSIZE in the 
patch than in current dictobject.c.  Read the new 
comments!  You have to choose a power of 2 and fiddle the 
polys[] vector to match.  That's all.

The code defines a ma_smalltable member just as yours did.  
The rest is details.  Primarily it's more aggressive about 
exploiting the new member, because I found it was more 
efficient to avoid undue work in the empty case by looping 
on the ma_fill count rather than by continuing to 
constantly fiddle around with NULL-pointer checks all over 
dictobject.c (they've been replaced by asserts).  It does 
pay for a memset() of the ma_smalltable member during 
creation, though.

It would be interesting to try both patches, but I spent 
too much time on this already to debug your patch too.  It 
would be good if you could upload a new version of your 
patch.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-21 01:25

Message:
Logged In: YES 
user_id=38388

Hmm, timdict2.patch seems to be a completly different
solution. What I am missing in that patch is the ability to
tune the implementation... what happens if I want to bump
MINSIZE to some higher value ? I think the patch should at
least include an explanation of how this can be done.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-20 15:31

Message:
Logged In: YES 
user_id=31435

Just deleted my first patch.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-20 15:30

Message:
Logged In: YES 
user_id=31435

timdict2.patch is more aggressive about iterating until 
we've seen fill non-virgin entries go by rather than the 
table size.  This is never slower but is sometimes a 
surprising win!  For example, dicts keyed by a contiguous 
range of small integers tend to fill a solid initial 
segment of the dict.  When resizing or copying, after the 
patch it's common for the loop to get out, e.g., after ~170 
iterations instead of (the current, and always) 256.

Also added some desperately needed comments about what the 
GF(2^n-{0}) business means in pragmatic terms; + a few 
assorted cleanups.

I think this is ready for prime time, but do have concerns 
about the increased memory use (embedding an 8-slot table 
in every dict object means every dict bites another 8*3*4 
== 96 bytes on a 32-bit box; OTOH, dicts with up to and 
including 5 entries never need more space than that, and 
dicts with 3, 4 or 5 entries were actually larger before 
due to the malloc overhead tagging along with their 
dynamically allocated 8-slot table).

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-19 20:40

Message:
Logged In: YES 
user_id=31435

Assigned to Jeremy since he's been timing stuff lately 
too:  care to give it a try?

timdict.patch is in some ways more aggressive than MAL's 
patch, taking advantage of that we always have *some* 
memory to point to now, thus allowing to get rid of a bunch 
of table==NULL? tests and associated gotos and labels.

The newer patch passes all the tests I've thrown at it, in 
debug and release builds.  It was a major bitch to get 
working correctly, due to an excruciating interaction among 
PyDict_Clear() and garbage collection and module 
finalization and the special treatment of __builtins__ (who 
would have guessed that allocating a tuple could cause a 
module to finalize!?).

I never figured out why MAL's patch died, and after 
spending 10 hours figuring out why mine did, don't intend 
to waste the rest of the weekend trying <wink>.


----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-18 10:21

Message:
Logged In: YES 
user_id=38388

This is just a quick update of the original patch which I
prepared for Python 1.5 some years ago. Since the dictionary
implementation has evolved somewhat since then, I'm not sure
whether it still works as robust as it does for Python 1.5
(I've been using this for years without any problem).

Running the test suite, their appears to be a hanger due to
some endless loop which occurrs for test_popen2. I'm not
sure where Python hangs, but it could well be that the
resize routines have to adapted a little for the current
dict implementation.



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=425242&group_id=5470


From noreply@sourceforge.net  Tue May 22 21:41:49 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 22 May 2001 13:41:49 -0700
Subject: [Patches] [ python-Patches-425242 ] Patch which "inlines" small dictionaries
Message-ID: <E152IyT-0002VS-00@usw-sf-web2.sourceforge.net>

Patches item #425242, was updated on 2001-05-18 10:15
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=425242&group_id=5470

Category: core (C code)
Group: None
>Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: M.-A. Lemburg (lemburg)
Assigned to: Tim Peters (tim_one)
>Summary: Patch which "inlines" small dictionaries

Initial Comment:
As discussed on python-dev, this patch inlines small
dictionary tables directly in the dictionary object.

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-05-22 13:41

Message:
Logged In: YES 
user_id=31435

Checked in as Objects/dictobject.c, new revision: 2.91.
See checkin comment for more.

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2001-05-22 12:15

Message:
Logged In: YES 
user_id=31392

timdict2.patch looks good on the few little tests and real
applications that I reported below.  So measurement suggests
it does no harm, and reason suggests it helps.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-22 12:03

Message:
Logged In: YES 
user_id=31435

You're suffering an off-by-10000x error <wink>:  
test_mutants as-is actually creates 100 pairs of dicts (so 
that's 200 dicts) of average size 50, and fills the keys 
and values of each with instances of class Horrid (so 
that's about 20,000 additional instance dicts).

If Jeremy is still keen to time things (I kinda doubt it:  
we're not seeing any surprises), I'd much rather time real 
programs now -- in real life dicts aren't just created and 
destroyed, they're also accessed, and the small-but-real 
getitem/setitem critical-path reductions are aimed at the 
latter.


----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-22 10:15

Message:
Logged In: YES 
user_id=38388

Jeremy, I think you ought to test the patches against
benchmarks which actually make extensive use of dictionaries
(test_mutant only uses 2-3 dictionaries).

pybench's Instances.py looks like a good start....

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2001-05-22 08:45

Message:
Logged In: YES 
user_id=31392

Comparing three different dict impls on the same tests.

CVS -- Python 2.2 CVS repository as of May 21, 2001
TIM -- Tim's dict patches to inline small dicts
MAL -- MAL's dict patches to inline small dicts

Test machine: Jeremy's 800MHz PIII, 256MB RAM, Linux 2.2.17

Compiled with gcc 2.95.3 -O3

Tests:

pystone -- the standard pystone benchmark
mutants -- the test_mutants test from the Python regression
test
compile -- the compiler package compiling itself

Results

Results for macro benchmarks are median of 9 runs.

For the mutants and compile benchmarks, measurement is
combined user
and system time reported by Unix time utility.  For the
pystone
benchmark, result is time reported by pystone.

Result table

test              CVS      TIM      MAL
test_mutant       1.49     1.48     1.53
pystone           0.94     0.91     0.94 
compile          11.7     11.65    11.83

I tried running a few of the pybench tests with gprof
enabled, but
the time the runs took varied wildly -- a range of a few
seconds.



----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-22 02:54

Message:
Logged In: YES 
user_id=38388

I think I better leave the timing to Jeremy then. It'll be
another week or two before I get the new machine up and
running.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-21 22:29

Message:
Logged In: YES 
user_id=31435

I don't know, but I'd guess you're also using different 
releases of compilers, libraries and an OS since you first 
did this under 1.5.  Any of those could account for it too 
(e.g., in my Win9x days I traced many timing surprises to 
bizarre system malloc() behavior); the Python codebase is 
simply larger now too, thanks to mounds of useless new 
stuff like Unicode <wink>.

BTW, bump the priority on getting that new box:  I finally 
did that myself earlier this year, and it's still a joy 
that *everything* runs 5x faster.  My old machine wasn't 
quite quick enough to run Tomb Raider in high resolution, 
but now I can do that and test Python at the same time.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-21 14:01

Message:
Logged In: YES 
user_id=38388

I was a bit surprised at my timings, since I would have
expected a speedup too (I did get a speedup for Python 1.5
back in the old days). I think this has to do with CPU
caches and branch prediction.

In any case, a new machine is in the making :-) This old box
just aint no fun any more...


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-21 13:38

Message:
Logged In: YES 
user_id=31435

On my WinTel Win2K box at work, current CVS is ~12350 
pystone w/o my patch and ~12500 with it.  Jeremy's timings 
on his Linux+gcc box show small but reproducible 
improvements on some other "realer" programs.  I'm not 
surprised if it actually slows things on *some* platforms, 
because that's the nature of low-level optimization work.  
But the changes simplify the code on frequent paths, 
reducing the start-to-finish operation counts, and over 
time that's the only thing that reliably improves x-
platform performance.

BTW, the pystone results suggest you could get a factor of 
6 improvement in an hour by buying a midrange new machine 
<wink>.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-21 06:53

Message:
Logged In: YES 
user_id=38388

I've tested both patches against the unpatched CVS version
with pystone. The results are surprising: CVS benchmarks at
2300 pystones while your patch runs at 2200 pystones and my
patch at 2100 pystones.

I think we need to put some more thought into this...

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-21 02:07

Message:
Logged In: YES 
user_id=31435

There's more explanation about how to bump MINSIZE in the 
patch than in current dictobject.c.  Read the new 
comments!  You have to choose a power of 2 and fiddle the 
polys[] vector to match.  That's all.

The code defines a ma_smalltable member just as yours did.  
The rest is details.  Primarily it's more aggressive about 
exploiting the new member, because I found it was more 
efficient to avoid undue work in the empty case by looping 
on the ma_fill count rather than by continuing to 
constantly fiddle around with NULL-pointer checks all over 
dictobject.c (they've been replaced by asserts).  It does 
pay for a memset() of the ma_smalltable member during 
creation, though.

It would be interesting to try both patches, but I spent 
too much time on this already to debug your patch too.  It 
would be good if you could upload a new version of your 
patch.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-21 01:25

Message:
Logged In: YES 
user_id=38388

Hmm, timdict2.patch seems to be a completly different
solution. What I am missing in that patch is the ability to
tune the implementation... what happens if I want to bump
MINSIZE to some higher value ? I think the patch should at
least include an explanation of how this can be done.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-20 15:31

Message:
Logged In: YES 
user_id=31435

Just deleted my first patch.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-20 15:30

Message:
Logged In: YES 
user_id=31435

timdict2.patch is more aggressive about iterating until 
we've seen fill non-virgin entries go by rather than the 
table size.  This is never slower but is sometimes a 
surprising win!  For example, dicts keyed by a contiguous 
range of small integers tend to fill a solid initial 
segment of the dict.  When resizing or copying, after the 
patch it's common for the loop to get out, e.g., after ~170 
iterations instead of (the current, and always) 256.

Also added some desperately needed comments about what the 
GF(2^n-{0}) business means in pragmatic terms; + a few 
assorted cleanups.

I think this is ready for prime time, but do have concerns 
about the increased memory use (embedding an 8-slot table 
in every dict object means every dict bites another 8*3*4 
== 96 bytes on a 32-bit box; OTOH, dicts with up to and 
including 5 entries never need more space than that, and 
dicts with 3, 4 or 5 entries were actually larger before 
due to the malloc overhead tagging along with their 
dynamically allocated 8-slot table).

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-19 20:40

Message:
Logged In: YES 
user_id=31435

Assigned to Jeremy since he's been timing stuff lately 
too:  care to give it a try?

timdict.patch is in some ways more aggressive than MAL's 
patch, taking advantage of that we always have *some* 
memory to point to now, thus allowing to get rid of a bunch 
of table==NULL? tests and associated gotos and labels.

The newer patch passes all the tests I've thrown at it, in 
debug and release builds.  It was a major bitch to get 
working correctly, due to an excruciating interaction among 
PyDict_Clear() and garbage collection and module 
finalization and the special treatment of __builtins__ (who 
would have guessed that allocating a tuple could cause a 
module to finalize!?).

I never figured out why MAL's patch died, and after 
spending 10 hours figuring out why mine did, don't intend 
to waste the rest of the weekend trying <wink>.


----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-18 10:21

Message:
Logged In: YES 
user_id=38388

This is just a quick update of the original patch which I
prepared for Python 1.5 some years ago. Since the dictionary
implementation has evolved somewhat since then, I'm not sure
whether it still works as robust as it does for Python 1.5
(I've been using this for years without any problem).

Running the test suite, their appears to be a hanger due to
some endless loop which occurrs for test_popen2. I'm not
sure where Python hangs, but it could well be that the
resize routines have to adapted a little for the current
dict implementation.



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=425242&group_id=5470


From noreply@sourceforge.net  Tue May 22 22:31:26 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 22 May 2001 14:31:26 -0700
Subject: [Patches] [ python-Patches-424335 ] richcompare for strings
Message-ID: <E152JkU-0004U8-00@usw-sf-web3.sourceforge.net>

Patches item #424335, was updated on 2001-05-15 12:54
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=424335&group_id=5470

Category: core (C code)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Martin v. Löwis (loewis)
>Assigned to: Tim Peters (tim_one)
Summary: richcompare for strings

Initial Comment:
This patch implements the tp_richcompare slot for
string objects. It shows a 8% speed-up on selected test
cases.

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-05-22 14:31

Message:
Logged In: YES 
user_id=31435

Assigned to me.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2001-05-21 08:33

Message:
Logged In: YES 
user_id=21627

The new revision of the patch entirely removes tp_compare
for string, following discussions on python-dev. The only
direct user of string_compare has been changed to use the
new function _PyString_Eq instead.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=424335&group_id=5470


From noreply@sourceforge.net  Wed May 23 00:04:50 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 22 May 2001 16:04:50 -0700
Subject: [Patches] [ python-Patches-424335 ] richcompare for strings
Message-ID: <E152LCs-0002w9-00@usw-sf-web1.sourceforge.net>

Patches item #424335, was updated on 2001-05-15 12:54
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=424335&group_id=5470

Category: core (C code)
Group: None
Status: Open
>Resolution: Accepted
Priority: 5
Submitted By: Martin v. Löwis (loewis)
Assigned to: Tim Peters (tim_one)
Summary: richcompare for strings

Initial Comment:
This patch implements the tp_richcompare slot for
string objects. It shows a 8% speed-up on selected test
cases.

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-05-22 16:04

Message:
Logged In: YES 
user_id=31435

Marked accepted.  Looks good!

Suggest

return a->ob_size == b->ob_size &&
       *a->ob_sval == *b->ob_sval &&
       memcmp(a->ob_sval, b->ob_sval, a->ob_size) == 0;

for the tail of the _PyString_Eq body as compilers should 
have an easier time of turning that into the best code for 
the platform (especially the weaker compilers do better 
optimizing expressions than across branches).  Plus it 
improves clarity, at least for me.

Unsure why the

case Py_EQ: c = c == 0; break; /* not needed here */

case is there:  if it's truly unreacable (and I agree it 
isn't), better to assert-fail if it gets there.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-22 14:31

Message:
Logged In: YES 
user_id=31435

Assigned to me.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2001-05-21 08:33

Message:
Logged In: YES 
user_id=21627

The new revision of the patch entirely removes tp_compare
for string, following discussions on python-dev. The only
direct user of string_compare has been changed to use the
new function _PyString_Eq instead.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=424335&group_id=5470


From noreply@sourceforge.net  Wed May 23 12:58:06 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 23 May 2001 04:58:06 -0700
Subject: [Patches] [ python-Patches-426598 ] doc patch for os.rename
Message-ID: <E152XHC-0003Gp-00@usw-sf-web2.sourceforge.net>

Patches item #426598, was updated on 2001-05-23 04:58
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=426598&group_id=5470

Category: documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: doc patch for os.rename

Initial Comment:
os.rename on Windows fails if the destination file
already
exists.  This patch documents that fact.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=426598&group_id=5470


From noreply@sourceforge.net  Wed May 23 21:29:54 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 23 May 2001 13:29:54 -0700
Subject: [Patches] [ python-Patches-426746 ] Infrastructure for getting MacPython modules working on OSX
Message-ID: <E152fGU-0000Pc-00@usw-sf-web2.sourceforge.net>

Patches item #426746, was updated on 2001-05-23 13:29
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=426746&group_id=5470

Category: Build
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Nobody/Anonymous (nobody)
Summary: Infrastructure for getting MacPython modules working on OSX

Initial Comment:
Here are a couple of patches that optionally (on MacOSX) enable a bit of extra infrastructure in the Python core, to allow various (MacPython-originated) dynamic extension modules to be built. Here's what I patched:

- Added a MACHDEP_OBJS variable to Makefile.pre.in and configure.in. This allows platforms to include patform-specific sourcefiles to be added to the core build.

- Added (using MACHDEP_OBJS) a macglue.c file to the build, which contains glue code that allows Mac extension modules to refer to each other while being in separate dynamically loaded modules, plus a couple of utility routines. There's also a few changes to LDFLAGS to get the object file incorporated (as it is otherwise optimized away because the rest of Python doesn't refer to it).

- Added a config.h.in define USE_TOOLBOX_OBJECT_GLUE which enables the glue code mentioned above (which isn't need in MacPython, only in Mach-O Python).

Possibly the latter two should be dependent on a configure switch (--with-mac-toolbox-modules?) but (a) I think the added memory footprint is minimal and (b) I never understood how to add configure switches:-)

A setup.py patch will follow, but I'm still testing it.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=426746&group_id=5470


From noreply@sourceforge.net  Wed May 23 23:00:09 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 23 May 2001 15:00:09 -0700
Subject: [Patches] [ python-Patches-426208 ] Fun with Floating Point
Message-ID: <E152gfp-0000FI-00@usw-sf-web1.sourceforge.net>

Patches item #426208, was updated on 2001-05-22 01:06
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=426208&group_id=5470

Category: documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Fun with Floating Point

Initial Comment:
I suggest this as an Appendix.  For Michel Pelletier's 
benefit, it contains no equation <wink>.  Alas for 
you, for my benefit it contains no LaTeX markup 
either.  Season to taste!


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-05-23 15:00

Message:
Logged In: YES 
user_id=31435

Deleted the attachment in preparation for uploading a new 
one.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=426208&group_id=5470


From noreply@sourceforge.net  Wed May 23 23:02:26 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 23 May 2001 15:02:26 -0700
Subject: [Patches] [ python-Patches-426208 ] Fun with Floating Point
Message-ID: <E152gi2-0000HY-00@usw-sf-web1.sourceforge.net>

Patches item #426208, was updated on 2001-05-22 01:06
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=426208&group_id=5470

Category: documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Fun with Floating Point

Initial Comment:
I suggest this as an Appendix.  For Michel Pelletier's 
benefit, it contains no equation <wink>.  Alas for 
you, for my benefit it contains no LaTeX markup 
either.  Season to taste!


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-05-23 15:02

Message:
Logged In: YES 
user_id=31435

New text, with improved wording, and an un-Wikized version 
of the RepresentationError page at the end as a new section.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-23 15:00

Message:
Logged In: YES 
user_id=31435

Deleted the attachment in preparation for uploading a new 
one.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=426208&group_id=5470


From noreply@sourceforge.net  Thu May 24 05:48:50 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 23 May 2001 21:48:50 -0700
Subject: [Patches] [ python-Patches-424335 ] richcompare for strings
Message-ID: <E152n3K-0002ut-00@usw-sf-web3.sourceforge.net>

Patches item #424335, was updated on 2001-05-15 12:54
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=424335&group_id=5470

Category: core (C code)
Group: None
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Martin v. Löwis (loewis)
>Assigned to: Martin v. Löwis (loewis)
Summary: richcompare for strings

Initial Comment:
This patch implements the tp_richcompare slot for
string objects. It shows a 8% speed-up on selected test
cases.

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-05-23 21:48

Message:
Logged In: YES 
user_id=31435

Oops!  Looks like I forgot to assign this back to Martin.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-22 16:04

Message:
Logged In: YES 
user_id=31435

Marked accepted.  Looks good!

Suggest

return a->ob_size == b->ob_size &&
       *a->ob_sval == *b->ob_sval &&
       memcmp(a->ob_sval, b->ob_sval, a->ob_size) == 0;

for the tail of the _PyString_Eq body as compilers should 
have an easier time of turning that into the best code for 
the platform (especially the weaker compilers do better 
optimizing expressions than across branches).  Plus it 
improves clarity, at least for me.

Unsure why the

case Py_EQ: c = c == 0; break; /* not needed here */

case is there:  if it's truly unreacable (and I agree it 
isn't), better to assert-fail if it gets there.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-22 14:31

Message:
Logged In: YES 
user_id=31435

Assigned to me.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2001-05-21 08:33

Message:
Logged In: YES 
user_id=21627

The new revision of the patch entirely removes tp_compare
for string, following discussions on python-dev. The only
direct user of string_compare has been changed to use the
new function _PyString_Eq instead.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=424335&group_id=5470


From noreply@sourceforge.net  Thu May 24 08:41:02 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 24 May 2001 00:41:02 -0700
Subject: [Patches] [ python-Patches-426880 ] Tkinter Listbox missing methods
Message-ID: <E152pjy-0000yH-00@usw-sf-web1.sourceforge.net>

Patches item #426880, was updated on 2001-05-24 00:41
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=426880&group_id=5470

Category: Tkinter
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Tkinter Listbox missing methods

Initial Comment:
Both the itemconfigure and the itemcget methods are
missing in the current Tkinter so here they are.....

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=426880&group_id=5470


From noreply@sourceforge.net  Fri May 25 06:30:35 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 24 May 2001 22:30:35 -0700
Subject: [Patches] [ python-Patches-427190 ] Speed-up "O" calls
Message-ID: <E153ABH-0007Xo-00@usw-sf-web1.sourceforge.net>

Patches item #427190, was updated on 2001-05-24 22:30
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=427190&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Martin v. Löwis (loewis)
Assigned to: Nobody/Anonymous (nobody)
Summary: Speed-up "O" calls

Initial Comment:
This patch improves the performance of a few functions
which have an "O" signature (ord, len, and
list_append). On selected test cases, this patch gives
a speed-up of 40%. If accepted, the approach can be
extended to more signatures. E.g. "l" is already
provided in the patch, but currently not used.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=427190&group_id=5470


From noreply@sourceforge.net  Sat May 26 07:58:41 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 25 May 2001 23:58:41 -0700
Subject: [Patches] [ python-Patches-426072 ] special case "O" in PyArg_ParseTuple()
Message-ID: <E153Y25-0004ZV-00@usw-sf-web1.sourceforge.net>

Patches item #426072, was updated on 2001-05-21 14:29
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=426072&group_id=5470

Category: core (C code)
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Jeremy Hylton (jhylton)
>Assigned to: Jeremy Hylton (jhylton)
>Summary: special case "O" in PyArg_ParseTuple()

Initial Comment:
The most common argument passed to PyArg_ParseTuple() 
is one or more Os. Special-case Os to make this go a
bit faster.

Also eliminate the convertsimple(), convertsimple1()
two-step, since it's adding an extra function call to
all cases to handle the error cases.  Instead, call the
extra function only when an error occurs.

Note that the indentation in this patch is a bit messy.

The speedup is modest.  On the parsetuple-intensive
benchmarks like pybench's BuiltinFunctionCalls, this
patch reduces the cost of PyArg_ParseTuple() by almost
40%.


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-05-25 23:58

Message:
Logged In: YES 
user_id=31435

Since there are other schemes under active discussion right 
now, how about applying the large pieces of this patch that 
make the current code saner?  Like avoiding the two-step, 
and transforming masses of if/else_if/else_if/ ... into 
switch stmts.  That's Good Stuff regardless -- and make the 
rest of the patch small enough to understand what's 
*really* changing <wink>.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=426072&group_id=5470


From noreply@sourceforge.net  Sat May 26 22:04:39 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 26 May 2001 14:04:39 -0700
Subject: [Patches] [ python-Patches-422471 ] Install IDLE Help File
Message-ID: <E153lEl-00066b-00@usw-sf-web1.sourceforge.net>

Patches item #422471, was updated on 2001-05-08 14:48
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=422471&group_id=5470

Category: IDLE
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Kurt B. Kaiser (kbk)
Assigned to: Nobody/Anonymous (nobody)
>Summary: Install IDLE Help File

Initial Comment:
Installing Idle to site-packages via Distutils does not
copy
the Idle help.txt file.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=422471&group_id=5470


From mail@ykcom.com  Sun May 27 09:42:03 2001
From: mail@ykcom.com (mail@ykcom.com)
Date: Sun, 27 May 2001 08:42:03
Subject: [Patches] Place your ads... Free offer expires on 5-31-01
Message-ID: <E153zfu-0000oJ-00@mail.python.org>

Place your LISTINGS or AD for FREE and Find your buyers..
--------------------------------------------------------------------------------------------------
Businesses for sale, Investment Properties,
Franchises, Homebased businesses, Distributors, Wholesales, M&A,
Other Special Businesses...

There will be a fee for placing ad from 6-01-2001 ( we'll charge it as low as possible.)
To place your ads before 5-31-2001 for Free,  
Visit our website http://www.findmybusiness.com

**30 days free trial for 4zip.net the broker's website listing services**
Find our features and maximize your business while you save a lot on your high cost of marketing.
Check our service at http://4zip.net
---------------------------------------------------------------------------------------------------
He will never let you down,  Trust in the Lord with all your heart...



From noreply@sourceforge.net  Sun May 27 19:35:12 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 27 May 2001 11:35:12 -0700
Subject: [Patches] [ python-Patches-427749 ] Patch for bug #419390 (base64.py)
Message-ID: <E1545Ng-0005GG-00@usw-sf-web1.sourceforge.net>

Patches item #427749, was updated on 2001-05-27 11:35
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=427749&group_id=5470

Category: library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Kalle Svensson (krftkndl)
Assigned to: Nobody/Anonymous (nobody)
Summary: Patch for bug #419390 (base64.py)

Initial Comment:
Improves performance of base64.encodestring and
base64.decodestring by avoiding StringIO and using
binascii directly.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=427749&group_id=5470


From fdsf@gfdasf.com  Mon May 28 12:30:05 2001
From: fdsf@gfdasf.com (china)
Date: Mon, 28 May 2001 07:30:05 -0400
Subject: [Patches] The best chinese manufacturer
Message-ID: <E154LDp-0003nV-00@mail.python.org>

Dear sir, welcome to:http://www.longf.com,
the best chinese manufacturer with biggest production scale, full range of products, most advanced technological facilities, perfect means of measurement and strongest capacity for development and research within the same domestic profession.
Web site:http://www.longf.com. 


From sanyol@omen.ru  Tue May 29 00:13:33 2001
From: sanyol@omen.ru (sanyol@omen.ru)
Date: Mon, 28 May 2001 16:13:33 -0700
Subject: [Patches] îïõôâõëé, íõìøôéíåäéá-ðòïåëôïòù
Message-ID: <E154WCb-0009Di-00@zeus.net-werks.com>

This is a MIME encoded message.

--b16bcb27d58756cb2ef4d1f9af4cb91b4
Content-Type: text/html ;	charset="windows-1251"
Content-Transfer-Encoding: base64

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv
L0VOIj4NCg0KPGh0bWw+DQo8aGVhZD4NCgk8dGl0bGU+zc7T0sHTysgsIMzTy9zSyMzFxMjALc/Q
zsXK0s7Q2zwvdGl0bGU+DQo8L2hlYWQ+DQoNCjxib2R5Pg0KPGRpdiBhbGlnbj0iQ0VOVEVSIj48
Zm9udCBmYWNlPSIiIGNvbG9yPSJCbHVlIj48aDI+zc7T0sHTysgsIMzTy9zSyMzFxMjALc/QzsXK
0s7Q2zwvaDI+PC9mb250PjwvZGl2Pg0KoKCgoKCg0+Lg5uDl7PvlIOPu8e/u5OAhPGJyPg0KoKCg
oKCgz/Dl5Ovg4+Dl7CDh7uv8+O7pIOL74e7wIM3O09LB08rOwiDoIMzTy9zSyMzFxMjALc/QzsXK
0s7QzsIg8e4g8err4OTgIOIgzO7x6uLlLjxicj4NCqCgoKCgoNbl7fsg5+3g9+jy5ev87e4g8e3o
5uXt+y48YnI+DQqgoKCgoKDP7vHw5eTt6Org7CDv8OXk8/Hs7vLw5e3uIODj5e3y8eru5SDi7uft
4OPw4Obk5e3o5S48YnI+DQqgoKCgoKDP8OXk6+Dj4OXsIPLg6ublIO7h7vDz5O7i4O3o5SDk6/8g
8e7n5ODt6P8g4eXx7/Du4u7k7fv1IPHl8uXpIOgg8/Hr8+PoIO/uIOj1IO/w7uXq8ujw7uLg7ej+
IOgg7O7t8uDm8y48YnI+DQqgoKCgoKDS5esuL9Tg6vE6ICgwOTUpIDxmb250IHNpemU9IisxIj48
Yj43NjAtNzktNDI8L2I+PC9mb250Pjxicj4NCg0KIKCgoKCgoDxhIGhyZWY9Im1haWx0bzpzYW55
b21Ab21lbi5ydSI+c2FueW9tQG9tZW4ucnU8L2E+DQoNCg0KDQo8L2JvZHk+DQo8L2h0bWw+DQo=

--b16bcb27d58756cb2ef4d1f9af4cb91b4--





From noreply@sourceforge.net  Tue May 29 15:58:38 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 29 May 2001 07:58:38 -0700
Subject: [Patches] [ python-Patches-428320 ] rich comparisons as operator.__lt__ etc.
Message-ID: <E154kxC-0005Jd-00@usw-sf-web1.sourceforge.net>

Patches item #428320, was updated on 2001-05-29 07:58
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=428320&group_id=5470

Category: library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: rich comparisons as operator.__lt__ etc.

Initial Comment:
Rich Comparisons (PEP 207) introduce new special names
in classes (__lt__, __le__, __eq__, etc.). They should
be available in the 'operator' module just like the
other special names (__add__ and the like).

This patch introduce 12 new names in 'operator': lt,
le, eq, ne, gt, ge, __lt__, __le__, __eq__, __ne__,
__gt__, __ge__. The first 6 are provided for uniformity
with the rest of the module but I am not sure whether
it is a good idea to clutter a namespace with names
only two letters long; for example, could names like
'eq' accidentally break existing programs using

  from operator import *

?


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=428320&group_id=5470


From noreply@sourceforge.net  Tue May 29 16:01:50 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 29 May 2001 08:01:50 -0700
Subject: [Patches] [ python-Patches-428320 ] rich comparisons as operator.__lt__ etc.
Message-ID: <E154l0I-0005N5-00@usw-sf-web1.sourceforge.net>

Patches item #428320, was updated on 2001-05-29 07:58
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=428320&group_id=5470

Category: library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: rich comparisons as operator.__lt__ etc.

Initial Comment:
Rich Comparisons (PEP 207) introduce new special names
in classes (__lt__, __le__, __eq__, etc.). They should
be available in the 'operator' module just like the
other special names (__add__ and the like).

This patch introduce 12 new names in 'operator': lt,
le, eq, ne, gt, ge, __lt__, __le__, __eq__, __ne__,
__gt__, __ge__. The first 6 are provided for uniformity
with the rest of the module but I am not sure whether
it is a good idea to clutter a namespace with names
only two letters long; for example, could names like
'eq' accidentally break existing programs using

  from operator import *

?


----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2001-05-29 08:01

Message:
Logged In: YES 
user_id=4771

Sorry, I forgot to login when I posted the patch.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=428320&group_id=5470


From noreply@sourceforge.net  Tue May 29 16:20:30 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 29 May 2001 08:20:30 -0700
Subject: [Patches] [ python-Patches-428326 ] Timer class for threading
Message-ID: <E154lIM-0005do-00@usw-sf-web1.sourceforge.net>

Patches item #428326, was updated on 2001-05-29 08:20
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=428326&group_id=5470

Category: library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Itamar Shtull-Trauring (itamar)
Assigned to: Nobody/Anonymous (nobody)
Summary: Timer class for threading

Initial Comment:
The Timer class allows you to schedule an action to
happen at some time in the future, using a thread. For
example:

  def f():
      print "30 seconds have passed"

  t = Timer(30.0, f)
  t.start() # after 30 seconds f will be called

  try:  
      # .... other stuff
  except SystemExit:
      t.cancel() # cancel the timer since we are
shutting down


It allows passing arguments and keyword arguments to
the function that is called. It also allows
*cancelling* the timer. That is, if the timer is still
waiting, we can tell it to stop its operation.

Why should this be in the standard library?

1. Timers are a standard, useful programming idiom.

2.  It can be used as an example of how to:
     a. create subclasses of threading.Thread
     b. make threads that can be "stopped"


If this patch is approved I will then write
documentation. I'm not sure how to go about writing
tests for it.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=428326&group_id=5470


From noreply@sourceforge.net  Tue May 29 17:45:53 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 29 May 2001 09:45:53 -0700
Subject: [Patches] [ python-Patches-428326 ] Timer class for threading
Message-ID: <E154mcz-0000zT-00@usw-sf-web2.sourceforge.net>

Patches item #428326, was updated on 2001-05-29 08:20
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=428326&group_id=5470

Category: library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Itamar Shtull-Trauring (itamar)
Assigned to: Nobody/Anonymous (nobody)
Summary: Timer class for threading

Initial Comment:
The Timer class allows you to schedule an action to
happen at some time in the future, using a thread. For
example:

  def f():
      print "30 seconds have passed"

  t = Timer(30.0, f)
  t.start() # after 30 seconds f will be called

  try:  
      # .... other stuff
  except SystemExit:
      t.cancel() # cancel the timer since we are
shutting down


It allows passing arguments and keyword arguments to
the function that is called. It also allows
*cancelling* the timer. That is, if the timer is still
waiting, we can tell it to stop its operation.

Why should this be in the standard library?

1. Timers are a standard, useful programming idiom.

2.  It can be used as an example of how to:
     a. create subclasses of threading.Thread
     b. make threads that can be "stopped"


If this patch is approved I will then write
documentation. I'm not sure how to go about writing
tests for it.

----------------------------------------------------------------------

>Comment By: Itamar Shtull-Trauring (itamar)
Date: 2001-05-29 09:45

Message:
Logged In: YES 
user_id=32065

I'm withdrawing this patch for a short period of time for
non-technical reasons, hopefully I can put it back soon.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=428326&group_id=5470


From noreply@sourceforge.net  Tue May 29 18:47:09 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 29 May 2001 10:47:09 -0700
Subject: [Patches] [ python-Patches-426072 ] special case "O" in PyArg_ParseTuple()
Message-ID: <E154naH-0007h9-00@usw-sf-web3.sourceforge.net>

Patches item #426072, was updated on 2001-05-21 14:29
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=426072&group_id=5470

Category: core (C code)
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 3
Submitted By: Jeremy Hylton (jhylton)
Assigned to: Jeremy Hylton (jhylton)
>Summary: special case "O" in PyArg_ParseTuple()

Initial Comment:
The most common argument passed to PyArg_ParseTuple() 
is one or more Os. Special-case Os to make this go a
bit faster.

Also eliminate the convertsimple(), convertsimple1()
two-step, since it's adding an extra function call to
all cases to handle the error cases.  Instead, call the
extra function only when an error occurs.

Note that the indentation in this patch is a bit messy.

The speedup is modest.  On the parsetuple-intensive
benchmarks like pybench's BuiltinFunctionCalls, this
patch reduces the cost of PyArg_ParseTuple() by almost
40%.


----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2001-05-29 10:47

Message:
Logged In: YES 
user_id=31392

The two parts of the patch that don't special case the snot
of 'O' are checked in as rev. 2.59 and 2.60.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-25 23:58

Message:
Logged In: YES 
user_id=31435

Since there are other schemes under active discussion right 
now, how about applying the large pieces of this patch that 
make the current code saner?  Like avoiding the two-step, 
and transforming masses of if/else_if/else_if/ ... into 
switch stmts.  That's Good Stuff regardless -- and make the 
rest of the patch small enough to understand what's 
*really* changing <wink>.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=426072&group_id=5470


From noreply@sourceforge.net  Tue May 29 19:37:28 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 29 May 2001 11:37:28 -0700
Subject: [Patches] [ python-Patches-426598 ] doc patch for os.rename
Message-ID: <E154oMy-0008TW-00@usw-sf-web3.sourceforge.net>

Patches item #426598, was updated on 2001-05-23 04:58
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=426598&group_id=5470

Category: documentation
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: doc patch for os.rename

Initial Comment:
os.rename on Windows fails if the destination file
already
exists.  This patch documents that fact.


----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-05-29 11:37

Message:
Logged In: YES 
user_id=3066

Checked in as Doc/lib/libos.tex revisions 1.54 and 1.53.4.1.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=426598&group_id=5470


From noreply@sourceforge.net  Tue May 29 21:59:29 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 29 May 2001 13:59:29 -0700
Subject: [Patches] [ python-Patches-427190 ] Speed-up "O" calls
Message-ID: <E154qaP-0003sS-00@usw-sf-web2.sourceforge.net>

Patches item #427190, was updated on 2001-05-24 22:30
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=427190&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Martin v. Löwis (loewis)
>Assigned to: Martin v. Löwis (loewis)
>Summary: Speed-up "O" calls

Initial Comment:
This patch improves the performance of a few functions
which have an "O" signature (ord, len, and
list_append). On selected test cases, this patch gives
a speed-up of 40%. If accepted, the approach can be
extended to more signatures. E.g. "l" is already
provided in the patch, but currently not used.

----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2001-05-29 13:59

Message:
Logged In: YES 
user_id=31392

I like METH_O, but I'm not sure about METH_L.  I'd rather
see the call handling in ceval be type-neutral.  It's easy
enough for the callee to cast from an object to an int (or
any other type).  There should be no effect on performance
and it reduces the amount of code in the core.

I think the implementation could be simplified a lot if it
defined METH_O -- or perhaps METH_NOARGS,  METH_ONEARG, and
maybe even METH_TWOARGS (but Tim has a pretty good argument
against that one).  I don't think there's any define METH_O
via METH_SPECIAL and reserve all of 0xFFF0 for flags on
METH_SPECIAL.  Instead, I'd just use the next N bits to
implement the next N flags.

The SPECIALSIZE and extra stack used in the implementation
seem like unneeded generality, too.  If the implementation
is only going to support 0 and 1 (and possibly 2) argument,
there's no need for anything more general.

Finally, I suggest appropriating fast_cfunction() for this
purpose, rather than calling the new function
do_call_special(), where "special" isn't a very specific
meaning.  If METH_NOARGS and METH_ONEARG are implemented,
there is basically no reason to use METH_OLDARGS.  So we can
get rid of it in the code base and stop attempting to
optimize it.

Do you want to have a go at a smaller patch that just did
METH_ONEARG and METH_NOARGS?


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=427190&group_id=5470


From mail@ykcom.com  Wed May 30 02:50:43 2001
From: mail@ykcom.com (mail@ykcom.com)
Date: Wed, 30 May 2001 01:50:43
Subject: [Patches] Place your ads... Free offer expires on 5-31-01
Message-ID: <E154yft-0000n2-00@mail.python.org>

Place your LISTINGS or AD for FREE and Find your buyers..
--------------------------------------------------------------------------------------------------
Businesses for sale, Investment Properties,
Franchises, Homebased businesses, Distributors, Wholesales, M&A,
Other Special Businesses...

There will be a fee for placing ad from 6-01-2001 ( we'll charge it as low as possible.)
To place your ads before 5-31-2001 for Free,  
Visit our website http://www.findmybusiness.com

**30 days free trial for 4zip.net the broker's website listing services**
Find our features and maximize your business while you save a lot on your high cost of marketing.
Check our service at http://4zip.net
---------------------------------------------------------------------------------------------------
He will never let you down,  Trust in the Lord with all your heart...




From noreply@sourceforge.net  Wed May 30 07:23:50 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 29 May 2001 23:23:50 -0700
Subject: [Patches] [ python-Patches-423221 ] Add a few Windows encoding aliases
Message-ID: <E154zOY-0008Pl-00@usw-sf-web3.sourceforge.net>

Patches item #423221, was updated on 2001-05-10 21:14
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=423221&group_id=5470

Category: library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Brian Quinlan (bquinlan)
Assigned to: Mark Hammond (mhammond)
Summary: Add a few Windows encoding aliases

Initial Comment:
This patch adds aliases for some of the common Windows 
encodings. Windows-1252 is particularly useful because 
it is the default encoding used by Visual Studio .NET 
projects. 

Microsoft's complete encoding list can be found at:
http://msdn.microsoft.com/workshop/author/dhtml/referen
ce/charsets/charset4.asp


----------------------------------------------------------------------

>Comment By: Brian Quinlan (bquinlan)
Date: 2001-05-29 23:23

Message:
Logged In: YES 
user_id=108973

The first patch (alias.patch) is incorrect and I'm not sure 
it the replacement (aliases.patch) is visible to anyone but 
me, so here is aliases.patch inline:

*** d:\Dev\python\dist\src\Lib\encodings\aliases.py	Wed 
Jun  7 02:12:30 2000
--- d:\Dev\python-dev\dist\src\Lib\encodings\aliases.py	Tue 
May 29 19:16:58 2001
***************
*** 59,64 ****
--- 59,69 ----
      'macroman': 'mac_roman',
      'macturkish': 'mac_turkish',
  
+     # Windows
+     'windows_1252': 'cp1252',
+     'windows_1254': 'cp1254',
+     'windows_1255': 'cp1255',
+     
      # MBCS
      'dbcs': 'mbcs',

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=423221&group_id=5470


From noreply@sourceforge.net  Wed May 30 07:30:37 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 29 May 2001 23:30:37 -0700
Subject: [Patches] [ python-Patches-423221 ] Add a few Windows encoding aliases
Message-ID: <E154zV7-0008UJ-00@usw-sf-web3.sourceforge.net>

Patches item #423221, was updated on 2001-05-10 21:14
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=423221&group_id=5470

Category: library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Brian Quinlan (bquinlan)
>Assigned to: M.-A. Lemburg (lemburg)
Summary: Add a few Windows encoding aliases

Initial Comment:
This patch adds aliases for some of the common Windows 
encodings. Windows-1252 is particularly useful because 
it is the default encoding used by Visual Studio .NET 
projects. 

Microsoft's complete encoding list can be found at:
http://msdn.microsoft.com/workshop/author/dhtml/referen
ce/charsets/charset4.asp


----------------------------------------------------------------------

>Comment By: Mark Hammond (mhammond)
Date: 2001-05-29 23:30

Message:
Logged In: YES 
user_id=14198

This looks good to me!  Assiging to MAL simply for 
comment.  Marc - if you have no objections and this sounds 
reasonable, assign back to me and I will check it in.

----------------------------------------------------------------------

Comment By: Brian Quinlan (bquinlan)
Date: 2001-05-29 23:23

Message:
Logged In: YES 
user_id=108973

The first patch (alias.patch) is incorrect and I'm not sure 
it the replacement (aliases.patch) is visible to anyone but 
me, so here is aliases.patch inline:

*** d:\Dev\python\dist\src\Lib\encodings\aliases.py	Wed 
Jun  7 02:12:30 2000
--- d:\Dev\python-dev\dist\src\Lib\encodings\aliases.py	Tue 
May 29 19:16:58 2001
***************
*** 59,64 ****
--- 59,69 ----
      'macroman': 'mac_roman',
      'macturkish': 'mac_turkish',
  
+     # Windows
+     'windows_1252': 'cp1252',
+     'windows_1254': 'cp1254',
+     'windows_1255': 'cp1255',
+     
      # MBCS
      'dbcs': 'mbcs',

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=423221&group_id=5470


From noreply@sourceforge.net  Wed May 30 10:16:31 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 30 May 2001 02:16:31 -0700
Subject: [Patches] [ python-Patches-428326 ] Timer class for threading
Message-ID: <E15525f-0003AG-00@usw-sf-web1.sourceforge.net>

Patches item #428326, was updated on 2001-05-29 08:20
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=428326&group_id=5470

Category: library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Itamar Shtull-Trauring (itamar)
Assigned to: Nobody/Anonymous (nobody)
Summary: Timer class for threading

Initial Comment:
The Timer class allows you to schedule an action to
happen at some time in the future, using a thread. For
example:

  def f():
      print "30 seconds have passed"

  t = Timer(30.0, f)
  t.start() # after 30 seconds f will be called

  try:  
      # .... other stuff
  except SystemExit:
      t.cancel() # cancel the timer since we are
shutting down


It allows passing arguments and keyword arguments to
the function that is called. It also allows
*cancelling* the timer. That is, if the timer is still
waiting, we can tell it to stop its operation.

Why should this be in the standard library?

1. Timers are a standard, useful programming idiom.

2.  It can be used as an example of how to:
     a. create subclasses of threading.Thread
     b. make threads that can be "stopped"


If this patch is approved I will then write
documentation. I'm not sure how to go about writing
tests for it.

----------------------------------------------------------------------

>Comment By: Itamar Shtull-Trauring (itamar)
Date: 2001-05-30 02:16

Message:
Logged In: YES 
user_id=32065

OK, I'm un-withdrawing this patch.  Just had to get things
straight with our lawyer. The patch is released under the
following license (the X11 license with 4 extra paragraphs
of disclaimers :):
http://www.zoteca.com/opensource/LICENSE.txt

----------------------------------------------------------------------

Comment By: Itamar Shtull-Trauring (itamar)
Date: 2001-05-29 09:45

Message:
Logged In: YES 
user_id=32065

I'm withdrawing this patch for a short period of time for
non-technical reasons, hopefully I can put it back soon.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=428326&group_id=5470


From noreply@sourceforge.net  Wed May 30 17:40:16 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 30 May 2001 09:40:16 -0700
Subject: [Patches] [ python-Patches-428326 ] Timer class for threading
Message-ID: <E155916-0007S0-00@usw-sf-web2.sourceforge.net>

Patches item #428326, was updated on 2001-05-29 08:20
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=428326&group_id=5470

Category: library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Itamar Shtull-Trauring (itamar)
Assigned to: Nobody/Anonymous (nobody)
Summary: Timer class for threading

Initial Comment:
The Timer class allows you to schedule an action to
happen at some time in the future, using a thread. For
example:

  def f():
      print "30 seconds have passed"

  t = Timer(30.0, f)
  t.start() # after 30 seconds f will be called

  try:  
      # .... other stuff
  except SystemExit:
      t.cancel() # cancel the timer since we are
shutting down


It allows passing arguments and keyword arguments to
the function that is called. It also allows
*cancelling* the timer. That is, if the timer is still
waiting, we can tell it to stop its operation.

Why should this be in the standard library?

1. Timers are a standard, useful programming idiom.

2.  It can be used as an example of how to:
     a. create subclasses of threading.Thread
     b. make threads that can be "stopped"


If this patch is approved I will then write
documentation. I'm not sure how to go about writing
tests for it.

----------------------------------------------------------------------

>Comment By: Itamar Shtull-Trauring (itamar)
Date: 2001-05-30 09:40

Message:
Logged In: YES 
user_id=32065

There was a licensing discussion on python-dev which no one
bothered to CC me on :). Yes, this can be relicensed under
the PSF license. 

I suggest someone write up some sort of guidelines for
submitted patches and improvement explain the whole
licensing and copyright issues.

----------------------------------------------------------------------

Comment By: Itamar Shtull-Trauring (itamar)
Date: 2001-05-30 02:16

Message:
Logged In: YES 
user_id=32065

OK, I'm un-withdrawing this patch.  Just had to get things
straight with our lawyer. The patch is released under the
following license (the X11 license with 4 extra paragraphs
of disclaimers :):
http://www.zoteca.com/opensource/LICENSE.txt

----------------------------------------------------------------------

Comment By: Itamar Shtull-Trauring (itamar)
Date: 2001-05-29 09:45

Message:
Logged In: YES 
user_id=32065

I'm withdrawing this patch for a short period of time for
non-technical reasons, hopefully I can put it back soon.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=428326&group_id=5470


From noreply@sourceforge.net  Wed May 30 18:34:22 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 30 May 2001 10:34:22 -0700
Subject: [Patches] [ python-Patches-401196 ] IPv6 patch against 2.0 CVS tree, as of 20001230
Message-ID: <E1559rS-00083n-00@usw-sf-web2.sourceforge.net>

Patches item #401196, was updated on 2000-08-16 05:53
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=401196&group_id=5470

Category: core (C code)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jun-ichiro itojun Hagino (itojun)
Assigned to: Nobody/Anonymous (nobody)
Summary: IPv6 patch against 2.0 CVS tree, as of 20001230

Initial Comment:
 

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-05-30 10:34

Message:
Logged In: NO 

i looked at python-dev email.  the proposal (split patches)
looks fine, but the exact example given in python-dev email
is not reasonable.  i cannot just send out configure.in
change separately from source code changes, period.  i can
split patches for *.py files separately though.

there's more important issue, which is, APi changes for
Socket class.  i really hoped to get some comment on that
part.  i really appreciate your comments.
i would like to propose that once we nailed down API
changes, integrate the patch into the tree.
with all #ifdef INET6 in place there should be no impact on
IPv4-only builds.

i have trouble tracking python development (i'm not a
sourceforge expert!), so forgive me for delays in patch
submissions.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-05-18 08:29

Message:
Logged In: YES 
user_id=6380

See
http://mail.python.org/pipermail/python-dev/2001-May/014889.html
for comments from MvL.

I'm unassigning this from Fred, he has nothing to do with
this.

----------------------------------------------------------------------

Comment By: Jun-ichiro itojun Hagino (itojun)
Date: 2001-02-26 02:24

Message:
Logged In: YES 
user_id=63767

about /usr/bin/test argument: does linux /usr/bin/test have
-d <dir> support?  if not, we may need to change
configure.in slightly.

you are correct that fallback getaddrinfo/getnameinfo.c was
missing in the patch.  sorry.  a question i need to ask is,
do we need to supply Python function Socket.getaddrinfo on
platforms that do not have getaddrinfo(3)?

HAVE_ADDRINFO is used in Include/addrinfo.h, which is also
missing in the patch set i have submitted.

i've put the missing files into
http://www.itojun.org/diary/20001230/missing.shar.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2001-02-23 23:58

Message:
After a shallow review of this patch, I found the following issues:

configure.in does not need to list both enable and disable options.
 
When running configure, I got the following error message on Linux
checking whether to enable ipv6... yes
checking ipv6 stack type... linux-glibc
./configure: test: too many arguments
using libc

The call to /usr/bin/test should be corrected; I could not find out which specific  invocation caused the problem.

HAVE_ADDRINFO is not used. Perhaps getaddrinfo.c/getnameinfo.c is missing in the patch?


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-01-04 07:51

Message:
A new patch is available.  I've changed the subject accordingly.

Due to upload size restrictions, the patch is now at

http://www.itojun.org/diary/20001230/python-2.0-v6-20001230.diff.gz

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2000-12-30 07:25

Message:
I got *many* rejects when trying to apply this patch to today's CVS tree. I recommend that patches for generated files (config.h.in, configure) are not included in the patch because they outdate too easily.
A number of changes in this patch have already been done by somebody else; others just don't fit into the current code anymore (perhaps due to indentation changes?).
Anyway, I'll mark the patch as out-of-date. Please let me know when you upload a new version.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2000-08-16 07:00

Message:
Postponed until Python 2.1 -- there's not enough time to review this and get it sufficiently tested on enough IPv6-connected platforms in time for 2.0, and we're already in feature freeze.  This should go into the tree very quickly once Python 2.0 has been released.

Assigned to myself to open it back up after Python 2.0.

----------------------------------------------------------------------

Comment By: Moshe Zadka (moshez)
Date: 2000-08-16 06:07

Message:
Assigned to Tim, since he's in charge of postponing
new features. I'm to timid to postpone it myself.

----------------------------------------------------------------------

Comment By: Jun-ichiro itojun Hagino (itojun)
Date: 2000-08-16 05:59

Message:
this is revised version of patch #101186 (now with my SourceForge accout...
i'm not familiar with the system here, so forgive my possible mistake).

1.6b1 patch applied mostly clean to 2.0.
It is confirmed that:
- 1.6b1 + IPv6 patch works fine on NetBSD 1.4.2 + KAME, and NetBSD 1.5
- 1.6b1 + IPv6 patch works fine on NetBSD 1.4.2 (NOT an IPv6 ready machine)
- 2.0 CVS tree + IPv6 patch works fine on NetBSD + KAME

forgot to attach the following into the diff - so i attach it (README.v6)
here as comment.  I have submitted the patch for 1.5.1, 1.5.2 and 1.6b1,
all hit a bad timing - bad luck.

contact: core@kame.net, or itojun@kame.net


---
IPv6-ready python 1.6
KAME Project
$KAME: README.v6,v 1.9 2000/08/15 02:40:38 itojun Exp $


This patchkit enables python 1.6 to perform AF_INET6 socket operations.
The only affected module is Modules/socketmodule.c.

Modules/socketmodule.c
	In most cases, IPv6 address can be placed where IPv4 address fits.

    sockaddr
	sockaddr tuple is formatted as follows:
	    IPv4: (host, port)
	    IPv6: socket class methods always generate
		    (host, port, flowinfo, scopeid).
		  socket class methods will accept 2, 3, or 4 tuple
		  (for backward compatibility).

	Compatibility warning: Some of the scripts assume that the sockaddr
	structure is 2 tuple, like:
	    host, port = sock.getpeername()
	this will fail if you are connected to IPv6 node.

    socket.getaddrinfo(host, port [, family, socktype, proto, flags])
	host: String or None
	port: String, Int or None
	family, socktype, proto, flags: Int, can be omitted

	Perform getaddrinfo(3).  Returns List of the following 5 tuple:
	    (family, socktype, proto, canonname, sockaddr)
	    family: Int
	    socktype: Int
	    proto: Int
	    canonname: String
	    sockaddr: sockaddr (see above)

	See Lib/httplib.py for typical usage on the client side.

    socket.getnameinfo(sockaddr, flags)
	sockaddr: sockaddr
	flags: Int

	Perform getnameinfo(3).  Returns the following 2 tuple:
	    host: String, numeric or hostname depending on flgags
	    port: String, numeric or portname depending on flgags

    socket.gethostbyname2(host, af)
	host: String
	af: Int

	Performs gethostbyname2(3).  Returns numeric address representation
	for "host".

    socket.gethostbyaddr(addr) (behavior change if IPv6 support is compiled in)
	addr: String

	Performs gethostbyaddr(3).  Returns string address representation for
	"addr".

	The function can take IPv6 numeric address as well.  This behavior
	is not problematical, because
	- if you pass numeric "addr" parameter, we can always identify address
	  family for it
	- return value is string address reprsentation, where IPv6 and IPv4
	  are not distinguishable.

     socket.bind(sa), socket.connect(sa) and others.
	(No behavior change, but be careful)

	See above for sockaddr format change.

	With Python "addr" portion of sockaddr (first element) can be string
	hostname.  When the string hostname resolved to numeric address, it
	will obey address family of the socket (which was specified when
	socket.socket() was called).
	If you give some string that does not give matching address family,
	you will get some error.
		s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
		# this is okay, if 'localhost' resolves to both IPv4/v6
		s.connect('localhost', 80)
		# this is not okay, of course
		s.connect('::1', 80)
		# this is not okay, as v6only.kame.net will not resolve to IPv4
		s.connect('v6only.kame.net', 80)

Lib/httplib.py
	IPv6 ready.  "host" in HTTP(host) will accept the following 3 forms:
		[host]:port
		host:port	there must be only single colon
		host
	This is to allow IPv6 numeric URL (http://[host]:port/) in documents.

	IMHO "host:port" parsing should be implemented in urllib.py, not here.

Lib/ftplib.py
	IPv6 ready.  This uses EPSV/EPRT on IPv6 ftp.  See RFC2428 for
	protocol details.

Lib/SocketServer.py
	IPv6 ready.  Wildcard bind on TCPServer, i.e. TCPServer(('', port)),
	will bind to wildcard socket on TCPServer.address_family.
	TCPServer.addresss_family is set to AF_INET by default, so ('', port)
	will usually bind AF_INET.

Lib/smtplib.py, Lib/telnetlib.py, Lib/poplib.py
	IPv6 ready.  Not much to say about protocol details - they just use
	TCP over IPv6.

configure
	Configure has extra option, --enable-ipv6 and --disable-ipv6.
	The option controls IPv6 support feature.

dynamic link issues in Modules/socketmodule.c
	Modules/socketmodule.c can be dynamically loaded only in the following
	situations:
	- getaddrinfo(3) and getnameinfo(3) are supplied by OS vendor in
	  libc, and libc is dynamic link library.
	- OS vendor is NOT supplying getaddrinfo(3) nor getnameinfo(3), and
	  You are configuring this package with --disable-ipv6.  In this case,
	  you'll be using missing/get{addr,name}info.c and they will refer to
	  gethostby{name,addr}.  gethostnameby{name,addr} can usually be found
	  in dynamic-linking libc.

	In other situations, such as the following, please link
	Modules/socketmodule.c into python itself.
	- getaddrinfo(3) and getnameinfo(3) are supplied by OS vendor, but
	  they are in statically linked library like libinet6.a.
	  (KAME falls into this category)

	python usually links Modules/socketmodule.c into python itself
	(due to its popularity) so there should be no problem.

restrictions
	- The patched tree will not use gethostbyname_r and other
	  thread-ready libraries.  Instead, it will use getaddrinfo() and
	  getnameinfo() throughout the operation.

todo
	- Patch bunch of library files in Lib/*.py.

compatibility issues with existing scripts
	If you disable IPv6 support (./configure --disable-ipv6), the
	patched code is mostly compatible with original Python
	(except files in "Lib" directory modified for dual stack support).

	User script may choke if:
	- IPv4/v6 dualstack libc is supplied, python is compiled for dual
	  stack, and script assumes some of IPv4-only behavior (especially
	  sockaddr)
	- IPv4/v6 dualstack libc is supplied, python is compiled for IPv4 only,
	  and script assumes some of IPv4-only behavior.
	  In this case, Python socket class itself does not support IPv6,
	  however, name resolution functions can return IPv6 names since
	  they use IPv6-ready libc functions!  I do not recommend this
	  configuration.
	- script assumes certain IPv4-only version behavior in Lib/*.py.

compilation
	If you use IPv6 features, it is assumed that you have working
	getaddrinfo() and getnameinfo() library functions.  We have noticed
	that some of IPv6 stack is shipped with broken getaddrinfo().  In
	such cases, use missing/get{addr,name}info.c instead (but then, you
	need to have working getipnodeby{name,addr}).

	If you compile this on IPv4-only machine without get{addr,name}info,
	missing/get{addr,name}info.c will be used.  They are from KAME IPv6
	distribution and is #ifdef'ed for IPv4 only support.  They are
	fairly complete implementation and you don't need to bother with
	bind 8.2 (bind 8.2 get{addr,name}info() has bugs).

	When compiling this kit on IPv6 node, you may need to specify some
	additional library paths or cpp defs. (like -linet6 or -DINET6)
	--enable-ipv6 will give you some warning, if the IPv6 stack is unknown
	to the "configure" script.  Currently, the following IPv6 stacks
	are officially supported (i.e. we've checked that the package works
	well):
	- KAME IPv6 stack, http://www.kame.net/

References
	RFC2553, for getaddrinfo(3) and getnameinfo(3).

Author contacts
	http://www.kame.net/
	mailto:core@kame.net


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=401196&group_id=5470


From noreply@sourceforge.net  Wed May 30 20:59:07 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 30 May 2001 12:59:07 -0700
Subject: [Patches] [ python-Patches-423221 ] Add a few Windows encoding aliases
Message-ID: <E155C7X-0001wK-00@usw-sf-web3.sourceforge.net>

Patches item #423221, was updated on 2001-05-10 21:14
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=423221&group_id=5470

Category: library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Brian Quinlan (bquinlan)
Assigned to: M.-A. Lemburg (lemburg)
Summary: Add a few Windows encoding aliases

Initial Comment:
This patch adds aliases for some of the common Windows 
encodings. Windows-1252 is particularly useful because 
it is the default encoding used by Visual Studio .NET 
projects. 

Microsoft's complete encoding list can be found at:
http://msdn.microsoft.com/workshop/author/dhtml/referen
ce/charsets/charset4.asp


----------------------------------------------------------------------

>Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-30 12:59

Message:
Logged In: YES 
user_id=38388

The link you gave doesn't work for me, but the aliases look
reasonable... aren't there more (Windows does have far more
code pages than the few you added) ?

In any case, go ahead and check them in :-)

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2001-05-29 23:30

Message:
Logged In: YES 
user_id=14198

This looks good to me!  Assiging to MAL simply for 
comment.  Marc - if you have no objections and this sounds 
reasonable, assign back to me and I will check it in.

----------------------------------------------------------------------

Comment By: Brian Quinlan (bquinlan)
Date: 2001-05-29 23:23

Message:
Logged In: YES 
user_id=108973

The first patch (alias.patch) is incorrect and I'm not sure 
it the replacement (aliases.patch) is visible to anyone but 
me, so here is aliases.patch inline:

*** d:\Dev\python\dist\src\Lib\encodings\aliases.py	Wed 
Jun  7 02:12:30 2000
--- d:\Dev\python-dev\dist\src\Lib\encodings\aliases.py	Tue 
May 29 19:16:58 2001
***************
*** 59,64 ****
--- 59,69 ----
      'macroman': 'mac_roman',
      'macturkish': 'mac_turkish',
  
+     # Windows
+     'windows_1252': 'cp1252',
+     'windows_1254': 'cp1254',
+     'windows_1255': 'cp1255',
+     
      # MBCS
      'dbcs': 'mbcs',

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=423221&group_id=5470


From noreply@sourceforge.net  Wed May 30 22:04:08 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 30 May 2001 14:04:08 -0700
Subject: [Patches] [ python-Patches-423221 ] Add a few Windows encoding aliases
Message-ID: <E155D8S-0001tY-00@usw-sf-web2.sourceforge.net>

Patches item #423221, was updated on 2001-05-10 21:14
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=423221&group_id=5470

Category: library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Brian Quinlan (bquinlan)
Assigned to: M.-A. Lemburg (lemburg)
Summary: Add a few Windows encoding aliases

Initial Comment:
This patch adds aliases for some of the common Windows 
encodings. Windows-1252 is particularly useful because 
it is the default encoding used by Visual Studio .NET 
projects. 

Microsoft's complete encoding list can be found at:
http://msdn.microsoft.com/workshop/author/dhtml/referen
ce/charsets/charset4.asp


----------------------------------------------------------------------

>Comment By: Brian Quinlan (bquinlan)
Date: 2001-05-30 14:04

Message:
Logged In: YES 
user_id=108973

Yeah, there are tonnes. But after my initial mistake, I 
don't want to add any without carefully checking that the 
encodings that I am aliasing are exactly identical.

I'll probably add some more later but Windows-1252 is 
probably the most immediately useful.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-30 12:59

Message:
Logged In: YES 
user_id=38388

The link you gave doesn't work for me, but the aliases look
reasonable... aren't there more (Windows does have far more
code pages than the few you added) ?

In any case, go ahead and check them in :-)

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2001-05-29 23:30

Message:
Logged In: YES 
user_id=14198

This looks good to me!  Assiging to MAL simply for 
comment.  Marc - if you have no objections and this sounds 
reasonable, assign back to me and I will check it in.

----------------------------------------------------------------------

Comment By: Brian Quinlan (bquinlan)
Date: 2001-05-29 23:23

Message:
Logged In: YES 
user_id=108973

The first patch (alias.patch) is incorrect and I'm not sure 
it the replacement (aliases.patch) is visible to anyone but 
me, so here is aliases.patch inline:

*** d:\Dev\python\dist\src\Lib\encodings\aliases.py	Wed 
Jun  7 02:12:30 2000
--- d:\Dev\python-dev\dist\src\Lib\encodings\aliases.py	Tue 
May 29 19:16:58 2001
***************
*** 59,64 ****
--- 59,69 ----
      'macroman': 'mac_roman',
      'macturkish': 'mac_turkish',
  
+     # Windows
+     'windows_1252': 'cp1252',
+     'windows_1254': 'cp1254',
+     'windows_1255': 'cp1255',
+     
      # MBCS
      'dbcs': 'mbcs',

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=423221&group_id=5470


From noreply@sourceforge.net  Thu May 31 15:27:50 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 31 May 2001 07:27:50 -0700
Subject: [Patches] [ python-Patches-429024 ] Deal with some unary ops at compile time
Message-ID: <E155TQU-0006Zb-00@usw-sf-web3.sourceforge.net>

Patches item #429024, was updated on 2001-05-31 07:27
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=429024&group_id=5470

Category: Parser/Compiler
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: Jeremy Hylton (jhylton)
Summary: Deal with some unary ops at compile time

Initial Comment:
This patch makes unary + and - operations with numeric
literals compile to a constant reference instead of a
constant reference and UNARY_POSITIVE or UNARY_NEGATIVE
opcode.  This could be extended to support UNARY_INVERT
as well, but that would be a little more complicated.

Folding unary + only affects one case in the regression
test, but folding the - affects 817 places (on a Linux
system with pretty much everything enabled).  I don't
know that this makes much difference at runtime, but
certainly reduces the number of opcodes evaluated.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=429024&group_id=5470


From noreply@sourceforge.net  Thu May 31 21:29:39 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 31 May 2001 13:29:39 -0700
Subject: [Patches] [ python-Patches-429136 ] BROWSER fix for webbrowser.py
Message-ID: <E155Z4d-0002sH-00@usw-sf-web3.sourceforge.net>

Patches item #429136, was updated on 2001-05-31 13:29
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=429136&group_id=5470

Category: library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Nobody/Anonymous (nobody)
Summary: BROWSER fix for webbrowser.py

Initial Comment:
webbrowser.py currently assumes the BROWSER environment
variable was set by the user who will take care of
registering that browser.  In the case of
Gnome+Mandrake 8.0 (at least), this is not the case. 
The attached patch attempts to register any browsers
found in BROWSER that aren't in the _browser dict
already.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=429136&group_id=5470


From noreply@sourceforge.net  Thu May 31 23:26:33 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 31 May 2001 15:26:33 -0700
Subject: [Patches] [ python-Patches-429171 ] sgmllib - leading spaces in declaration
Message-ID: <E155atl-0004O5-00@usw-sf-web3.sourceforge.net>

Patches item #429171, was updated on 2001-05-31 15:26
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=429171&group_id=5470

Category: library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Doug Fort (dougfort)
Assigned to: Nobody/Anonymous (nobody)
Summary: sgmllib - leading spaces in declaration

Initial Comment:
Some sites sloppily leave a space in their doctype
declaration:  i.e. <! doctype...>. The Python 2.1 sgml
parser raises an exception for this.  This patch
modifies sgmllib.py to allow leading whitespace in the
declaration.  It also adds a little information to the
exception message.



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=429171&group_id=5470