From noreply@sourceforge.net  Sat Jul  1 13:18:16 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 1 Jul 2000 05:18:16 -0700
Subject: [Patches] [Patch #100706] minidom __repr__ returns Unicode strings
Message-ID: <200007011218.FAA19261@bush.i.sourceforge.net>

Patch #100706 has been updated. 
Visit SourceForge.net for more info.

http://sourceforge.net/patch/?func=detailpatch&patch_id=100706&group_id=5470


From noreply@sourceforge.net  Mon Jul  3 15:50:40 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 3 Jul 2000 07:50:40 -0700
Subject: [Patches] [Patch #100719] Use '#!/usr/bin/env python' in scripts
Message-ID: <200007031450.HAA01841@bush.i.sourceforge.net>

Patch #100719 has been updated. 
Visit SourceForge.net for more info.

http://sourceforge.net/patch/?func=detailpatch&patch_id=100719&group_id=5470


From noreply@sourceforge.net  Tue Jul  4 01:11:31 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 3 Jul 2000 17:11:31 -0700
Subject: [Patches] [Patch #100723] make unicode_compare a UTF-16 code point order comparison fu
Message-ID: <200007040011.RAA18430@bush.i.sourceforge.net>

Patch #100723 has been updated. 
Visit SourceForge.net for more info.

http://sourceforge.net/patch/?func=detailpatch&patch_id=100723&group_id=5470


From mal@lemburg.com  Tue Jul  4 10:52:49 2000
From: mal@lemburg.com (M.-A. Lemburg)
Date: Tue, 04 Jul 2000 11:52:49 +0200
Subject: [Patches] [Patch #100723] make unicode_compare a UTF-16 code point
 order comparison fu
References: <200007040011.RAA18430@bush.i.sourceforge.net>
Message-ID: <3961B3F1.339E551@lemburg.com>

noreply@sourceforge.net wrote:
> 
> Patch #100723 has been updated.
> Visit SourceForge.net for more info.
> 
> http://sourceforge.net/patch/?func=detailpatch&patch_id=100723&group_id=5470
> 

Bill,

I've checked in the patch (slightly edited). Could you also post
a patch to the test_unicode.py script which tests the new
feature ?

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


From Moshe Zadka <moshez@math.huji.ac.il>  Wed Jul  5 07:38:13 2000
From: Moshe Zadka <moshez@math.huji.ac.il> (Moshe Zadka)
Date: Wed, 5 Jul 2000 09:38:13 +0300 (IDT)
Subject: [Patches] Patch 100718 -- LinuxThreads vs. Pth
Message-ID: <Pine.GSO.4.10.10007050934240.109-100000@sundial>

I'm +1 on this -- LinuxThreads is more-or-less Posix compliant, and is
based on Kernel level support. It seems much closer to the norm in the
Linux world then Pth.

(Question to PythonLabs team: any hope of getting the patch contents in
e-mail? It's much easier to comment that way)

--
Moshe Zadka <moshez@math.huji.ac.il>
There is no GOD but Python, and HTTP is its prophet.



From Moshe Zadka <moshez@math.huji.ac.il>  Wed Jul  5 07:43:32 2000
From: Moshe Zadka <moshez@math.huji.ac.il> (Moshe Zadka)
Date: Wed, 5 Jul 2000 09:43:32 +0300 (IDT)
Subject: [Patches] Patch 100730 -- Change creation of new instances in UserString/UserList
Message-ID: <Pine.GSO.4.10.10007050940170.109-100000@sundial>

It's basically a refactoring of the 

return self.__class__(...)

ugliness into a single (overridable) method.

I'm +0 on that.

--
Moshe Zadka <moshez@math.huji.ac.il>
There is no GOD but Python, and HTTP is its prophet.



From Fredrik Lundh" <effbot@telia.com  Wed Jul  5 08:53:18 2000
From: Fredrik Lundh" <effbot@telia.com (Fredrik Lundh)
Date: Wed, 5 Jul 2000 09:53:18 +0200
Subject: [Patches] Patch 100730 -- Change creation of new instances in UserString/UserList
References: <Pine.GSO.4.10.10007050940170.109-100000@sundial>
Message-ID: <002301bfe656$18571780$f2a6b5d4@hagrid>

moshe wrote:


> It's basically a refactoring of the=20
>=20
> return self.__class__(...)
>=20
> ugliness into a single (overridable) method.
>=20
> I'm +0 on that.

-0: what's the point?  why would anyone create userlist sub-
classes where slicing etc returns objects of *another* class?

</F>



From gstein@lyra.org  Wed Jul  5 08:52:09 2000
From: gstein@lyra.org (Greg Stein)
Date: Wed, 5 Jul 2000 00:52:09 -0700
Subject: [Patches] Patch 100718 -- LinuxThreads vs. Pth
In-Reply-To: <Pine.GSO.4.10.10007050934240.109-100000@sundial>; from moshez@math.huji.ac.il on Wed, Jul 05, 2000 at 09:38:13AM +0300
References: <Pine.GSO.4.10.10007050934240.109-100000@sundial>
Message-ID: <20000705005209.J29590@lyra.org>

On Wed, Jul 05, 2000 at 09:38:13AM +0300, Moshe Zadka wrote:
> 
> I'm +1 on this -- LinuxThreads is more-or-less Posix compliant, and is
> based on Kernel level support. It seems much closer to the norm in the
> Linux world then Pth.

This patch is a huge +1. We should *never* prefer Pth over LinuxThreads.
Never. Ever. Hell... there isn't really "LinuxThreads" any more -- it is
part of glibc. We really shouldn't take an external package over the core
C library.

Pth is a user-mode thread package. That should not be used by Python unless
somebody specifically requests it.

Gah. How did that Pth get preferred installation...

I'm off to fix this sucker. Big time.

There is a separate problem for how somebody can override the selection
mechanism. But we're talking defaults here, and we should select the proper
default.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/


From Moshe Zadka <moshez@math.huji.ac.il>  Wed Jul  5 08:58:53 2000
From: Moshe Zadka <moshez@math.huji.ac.il> (Moshe Zadka)
Date: Wed, 5 Jul 2000 10:58:53 +0300 (IDT)
Subject: [Patches] Patch 100730 -- Change creation of new instances in
 UserString/UserList
In-Reply-To: <002301bfe656$18571780$f2a6b5d4@hagrid>
Message-ID: <Pine.GSO.4.10.10007051056220.109-100000@sundial>

On Wed, 5 Jul 2000, Fredrik Lundh wrote:

[Moshe]
> It's basically a refactoring of the 
> 
> return self.__class__(...)
> 
> ugliness into a single (overridable) method.
> 
> I'm +0 on that.

[Fredrik]
> -0: what's the point?  why would anyone create userlist sub-
> classes where slicing etc returns objects of *another* class?

Fredrik, one of us doesn't understand the other, but I'm not sure who. 
The patch does *not* change what happens to derived classes, *unless* they
override the _newinst() method. What is the problem with that?

--
Moshe Zadka <moshez@math.huji.ac.il>
There is no GOD but Python, and HTTP is its prophet.



From thomas@xs4all.net  Wed Jul  5 09:12:16 2000
From: thomas@xs4all.net (Thomas Wouters)
Date: Wed, 5 Jul 2000 10:12:16 +0200
Subject: [Patches] Patch 100730 -- Change creation of new instances in UserString/UserList
In-Reply-To: <002301bfe656$18571780$f2a6b5d4@hagrid>; from effbot@telia.com on Wed, Jul 05, 2000 at 09:53:18AM +0200
References: <Pine.GSO.4.10.10007050940170.109-100000@sundial> <002301bfe656$18571780$f2a6b5d4@hagrid>
Message-ID: <20000705101216.G13469@xs4all.nl>

On Wed, Jul 05, 2000 at 09:53:18AM +0200, Fredrik Lundh wrote:
> moshe wrote:
> > It's basically a refactoring of the 
> > 
> > return self.__class__(...)
> > 
> > ugliness into a single (overridable) method.
> > 
> > I'm +0 on that.

> -0: what's the point?  why would anyone create userlist sub-
> classes where slicing etc returns objects of *another* class?

The point was that someone (named Normal Shelley) complained on the
python-list that UserList used this 'trick' to create a new instance of the
subclass, but his subclass had extra, required arguments. He suggested using
copy.copy() to create a new instance, which I think is silly ;-P but he does
have a point that the 'self.__class__' thing is spread out all over
UserList, and is not easily overridable.

The python-list archive is still down, so I can't point there, but you can
probably find the thread on deja. It was a short 2-man discussion on c.l.py,
between Norman Shelley <Norman_Shelley-RRDN60@email.sps.mot.com> and myself,
subject 'UserDict and UserList issue (bug?_'. I'm not particularly + on this
patch myself, but I promised to try and send it in ;) (in private email, I
believe)

By the way, did Moshe's original reply to this go to
twouters@users.sourceforge.net too ? I dont seem to have gotten it. Please
leave me in the CC, though, the patches archive is down too ;-P

-- 
Thomas Wouters <thomas@xs4all.net>

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


From Fredrik Lundh" <effbot@telia.com  Wed Jul  5 09:18:48 2000
From: Fredrik Lundh" <effbot@telia.com (Fredrik Lundh)
Date: Wed, 5 Jul 2000 10:18:48 +0200
Subject: [Patches] Patch 100730 -- Change creation of new instances inUserString/UserList
References: <Pine.GSO.4.10.10007051056220.109-100000@sundial>
Message-ID: <001701bfe659$a64cebc0$f2a6b5d4@hagrid>

moshe wrote:

> [Fredrik]
> > -0: what's the point?  why would anyone create userlist sub-
> > classes where slicing etc returns objects of *another* class?
>=20
> Fredrik, one of us doesn't understand the other, but I'm not sure who. =

> The patch does *not* change what happens to derived classes, *unless* =
they
> override the _newinst() method. What is the problem with that?

so why should anyone ever want to override the _newinst() method?
show me a use case or two...

this looks like yet another attempt of trying to turn the usertype
classes into something they're not.  (they're subclassable versions
of the built-in types, not generic containers with type-like inter-
faces).

when the type/class difference is removed, these classes should
be removed.  please don't add things to them that we don't want
to have in the core types.

</F>



From noreply@sourceforge.net  Thu Jul  6 13:31:53 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 6 Jul 2000 05:31:53 -0700
Subject: [Patches] [Patch #100745] Fix PR #384, fixes UTF-8 en/decode
Message-ID: <200007061231.FAA23393@bush.i.sourceforge.net>

Patch #100745 has been updated. 
Visit SourceForge.net for more info.

http://sourceforge.net/patch/?func=detailpatch&patch_id=100745&group_id=5470


From Moshe Zadka <moshez@math.huji.ac.il>  Thu Jul  6 20:00:01 2000
From: Moshe Zadka <moshez@math.huji.ac.il> (Moshe Zadka)
Date: Thu, 6 Jul 2000 22:00:01 +0300 (IDT)
Subject: [Patches] [Patch #100745] Fix PR #384, fixes UTF-8 en/decode
In-Reply-To: <200007061231.FAA23393@bush.i.sourceforge.net>
Message-ID: <Pine.GSO.4.10.10007062157470.27116-100000@sundial>

On Thu, 6 Jul 2000 noreply@sourceforge.net wrote:

> Patch #100745 has been updated. 
> Visit SourceForge.net for more info.
> 
> http://sourceforge.net/patch/?func=detailpatch&patch_id=100745&group_id=5470

-1: Since when have we stopped supporting machines without 4-byte integral
types? Or even non-standard 4 byte integral types? This looks extremely
dangerous.

(Can we have a standing -0 on inserting #error into Python, which can of
course be offsetted by having extraordinary code)



From rassilon@list.org  Thu Jul  6 20:51:29 2000
From: rassilon@list.org (Bill Tutt)
Date: Thu, 6 Jul 2000 12:51:29 -0700 (PDT)
Subject: [Patches] [Patch #100745] Fix PR #384, fixes UTF-8 en/decode
In-Reply-To: <Pine.GSO.4.10.10007062157470.27116-100000@sundial>
Message-ID: <Pine.LNX.3.95.1000706124012.10464A-100000@lima.mudlib.org>


On Thu, 6 Jul 2000, Moshe Zadka wrote:

> On Thu, 6 Jul 2000 noreply@sourceforge.net wrote:
> 
> > Patch #100745 has been updated. 
> > Visit SourceForge.net for more info.
> > 
> > http://sourceforge.net/patch/?func=detailpatch&patch_id=100745&group_id=5470
> 
> -1: Since when have we stopped supporting machines without 4-byte integral
> types? Or even non-standard 4 byte integral types? This looks extremely
> dangerous.
> 
> (Can we have a standing -0 on inserting #error into Python, which can of
> course be offsetted by having extraordinary code)
> 

Code currently in unicodeobject.c needs to do 32-bit arithmetic in 
order to work. Additionally, UCS-4 characters (aka UTF-16 surrogate
characters) require 32 bits to represent the true unicode code point of a
surrogate pair.

Having the typedef, and the #error are much better than
what is currently in CVS. (unsigned int)

This code should work for the PC 16-bit config in PC\config.h since
unsigned long is 32 bits there.

Are there any other platforms that this might impact that need all of the
core python platform installed on them? (i.e. current Palm, and CE
platforms probably don't qualify) The unicode supports needs too much
ancillary room for its metadata to make it effective in those kinds of
environments.

Just wanting cool unicode support in Python,
Bill




From mal@lemburg.com  Thu Jul  6 21:23:12 2000
From: mal@lemburg.com (M.-A. Lemburg)
Date: Thu, 06 Jul 2000 22:23:12 +0200
Subject: [Patches] [Patch #100745] Fix PR #384, fixes UTF-8 en/decode
References: <Pine.LNX.3.95.1000706124012.10464A-100000@lima.mudlib.org>
Message-ID: <3964EAB0.BC8EC39E@lemburg.com>

Bill Tutt wrote:
> 
> On Thu, 6 Jul 2000, Moshe Zadka wrote:
> 
> > On Thu, 6 Jul 2000 noreply@sourceforge.net wrote:
> >
> > > Patch #100745 has been updated.
> > > Visit SourceForge.net for more info.
> > >
> > > http://sourceforge.net/patch/?func=detailpatch&patch_id=100745&group_id=5470
> >
> > -1: Since when have we stopped supporting machines without 4-byte integral
> > types? Or even non-standard 4 byte integral types? This looks extremely
> > dangerous.
> >
> > (Can we have a standing -0 on inserting #error into Python, which can of
> > course be offsetted by having extraordinary code)
> >
> 
> Code currently in unicodeobject.c needs to do 32-bit arithmetic in
> order to work. 

Just fixed... it doesn't use int or short anymore, so it should
basically work on all platforms now.

> Additionally, UCS-4 characters (aka UTF-16 surrogate
> characters) require 32 bits to represent the true unicode code point of a
> surrogate pair.
> 
> Having the typedef, and the #error are much better than
> what is currently in CVS. (unsigned int)

True, but now you're competing against 'unsigned long' ;-)
 
> This code should work for the PC 16-bit config in PC\config.h since
> unsigned long is 32 bits there.
> 
> Are there any other platforms that this might impact that need all of the
> core python platform installed on them? (i.e. current Palm, and CE
> platforms probably don't qualify) The unicode supports needs too much
> ancillary room for its metadata to make it effective in those kinds of
> environments.
> 
> Just wanting cool unicode support in Python,

Who doesn't ;-) ?

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


From noreply@sourceforge.net  Fri Jul  7 04:09:50 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 6 Jul 2000 20:09:50 -0700
Subject: [Patches] [Patch #100752] Make atoi work for negative bases, a useful generalization
Message-ID: <200007070309.UAA12927@bush.i.sourceforge.net>

Patch #100752 has been updated. 
Visit SourceForge.net for more info.

http://sourceforge.net/patch/?func=detailpatch&patch_id=100752&group_id=5470


From Moshe Zadka <moshez@math.huji.ac.il>  Fri Jul  7 13:55:33 2000
From: Moshe Zadka <moshez@math.huji.ac.il> (Moshe Zadka)
Date: Fri, 7 Jul 2000 15:55:33 +0300 (IDT)
Subject: [Patches] [Patch #100752] Make atoi work for negative bases, a
 useful generalization
In-Reply-To: <200007070309.UAA12927@bush.i.sourceforge.net>
Message-ID: <Pine.GSO.4.10.10007071553290.7615-100000@sundial>

On Thu, 6 Jul 2000 noreply@sourceforge.net wrote:

> Patch #100752 has been updated. 

I'm -0. I haven't yet seen a single place to use such a thing, and it's
certainly weird enough. Aside from corner cases, 

int(s, x) == -int(s, -x)

So the functionality is there. 

However, it's certainly a welcome change to change the documentation and
add test cases....

--
Moshe Zadka <moshez@math.huji.ac.il>
There is no GOD but Python, and HTTP is its prophet.



From noreply@sourceforge.net  Sat Jul  8 13:50:57 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 8 Jul 2000 05:50:57 -0700
Subject: [Patches] [Patch #100764] fix to make os.popen work under pythonw.exe
Message-ID: <200007081250.FAA03606@delerium.i.sourceforge.net>

Patch #100764 has been updated. 
Visit SourceForge.net for more info.

http://sourceforge.net/patch/?func=detailpatch&patch_id=100764&group_id=5470


From noreply@sourceforge.net  Sat Jul  8 20:04:21 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 8 Jul 2000 12:04:21 -0700
Subject: [Patches] [Patch #100765] proposed changes to the locale.py interface
Message-ID: <200007081904.MAA13574@delerium.i.sourceforge.net>

Patch #100765 has been updated. 
Visit SourceForge.net for more info.

http://sourceforge.net/patch/?func=detailpatch&patch_id=100765&group_id=5470


From noreply@sourceforge.net  Mon Jul 10 08:47:27 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 10 Jul 2000 00:47:27 -0700
Subject: [Patches] [Patch #100831] correcting documentaion for in and not in
Message-ID: <200007100747.AAA10874@delerium.i.sourceforge.net>

Patch #100831 has been updated. 
Visit SourceForge.net for more info.

http://sourceforge.net/patch/?func=detailpatch&patch_id=100831&group_id=5470


From Moshe Zadka <moshez@math.huji.ac.il>  Mon Jul 10 08:51:44 2000
From: Moshe Zadka <moshez@math.huji.ac.il> (Moshe Zadka)
Date: Mon, 10 Jul 2000 10:51:44 +0300 (IDT)
Subject: [Patches] [Patch #100831] correcting documentaion for in and
 not in
In-Reply-To: <200007100747.AAA10874@delerium.i.sourceforge.net>
Message-ID: <Pine.GSO.4.10.10007101050441.15573-100000@sundial>

On Mon, 10 Jul 2000 noreply@sourceforge.net wrote:

> Patch #100831 has been updated. 
> Visit SourceForge.net for more info.
> 
> http://sourceforge.net/patch/?func=detailpatch&patch_id=100831&group_id=5470
> 

This patch needs to be assigned to Fred (duh!)
--
Moshe Zadka <moshez@math.huji.ac.il>
There is no GOD but Python, and HTTP is its prophet.



From noreply@sourceforge.net  Mon Jul 10 13:38:44 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 10 Jul 2000 05:38:44 -0700
Subject: [Patches] [Patch #100836] Trivial fix to stop a compiler warning.
Message-ID: <200007101238.FAA19516@delerium.i.sourceforge.net>

Patch #100836 has been updated. 
Visit SourceForge.net for more info.

http://sourceforge.net/patch/?func=detailpatch&patch_id=100836&group_id=5470


From Moshe Zadka <moshez@math.huji.ac.il>  Mon Jul 10 15:32:52 2000
From: Moshe Zadka <moshez@math.huji.ac.il> (Moshe Zadka)
Date: Mon, 10 Jul 2000 17:32:52 +0300 (IDT)
Subject: [Patches] [Patch #100836] Trivial fix to stop a compiler warning.
In-Reply-To: <200007101238.FAA19516@delerium.i.sourceforge.net>
Message-ID: <Pine.GSO.4.10.10007101731410.15573-100000@sundial>

On Mon, 10 Jul 2000 noreply@sourceforge.net wrote:

> Patch #100836 has been updated. 
> Visit SourceForge.net for more info.

I'm -0: you're casting away the warning, when it might actually mean
something
--
Moshe Zadka <moshez@math.huji.ac.il>
There is no GOD but Python, and HTTP is its prophet.
http://advogato.org/person/moshez



From alex_c@MIT.EDU  Mon Jul 10 15:38:59 2000
From: alex_c@MIT.EDU (Alex Coventry)
Date: Mon, 10 Jul 2000 10:38:59 -0400 (EDT)
Subject: [Patches] [Patch #100836] Trivial fix to stop a compiler warning.
In-Reply-To: <Pine.GSO.4.10.10007101731410.15573-100000@sundial> (message from
 Moshe Zadka on Mon, 10 Jul 2000 17:32:52 +0300 (IDT))
References: <Pine.GSO.4.10.10007101731410.15573-100000@sundial>
Message-ID: <200007101438.KAA76251@w20-575-116.mit.edu>

Yeah, I think it does mean something: the problem is that the signature
for chown is int chown(const char *path, uid_t owner, gid_t group), but
the uid_t and gid_t types are compatible with int's, as far as I can
tell.

The alternative would be to change the signature for the function
pointer accepted by posix_strintint.  Since posix_strintint is only
called where I am doing the cast, that might be the better way to go. 

Alex.


From Moshe Zadka <moshez@math.huji.ac.il>  Mon Jul 10 15:40:05 2000
From: Moshe Zadka <moshez@math.huji.ac.il> (Moshe Zadka)
Date: Mon, 10 Jul 2000 17:40:05 +0300 (IDT)
Subject: [Patches] [Patch #100836] Trivial fix to stop a compiler warning.
In-Reply-To: <200007101438.KAA76251@w20-575-116.mit.edu>
Message-ID: <Pine.GSO.4.10.10007101739290.15573-100000@sundial>

On Mon, 10 Jul 2000, Alex Coventry wrote:

> 
> Yeah, I think it does mean something: the problem is that the signature
> for chown is int chown(const char *path, uid_t owner, gid_t group), but
> the uid_t and gid_t types are compatible with int's, as far as I can
> tell.
> 
> The alternative would be to change the signature for the function
> pointer accepted by posix_strintint.  Since posix_strintint is only
> called where I am doing the cast, that might be the better way to go. 

Or perhaps lose posix_strintint completely?

--
Moshe Zadka <moshez@math.huji.ac.il>
There is no GOD but Python, and HTTP is its prophet.
http://advogato.org/person/moshez



From guido@beopen.com  Mon Jul 10 16:44:02 2000
From: guido@beopen.com (Guido van Rossum)
Date: Mon, 10 Jul 2000 10:44:02 -0500
Subject: [Patches] [Patch #100836] Trivial fix to stop a compiler warning.
In-Reply-To: Your message of "Mon, 10 Jul 2000 17:40:05 +0300."
 <Pine.GSO.4.10.10007101739290.15573-100000@sundial>
References: <Pine.GSO.4.10.10007101739290.15573-100000@sundial>
Message-ID: <200007101544.KAA26009@cj20424-a.reston1.va.home.com>

> Or perhaps lose posix_strintint completely?

Yes, /F will do this.  Focus on something else please! :-)

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


From noreply@sourceforge.net  Tue Jul 11 11:37:53 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 11 Jul 2000 03:37:53 -0700
Subject: [Patches] [Patch #100851] traceback.py, with unicode exceptions
Message-ID: <200007111037.DAA25505@bush.i.sourceforge.net>

Patch #100851 has been updated. 
Visit SourceForge.net for more info.

http://sourceforge.net/patch/?func=detailpatch&patch_id=100851&group_id=5470


From noreply@sourceforge.net  Tue Jul 11 19:45:34 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 11 Jul 2000 11:45:34 -0700
Subject: [Patches] [Patch #100857] fix pointer mismatch warnings in socketmodule.c (Jul 12)
Message-ID: <200007111845.LAA11437@delerium.i.sourceforge.net>

Patch #100857 has been updated. 
Visit SourceForge.net for more info.

http://sourceforge.net/patch/?func=detailpatch&patch_id=100857&group_id=5470


From Moshe Zadka <moshez@math.huji.ac.il>  Wed Jul 12 07:12:29 2000
From: Moshe Zadka <moshez@math.huji.ac.il> (Moshe Zadka)
Date: Wed, 12 Jul 2000 09:12:29 +0300 (IDT)
Subject: [Patches] Patch 100858 -- add seteuid, setegid
Message-ID: <Pine.GSO.4.10.10007120910080.15424-100000@sundial>

I'm +1 on that. No reason Python programs should not be able to play
around with the whole mess of UNIX permissions.

(One question though: does configure gives those HAVE_SETEUID etc.)

--
Moshe Zadka <moshez@math.huji.ac.il>
There is no GOD but Python, and HTTP is its prophet.
http://advogato.org/person/moshez



From noreply@sourceforge.net  Wed Jul 12 10:01:04 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 12 Jul 2000 02:01:04 -0700
Subject: [Patches] [Patch #100868] refactoring of the code in shutil.copyfile
Message-ID: <200007120901.CAA03942@delerium.i.sourceforge.net>

Patch #100868 has been updated. 
Visit SourceForge.net for more info.

http://sourceforge.net/patch/?func=detailpatch&patch_id=100868&group_id=5470


From noreply@sourceforge.net  Wed Jul 12 10:43:12 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 12 Jul 2000 02:43:12 -0700
Subject: [Patches] [Patch #100869] exceptions in _PyImport_Inittab
Message-ID: <200007120943.CAA05078@delerium.i.sourceforge.net>

Patch #100869 has been updated. 
Visit SourceForge.net for more info.

http://sourceforge.net/patch/?func=detailpatch&patch_id=100869&group_id=5470


From noreply@sourceforge.net  Wed Jul 12 11:10:38 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 12 Jul 2000 03:10:38 -0700
Subject: [Patches] [Patch #100871] document new method in shutil (copyfileobj)
Message-ID: <200007121010.DAA05915@delerium.i.sourceforge.net>

Patch #100871 has been updated. 
Visit SourceForge.net for more info.

http://sourceforge.net/patch/?func=detailpatch&patch_id=100871&group_id=5470


From gstein@lyra.org  Wed Jul 12 11:39:51 2000
From: gstein@lyra.org (Greg Stein)
Date: Wed, 12 Jul 2000 03:39:51 -0700
Subject: [Patches] [Patch #100871] document new method in shutil (copyfileobj)
In-Reply-To: <200007121010.DAA05915@delerium.i.sourceforge.net>; from noreply@sourceforge.net on Wed, Jul 12, 2000 at 03:10:38AM -0700
References: <200007121010.DAA05915@delerium.i.sourceforge.net>
Message-ID: <20000712033951.A29590@lyra.org>

On Wed, Jul 12, 2000 at 03:10:38AM -0700, noreply@sourceforge.net wrote:
> Patch #100871 has been updated. 
> Visit SourceForge.net for more info.
> 
> http://sourceforge.net/patch/?func=detailpatch&patch_id=100871&group_id=5470

I don't understand the comment about negative values. I certainly don't see
that from the code.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/


From Moshe Zadka <moshez@math.huji.ac.il>  Wed Jul 12 11:40:11 2000
From: Moshe Zadka <moshez@math.huji.ac.il> (Moshe Zadka)
Date: Wed, 12 Jul 2000 13:40:11 +0300 (IDT)
Subject: [Patches] [Patch #100871] document new method in shutil
 (copyfileobj)
In-Reply-To: <20000712033951.A29590@lyra.org>
Message-ID: <Pine.GSO.4.10.10007121338350.15424-100000@sundial>

On Wed, 12 Jul 2000, Greg Stein wrote:

> On Wed, Jul 12, 2000 at 03:10:38AM -0700, noreply@sourceforge.net wrote:
> > Patch #100871 has been updated. 
> > Visit SourceForge.net for more info.
> > 
> > http://sourceforge.net/patch/?func=detailpatch&patch_id=100871&group_id=5470
> 
> I don't understand the comment about negative values. I certainly don't see
> that from the code.

It's documented that read(negative_number) on a file object returns all
the contents of the file.

--
Moshe Zadka <moshez@math.huji.ac.il>
There is no GOD but Python, and HTTP is its prophet.
http://advogato.org/person/moshez



From guido@beopen.com  Wed Jul 12 14:30:16 2000
From: guido@beopen.com (Guido van Rossum)
Date: Wed, 12 Jul 2000 08:30:16 -0500
Subject: [Patches] [Patch #100871] document new method in shutil (copyfileobj)
In-Reply-To: Your message of "Wed, 12 Jul 2000 13:40:11 +0300."
 <Pine.GSO.4.10.10007121338350.15424-100000@sundial>
References: <Pine.GSO.4.10.10007121338350.15424-100000@sundial>
Message-ID: <200007121330.IAA14201@cj20424-a.reston1.va.home.com>

Folks, please use the SF patch manager for comments like these.

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


From noreply@sourceforge.net  Wed Jul 12 15:31:56 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 12 Jul 2000 07:31:56 -0700
Subject: [Patches] [Patch #100872] change SimpleHTTPServer to use copyfileobj to copy files
Message-ID: <200007121431.HAA13793@delerium.i.sourceforge.net>

Patch #100872 has been updated. 
Visit SourceForge.net for more info.

http://sourceforge.net/patch/?func=detailpatch&patch_id=100872&group_id=5470


From noreply@sourceforge.net  Thu Jul 13 03:20:55 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 12 Jul 2000 19:20:55 -0700
Subject: [Patches] [Patch #100873] Use registry to find proxies for urllib on Win32
Message-ID: <200007130220.TAA03264@delerium.i.sourceforge.net>

Patch #100873 has been updated. 
Visit SourceForge.net for more info.

http://sourceforge.net/patch/?func=detailpatch&patch_id=100873&group_id=5470


From noreply@sourceforge.net  Thu Jul 13 04:29:41 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 12 Jul 2000 20:29:41 -0700
Subject: [Patches] [Patch #100874] Better error message with UnboundLocalError (for Tim Peters)
Message-ID: <200007130329.UAA05255@delerium.i.sourceforge.net>

Patch #100874 has been updated. 
Visit SourceForge.net for more info.

http://sourceforge.net/patch/?func=detailpatch&patch_id=100874&group_id=5470


From noreply@sourceforge.net  Thu Jul 13 09:33:40 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 13 Jul 2000 03:33:40 -0500
Subject: [Patches] [Patch #100874] THIS IS ONLY A TEST
Message-ID: <200007130833.DAA05736@server1.lfw.org>

Patch #100874 has been updated. 
Visit SourceForge.net for more info.

http://sourceforge.net/patch/?func=detailpatch&patch_id=100874&group_id=5470


From noreply@sourceforge.net  Thu Jul 13 09:40:20 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 13 Jul 2000 03:40:20 -0500
Subject: [Patches] [Patch #100874] THIS IS ONLY A TEST
Message-ID: <200007130840.DAA05815@server1.lfw.org>

Patch #100874 has been updated. 
Visit SourceForge.net for more info.

http://sourceforge.net/patch/?func=detailpatch&patch_id=100874&group_id=5470


From ping@server1.lfw.org  Thu Jul 13 09:40:46 2000
From: ping@server1.lfw.org (Ka-Ping Yee)
Date: Thu, 13 Jul 2000 03:40:46 -0500
Subject: [Patches] #100874: prescod -> prescod [Rejected] Better error message with UnboundLocalError
Message-ID: <200007130840.DAA05828@server1.lfw.org>

http://sourceforge.net/patch/?func=detailpatch&patch_id=100874&group_id=5470

Status: Rejected
Submitted By: prescod
Category: None
Summary: Better error message with UnboundLocalError
Assigned To: prescod
Patch: View Raw Patch
Date: 2000-Jul-12 20:29

2000-Jul-12 21:56 - tim_one wrote:
    Rejected and assigned back to Paul. I like the idea fine, the rejection is for style reasons and a repeated security hole. Please make the code look like the rest of ceval.c -- idiosyncracies (that aren't Guido's <0.3 wink>) are harmful in group-maintained code. Examples:
    
    > PyObject *nm=NULL;
    
    Should be a space on each side of "=". Ditto throughout the patch. BTW, is "nm" meant to be an abbreviation for "name"? If so, please spell out the two extra letters. If it's meant to be an abbreviation for New Mexico, capitalize it <wink>.
    
    > if(!nm) break;
    
    "if" isn't a function call: use a space between "if" and "(". It's also bad to slop "break" on the same line: makes it much harder to set a useful breakpoint here in a debugger. Everywhere else in the code this line would be spelled (if Guido wrote it -- and the "\t" business here is because SF comments don't preserve indentation):
    
    \tif (!nm)
    \t\tbreak
    
    > sprintf( buf, "Local variable %s
    
    No space between "(" and "buf" here.
    
    > PyExc_UnboundLocalError, buf );
    
    No space between "buf" and ")" here.
    
    > char buf[500];
    > ... followed by an unchecked sprintf into buf.
    
    This is a security hole: Python doesn't restrict identifiers to being no longer than 500 chars, so a hacker can easily trick this code into overwriting the buffer bounds. Easy but tedious to fix (e.g., #define the buf length, and use runtime code in conjunction with strncpy to guarantee buf's bounds are respected).

2000-Jul-12 21:56 - tim_one changed patch_status_id (previously Open)
2000-Jul-12 21:56 - tim_one changed assigned_to (previously tim_one)
2000-Jul-12 20:50 - prescod changed assigned_to (previously none)
2000-Jul-12 20:50 - prescod changed summary (previously Better error message with UnboundLocalError (for Tim Peters))


From ping@lfw.org  Thu Jul 13 09:35:54 2000
From: ping@lfw.org (Ka-Ping Yee)
Date: Thu, 13 Jul 2000 01:35:54 -0700 (PDT)
Subject: [Patches] Automatic patch notification messages
In-Reply-To: <200007130840.DAA05815@server1.lfw.org>
Message-ID: <Pine.LNX.4.10.10007130131560.16699-100000@skuld.lfw.org>

Okay, sorry for the two test messages.

I've set up a mail filter on my machine to detect patch notifications
from SourceForge and emit more informative messages in response, just
like the last one you saw about #100874.

This means each patch-status-change event will produce two messages on
this list: one uninformative message from <noreply@sourceforge.net> and
one verbose message from my script, which will send it as me.

If you filter out messages from <noreply@sourceforge.net>, the net
effect will be that you get more informative notifications.

If you're offended by the generation of extra mail -- i apologize --
scream at me and i can shut it off easily.

(Barry, if/when you want to set this up on your end so it doesn't
rely on lfw.org, feel free -- let me know and i'll turn off this one.)


-- ?!ng



From jeremy@beopen.com  Thu Jul 13 17:27:40 2000
From: jeremy@beopen.com (Jeremy Hylton)
Date: Thu, 13 Jul 2000 12:27:40 -0400 (EDT)
Subject: [Patches] Automatic patch notification messages
In-Reply-To: <Pine.LNX.4.10.10007130131560.16699-100000@skuld.lfw.org>
References: <200007130840.DAA05815@server1.lfw.org>
 <Pine.LNX.4.10.10007130131560.16699-100000@skuld.lfw.org>
Message-ID: <14701.60924.172820.114909@bitdiddle.concentric.net>

When does the Patch Manager generates a message to
patches@python.org?  I recently changed the status of a patch and got
mail personally, but don't think I saw anything on patches.

Jeremy


From DavidA@ActiveState.com  Thu Jul 13 17:56:05 2000
From: DavidA@ActiveState.com (David Ascher)
Date: Thu, 13 Jul 2000 09:56:05 -0700 (Pacific Daylight Time)
Subject: [Patches] Automatic patch notification messages
In-Reply-To: <Pine.LNX.4.10.10007130131560.16699-100000@skuld.lfw.org>
Message-ID: <Pine.WNT.4.21.0007130955460.1696-100000@ARMSTRONG>

> If you're offended by the generation of extra mail -- i apologize --
> scream at me and i can shut it off easily.

I like it.  Those other messages are deeply useless.

--david



From guido@beopen.com  Thu Jul 13 23:11:09 2000
From: guido@beopen.com (Guido van Rossum)
Date: Thu, 13 Jul 2000 17:11:09 -0500
Subject: [Patches] Automatic patch notification messages
In-Reply-To: Your message of "Thu, 13 Jul 2000 12:27:40 -0400."
 <14701.60924.172820.114909@bitdiddle.concentric.net>
References: <200007130840.DAA05815@server1.lfw.org> <Pine.LNX.4.10.10007130131560.16699-100000@skuld.lfw.org>
 <14701.60924.172820.114909@bitdiddle.concentric.net>
Message-ID: <200007132211.RAA11123@cj20424-a.reston1.va.home.com>

> When does the Patch Manager generates a message to
> patches@python.org?

Exactly once per patch: when the patch is first entered in the database.

> I recently changed the status of a patch and got
> mail personally, but don't think I saw anything on patches.

Status changes, as far as I can tell, go to the person who submitted
the patch and to the person who is the assignee.  There's probably a
bug that when the assignee changes, the new assignee gets mail but the
old assignee doesn't.

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


From ping@lfw.org  Fri Jul 14 10:48:46 2000
From: ping@lfw.org (Ka-Ping Yee)
Date: Fri, 14 Jul 2000 02:48:46 -0700 (PDT)
Subject: [Patches] Automatic patch notification messages
In-Reply-To: <200007132211.RAA11123@cj20424-a.reston1.va.home.com>
Message-ID: <Pine.LNX.4.10.10007140246440.16699-100000@skuld.lfw.org>

On Thu, 13 Jul 2000, Guido van Rossum wrote:
> > When does the Patch Manager generates a message to patches@python.org?
> 
> Exactly once per patch: when the patch is first entered in the database.

Darn.  Okay then -- sorry -- this is not going to work unless
i can receive a copy of all notifications somehow.

Forget this idea for now.  (Don't filter out <noreply@sourceforge.net>.)

(If there's a way to get SourceForge to send me ALL notifications,
then the script can do the job.)


-- ?!ng



From noreply@sourceforge.net  Fri Jul 14 13:22:34 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 14 Jul 2000 05:22:34 -0700
Subject: [Patches] [Patch #100888] Fix UCNs machine with >= 32bit longs
Message-ID: <200007141222.FAA27162@bush.i.sourceforge.net>

Patch #100888 has been updated. 
Visit SourceForge.net for more info.

http://sourceforge.net/patch/?func=detailpatch&patch_id=100888&group_id=5470


From vpoklsp@key1.italkey.it  Fri Jul 14 10:03:03 2000
From: vpoklsp@key1.italkey.it (vpoklsp@key1.italkey.it)
Date: Fri, 14 Jul 2000 09:03:03
Subject: [Patches] (no subject)
Message-ID: <191.769354.671576@mail.mindspring.com>

GET YOUR OWN 5 MEG WEBSITE FOR ONLY $11.95 PER MONTH TODAY!

STOP PAYING $19.95 or more TODAY for your web site, WHEN YOU CAN 
GET ONE FOR ONLY $11.95 PER MONTH!

DO YOU ALREADY HAVE A WEBSITE? ALL YOU HAVE TO DO IS TRANSFER THE 
DOMAIN TO OUR SERVERS AND UPLOAD YOUR DATA AND YOU ARE READY TO 
GO! YOUR NEW WEB SPACE CAN BE CREATED INSTANTLY WITH JUST A 
SIMPLE PHONE CALL TO  OUR OFFICE.

YOU CAN CHANGE THE DESIGN OF YOUR SITE AS MUCH AS YOU WANT with 
no extra charge!  UNLIMITED TRAFFIC -- no extra charge!

WE HAVE BOTH UNIX AND NT MACHINES WITH FRONT PAGE EXTENSIONS 
FULLY SUPPORTED.

A SET UP FEE OF $40.00 APPLIES for FIRST TIME CUSTOMERS.

ALL FEES PREPAID IN ADVANCE FOR THE YEAR PLUS A $40.00 SET UP 
CHARGE.

FOR DETAILS CALL 1 888 248 0765  or fax 240 337 8325

PES WEB HOSTING -- 
_______________________________________________________________

Want to do bulk email?

Ask us how today!

GET YOUR MESSAGE DELIVERED TO 500,000 PEOPLE FOR ONLY $550.00.

OR HAVE YOUR MESSAGE DELIVERED TO OVER 1 MILLION 
PEOPLE FOR ONLY $1200.00.

Call 1888 248 0765 for FURTHER INFORMATION today!
  or fax 240 337 8325

_________________________________________________________________

Get your own offshore trust! 
PROTECT YOUR PERSONAL ASSETS FROM LAWSUITS or Do SOME ESTATE 
PLANNING TO MINIMIZE THOSE INHERITANCE TAXES!
GET THAT OFFSHORE BANK ACCOUNT YOU ALWAYS WANTED!

For further information please fax 240 337 8325




THANK YOU




 
 
 
 
 
 
 


From noreply@sourceforge.net  Fri Jul 14 21:04:37 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 14 Jul 2000 13:04:37 -0700
Subject: [Patches] [Patch #100895] safe version of PyErr_Format
Message-ID: <200007142004.NAA08667@bush.i.sourceforge.net>

Patch #100895 has been updated. 
Visit SourceForge.net for more info.

http://sourceforge.net/patch/?func=detailpatch&patch_id=100895&group_id=5470


From noreply@sourceforge.net  Sat Jul 15 18:42:50 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 15 Jul 2000 10:42:50 -0700
Subject: [Patches] [Patch #100899] a smaller unicode name database
Message-ID: <200007151742.KAA13387@delerium.i.sourceforge.net>

Patch #100899 has been updated. 
Visit SourceForge.net for more info.

http://sourceforge.net/patch/?func=detailpatch&patch_id=100899&group_id=5470


From noreply@sourceforge.net  Sat Jul 15 19:46:22 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 15 Jul 2000 11:46:22 -0700
Subject: [Patches] [Patch #100900] POssible fix for posixpath.normpath
Message-ID: <200007151846.LAA15380@delerium.i.sourceforge.net>

Patch #100900 has been updated. 
Visit SourceForge.net for more info.

http://sourceforge.net/patch/?func=detailpatch&patch_id=100900&group_id=5470


From noreply@sourceforge.net  Sun Jul 16 17:48:42 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 16 Jul 2000 09:48:42 -0700
Subject: [Patches] [Patch #100912] modified \x behaviour for unicode strings
Message-ID: <200007161648.JAA22290@bush.i.sourceforge.net>

Patch #100912 has been updated. 
Visit SourceForge.net for more info.

http://sourceforge.net/patch/?func=detailpatch&patch_id=100912&group_id=5470


From noreply@sourceforge.net  Mon Jul 17 09:33:51 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 17 Jul 2000 01:33:51 -0700
Subject: [Patches] [Patch #100913] Optional pad character for rjust, ljust
Message-ID: <200007170833.BAA15670@bush.i.sourceforge.net>

Patch #100913 has been updated. 
Visit SourceForge.net for more info.

http://sourceforge.net/patch/?func=detailpatch&patch_id=100913&group_id=5470


From Pekka.Pessi@nokia.com  Tue Jul 18 11:39:41 2000
From: Pekka.Pessi@nokia.com (Pekka Pessi)
Date: Tue, 18 Jul 2000 13:39:41 +0300 (EEST)
Subject: [Patches] Now including the patch:
 Adding message text for (some) Winsock errors,
 adding "0" as a synonym for INADDR_ANY,
Message-ID: <14708.13293.724088.650971@rama.research.nokia.com>

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


	The first patch is for convenience on Windows platform. It contains
	standard (stderror()-like) error messages for (some) Winsock errors.

	The second patch is due to broken gethostbyname() on some
	platforms. ("0" is valid IP address - dot notation without a dot,
	like 0xfffffc00 when specifying a netmask. Unfortunately, "0" is not
	regonized by some Windows platforms.)

	Regards,
				Pekka Pessi


--QHKZn1oXFR
Content-Type: text/plain
Content-Description: patch
Content-Disposition: inline;
	filename="patch"
Content-Transfer-Encoding: 7bit

*** socketmodule.c.orig	Tue Jul 18 13:14:12 2000
--- socketmodule.c	Tue Jul 18 13:18:28 2000
***************
*** 281,288 ****
  {
  #ifdef MS_WINDOWS
  	if (WSAGetLastError()) {
  		PyObject *v;
! 		v = Py_BuildValue("(is)", WSAGetLastError(), "winsock error");
  		if (v != NULL) {
  			PyErr_SetObject(PySocket_Error, v);
  			Py_DECREF(v);
--- 281,359 ----
  {
  #ifdef MS_WINDOWS
  	if (WSAGetLastError()) {
+ 		static struct { int no; const char *msg; } *msgp, msgs[] = {
+ 			{ WSAEINTR, "Interrupted system call" },
+ 			{ WSAEBADF, "Bad file descriptor" },
+ 			{ WSAEACCES, "Permission denied" },
+ 			{ WSAEFAULT, "Bad address" },
+ 			{ WSAEINVAL, "Invalid argument" },
+ 			{ WSAEMFILE, "Too many open files" },
+ 			{ WSAEWOULDBLOCK, "Another winsock call while a "
+ 			  "blocking function was in progress" },
+ 			{ WSAEINPROGRESS, "Operation now in progress" },
+ 			{ WSAEALREADY, "Operation already in progress" },
+ 			{ WSAENOTSOCK, "Socket operation on non-socket" },
+ 			{ WSAEDESTADDRREQ, "Destination address required" },
+ 			{ WSAEMSGSIZE, "Message too long" },
+ 			{ WSAEPROTOTYPE, "Protocol wrong type for socket" },
+ 			{ WSAENOPROTOOPT, "Protocol not available" },
+ 			{ WSAEPROTONOSUPPORT, "Protocol not supported" },
+ 			{ WSAESOCKTNOSUPPORT, "Socket type not supported" },
+ 			{ WSAEOPNOTSUPP, "Operation not supported" },
+ 			{ WSAEPFNOSUPPORT, "Protocol family not supported" },
+ 			{ WSAEAFNOSUPPORT, "Address family not supported" },
+ 			{ WSAEADDRINUSE, "Address already in use" },
+ 			{ WSAEADDRNOTAVAIL, "Can't assign requested address" },
+ 			{ WSAENETDOWN, "Network is down" },
+ 			{ WSAENETUNREACH, "Network is unreachable" },
+ 			{ WSAENETRESET, "Network dropped connection on reset" },
+ 			{ WSAECONNABORTED, "Software caused connection abort" },
+ 			{ WSAECONNRESET, "Connection reset by peer" },
+ 			{ WSAENOBUFS, "No buffer space available" },
+ 			{ WSAEISCONN, "Socket is already connected" },
+ 			{ WSAENOTCONN, "Socket is not connected" },
+ 			{ WSAESHUTDOWN, "Can't send after socket shutdown" },
+ 			{ WSAETOOMANYREFS, "Too many references: "
+ 			  "can't splice" },
+ 			{ WSAETIMEDOUT, "Operation timed out" },
+ 			{ WSAECONNREFUSED, "Connection refused" },
+ 			{ WSAELOOP, "Too many levels of symbolic links" },
+ 			{ WSAENAMETOOLONG, "File name too long" },
+ 			{ WSAEHOSTDOWN, "Host is down" },
+ 			{ WSAEHOSTUNREACH, "No route to host" },
+ 			{ WSAENOTEMPTY, "Directory not empty" },
+ 			{ WSAEPROCLIM, "Too many processes" },
+ 			{ WSAEUSERS, "Too many users" },
+ 			{ WSAEDQUOT, "Disc quota exceeded" },
+ 			{ WSAESTALE, "Stale NFS file handle" },
+ 			{ WSAEREMOTE, "Too many levels of remote in path" },
+ 			{ WSASYSNOTREADY, "Network subsystem is unvailable" },
+ 			{ WSAVERNOTSUPPORTED, "WinSock version is not "
+ 			  "supported" },
+ 			{ WSANOTINITIALISED, "Successful WSAStartup() not yet "
+ 			  "performed" },
+ 			{ WSAEDISCON, "Graceful shutdown in progress" },
+ 			/* Resolver errors */
+ 			{ WSAHOST_NOT_FOUND, "No such host is known" },
+ 			{ WSATRY_AGAIN, "Host not found, or server failed" },
+ 			{ WSANO_RECOVERY, "Unexpected server error "
+ 			  "encountered" },
+ 			{ WSANO_DATA, "Valid name without requested data" },
+ 			{ WSANO_ADDRESS, "No address, look for MX record" },
+ 			{ 0, NULL }
+ 		};
  		PyObject *v;
! 		int no = WSAGetLastError();
! 		const char *msg = "winsock error";
! 		
! 		for (msgp = msgs; msgp->msg; msgp++) {
! 			if (no == msgp->no) {
! 				msg = msgp->msg;
! 				break;
! 			}
! 		}
! 
! 		v = Py_BuildValue("(is)", no, msg);
  		if (v != NULL) {
  			PyErr_SetObject(PySocket_Error, v);
  			Py_DECREF(v);
***************
*** 405,411 ****
  
  /* Convert a string specifying a host name or one of a few symbolic
     names to a numeric IP address.  This usually calls gethostbyname()
!    to do the work; the names "" and "<broadcast>" are special.
     Return the length (should always be 4 bytes), or negative if
     an error occurred; then an exception is raised. */
  
--- 476,482 ----
  
  /* Convert a string specifying a host name or one of a few symbolic
     names to a numeric IP address.  This usually calls gethostbyname()
!    to do the work; the names "", "0", "-1" and "<broadcast>" are special.
     Return the length (should always be 4 bytes), or negative if
     an error occurred; then an exception is raised. */
  
***************
*** 431,441 ****
  #endif /* HAVE_GETHOSTBYNAME_R */
  
  	memset((void *) addr_ret, '\0', sizeof(*addr_ret));
! 	if (name[0] == '\0') {
  		addr_ret->sin_addr.s_addr = INADDR_ANY;
  		return 4;
  	}
! 	if (name[0] == '<' && strcmp(name, "<broadcast>") == 0) {
  		addr_ret->sin_addr.s_addr = INADDR_BROADCAST;
  		return 4;
  	}
--- 502,513 ----
  #endif /* HAVE_GETHOSTBYNAME_R */
  
  	memset((void *) addr_ret, '\0', sizeof(*addr_ret));
! 	if (name[0] == '\0' || name[0] == '0' && name[1] == '\0') {
  		addr_ret->sin_addr.s_addr = INADDR_ANY;
  		return 4;
  	}
! 	if (name[0] == '<' && strcmp(name, "<broadcast>") == 0 ||
! 	    strcmp(name, "-1") == 0) {
  		addr_ret->sin_addr.s_addr = INADDR_BROADCAST;
  		return 4;
  	}


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

I confirm that, to the best of my knowledge and belief, this
contribution is free of any claims of third parties under
copyright, patent or other rights or interests ("claims").  To
the extent that I have any such claims, I hereby grant to CNRI a
nonexclusive, irrevocable, royalty-free, worldwide license to
reproduce, distribute, perform and/or display publicly, prepare
derivative versions, and otherwise use this contribution as part
of the Python software and its related documentation, or any
derivative versions thereof, at no cost to CNRI or its licensed
users, and to authorize others to do so.

I acknowledge that CNRI may, at its sole discretion, decide
whether or not to incorporate this contribution in the Python
software and its related documentation.  I further grant CNRI
permission to use my name and other identifying information
provided to CNRI by me for use in connection with the Python
software and its related documentation.

--QHKZn1oXFR--


From thomas@xs4all.net  Tue Jul 18 12:14:41 2000
From: thomas@xs4all.net (Thomas Wouters)
Date: Tue, 18 Jul 2000 13:14:41 +0200
Subject: [Patches] Now including the patch: Adding message text for (some) Winsock errors, adding "0" as a synonym for INADDR_ANY,
In-Reply-To: <14708.13293.724088.650971@rama.research.nokia.com>; from Pekka.Pessi@nokia.com on Tue, Jul 18, 2000 at 01:39:41PM +0300
References: <14708.13293.724088.650971@rama.research.nokia.com>
Message-ID: <20000718131440.C7340@xs4all.nl>

On Tue, Jul 18, 2000 at 01:39:41PM +0300, Pekka Pessi wrote:

> 	The first patch is for convenience on Windows platform. It contains
> 	standard (stderror()-like) error messages for (some) Winsock errors.

> 	The second patch is due to broken gethostbyname() on some
> 	platforms. ("0" is valid IP address - dot notation without a dot,
> 	like 0xfffffc00 when specifying a netmask. Unfortunately, "0" is not
> 	regonized by some Windows platforms.)

Very nice ! Those winsock errors always bothered me ;) However, the patch
submission guidelines have changed some now that Python has moved to
SourceForge. See http://www.python.org/patches/ for more information. Can
you upload your patch(es) to the Python sourceforge pages, either as a
single patch or as two seperate ones ? If so, please do, and place the
comments there, too.

If not, well, no problem, I or someone else will probably upload them ;) But
doing it yourself is easier, for feedback and for uploading new versions.

-- 
Thomas Wouters <thomas@xs4all.net>

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


From noreply@sourceforge.net  Tue Jul 18 12:30:18 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 18 Jul 2000 04:30:18 -0700
Subject: [Patches] [Patch #100926] StaError messages for Winsock errors.
Message-ID: <200007181130.EAA13684@delerium.i.sourceforge.net>

Patch #100926 has been updated. 
Visit sourceforge.net for more info.

http://sourceforge.net/patch/?func=detailpatch&patch_id=100926&group_id=5470


From noreply@sourceforge.net  Tue Jul 18 12:32:40 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 18 Jul 2000 04:32:40 -0700
Subject: [Patches] [Patch #100927] Fix for broken gethostbyname("0")
Message-ID: <200007181132.EAA13711@delerium.i.sourceforge.net>

Patch #100927 has been updated. 
Visit sourceforge.net for more info.

http://sourceforge.net/patch/?func=detailpatch&patch_id=100927&group_id=5470


From Pekka.Pessi@nokia.com  Tue Jul 18 11:38:11 2000
From: Pekka.Pessi@nokia.com (Pekka Pessi)
Date: Tue, 18 Jul 2000 13:38:11 +0300 (EEST)
Subject: [Patches] Adding message text for (some) Winsock errors,
 adding "0" as a synonym for INADDR_ANY
Message-ID: <14708.13203.684851.353453@rama.research.nokia.com>

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


	The first patch is for convenience on Windows platform. It contains
	standard (stderror()-like) error messages for (some) Winsock errors.

	The second patch is due to broken gethostbyname() on some
	platforms. ("0" is valid IP address - dot notation without a dot,
	like 0xfffffc00 when specifying a netmask. Unfortunately, "0" is not
	regonized by some Windows platforms.)

	Regards,
				Pekka Pessi


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

I confirm that, to the best of my knowledge and belief, this
contribution is free of any claims of third parties under
copyright, patent or other rights or interests ("claims").  To
the extent that I have any such claims, I hereby grant to CNRI a
nonexclusive, irrevocable, royalty-free, worldwide license to
reproduce, distribute, perform and/or display publicly, prepare
derivative versions, and otherwise use this contribution as part
of the Python software and its related documentation, or any
derivative versions thereof, at no cost to CNRI or its licensed
users, and to authorize others to do so.

I acknowledge that CNRI may, at its sole discretion, decide
whether or not to incorporate this contribution in the Python
software and its related documentation.  I further grant CNRI
permission to use my name and other identifying information
provided to CNRI by me for use in connection with the Python
software and its related documentation.

--xdbrobk5OY--


From noreply@sourceforge.net  Wed Jul 19 06:03:44 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 18 Jul 2000 22:03:44 -0700
Subject: [Patches] [Patch #100931] fix for posixpath.normpath -- competitor to 100900
Message-ID: <200007190503.WAA27781@bush.i.sourceforge.net>

Patch #100931 has been updated. 
Visit sourceforge.net for more info.

http://sourceforge.net/patch/?func=detailpatch&patch_id=100931&group_id=5470


From Moshe Zadka <moshez@math.huji.ac.il>  Thu Jul 20 14:38:41 2000
From: Moshe Zadka <moshez@math.huji.ac.il> (Moshe Zadka)
Date: Thu, 20 Jul 2000 16:38:41 +0300 (IDT)
Subject: [Patches] Rejecting patch 100933
Message-ID: <Pine.GSO.4.10.10007201636280.23388-100000@sundial>

Does anyone feel like test() functions should be defined only if the
module is being run as a script? I think the consensus is that this is a
Bad Thing(TM). Anyone? Otherwise I'm just going to reject it...

--
Moshe Zadka <moshez@math.huji.ac.il>
There is no GOD but Python, and HTTP is its prophet.
http://advogato.org/person/moshez



From thomas@xs4all.net  Thu Jul 20 14:48:24 2000
From: thomas@xs4all.net (Thomas Wouters)
Date: Thu, 20 Jul 2000 15:48:24 +0200
Subject: [Patches] Rejecting patch 100933
In-Reply-To: <Pine.GSO.4.10.10007201636280.23388-100000@sundial>; from moshez@math.huji.ac.il on Thu, Jul 20, 2000 at 04:38:41PM +0300
References: <Pine.GSO.4.10.10007201636280.23388-100000@sundial>
Message-ID: <20000720154824.R9897@xs4all.nl>

On Thu, Jul 20, 2000 at 04:38:41PM +0300, Moshe Zadka wrote:
> Does anyone feel like test() functions should be defined only if the
> module is being run as a script? I think the consensus is that this is a
> Bad Thing(TM). Anyone? Otherwise I'm just going to reject it...

-1, but then, I already gave my opinion on the patch on SF.

-- 
Thomas Wouters <thomas@xs4all.net>

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


From noreply@sourceforge.net  Thu Jul 20 23:40:33 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 20 Jul 2000 15:40:33 -0700
Subject: [Patches] [Patch #100947] increase control and default size of pdb traceback display
Message-ID: <200007202240.PAA29479@bush.i.sourceforge.net>

Patch #100947 has been updated. 

Project: 
Category: None
Status: Open
Summary: increase control and default size of pdb traceback display

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=100947&group_id=5470


From tim_one@email.msn.com  Sat Jul 22 22:31:14 2000
From: tim_one@email.msn.com (Tim Peters)
Date: Sat, 22 Jul 2000 17:31:14 -0400
Subject: [Patches] Test -- ignore
Message-ID: <LNBBLJKPBEHFEDALKOLCGEGAGLAA.tim_one@email.msn.com>

Wondering whether *any* mail to patches@python.org comes thru anymore.




From InternetSeer.com  Mon Jul 24 07:13:06 2000
From: InternetSeer.com (InternetSeer.com)
Date: 24 Jul 2000 02:13:06 -0400
Subject: [Patches] Your web site has been mapped
Message-ID: <0e34f0613061870MARS1@mars1.internetseer.com>

Freewire has added your web site to its map of the World Wide Web.  Freewire will continue to monitor millions of links and web sites every day during its ongoing web survey.

If it is important for you to know that your site is connected to the web at all times, Freewire has arranged with InternetSeer.com to notify you when your site does not respond.  This means that, AT NO CHARGE; InternetSeer.com will monitor your Web site every hour and send notification to you by email whenever your site is not connected to the Web. There are NO current or future charges associated with this service.

To begin your FREE monitoring NOW, activate your account at:
http://www.internetseer.com/signup.asp?email=patches@python.org

Mark McLellan
Chief Technology Officer
Freewire.com

Is your web site status important to you? I'd love your comments. If you prefer not to receive any future notices that result from our ongoing survey please let me know by returning this email with the word "remove" in the subject line.

=============================================
##Remove: patches@python.org##


From noreply@sourceforge.net  Tue Jul 25 12:24:42 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 25 Jul 2000 04:24:42 -0700
Subject: [Patches] [Patch #100977] This patch makes whichdb recognize Python's dumbdbm database
Message-ID: <200007251124.EAA18816@delerium.i.sourceforge.net>

Patch #100977 has been updated. 

Project: 
Category: None
Status: Open
Summary: This patch makes whichdb recognize Python's dumbdbm database

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=100977&group_id=5470


From noreply@sourceforge.net  Tue Jul 25 16:51:14 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 25 Jul 2000 08:51:14 -0700
Subject: [Patches] [Patch #100978] Minor updates for BeOS R5
Message-ID: <200007251551.IAA27173@delerium.i.sourceforge.net>

Patch #100978 has been updated. 

Project: 
Category: None
Status: Open
Summary: Minor updates for BeOS R5

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=100978&group_id=5470


From noreply@sourceforge.net  Tue Jul 25 21:30:31 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 25 Jul 2000 13:30:31 -0700
Subject: [Patches] [Patch #100852] Add poll() to select module
Message-ID: <200007252030.NAA01690@bush.i.sourceforge.net>

Patch #100852 has been updated. 

Project: 
Category: None
Status: Open
Summary: Add poll() to select module

Follow-Ups:

Date: 2000-Jul-11 04:25
By: akuchling

Comment:
Derived from Sam Rushing's pollmodule.c that forms
part of Medusa.  Once I get a second opinion about the patch, I'll check it in.


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

Date: 2000-Jul-21 06:33
By: akuchling

Comment:
Updated version of the patch, which adds poll() to the select module.
.register() and .unregister() add/remove fds, and .poll() performs the system call.  

Open question: what should register/unregister do if you attempt to register a fd twice?  Or remove a fd that isn't registered?  In this version, 
no exception is raised.  IMHO the second case should definitely be an error (ValueError?).  I'm not sure about the first case, but maybe it should continue to be ignored.

Open question: should there be a function or attribute to get the list of 
registered fds?

Still to do: write documentation, add the test case.

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

Date: 2000-Jul-24 17:54
By: akuchling

Comment:
Assigned to Jeremy for review; feel free to bounce it to someone else.
-------------------------------------------------------

Date: 2000-Jul-25 10:25
By: akuchling

Comment:
Update patch to latest version, which adds poll() to the select() module.
-------------------------------------------------------

Date: 2000-Jul-25 13:30
By: jhylton

Comment:
Several style nits changed, mostly to do with whitespace.

Substantive changes:
1. include poll.h instead of sys/poll.h; this works on Linux and is recommended by Stevens
2. add symbolic constants for POLLIN, ..., POLLNVAL, ... POLLWRBAND

One more Open Issue:
I worry about the linear search and realloc that occur every time a fd is registered or unregistered.  Possible solutions:
- interface to register many fds at once
- keep the list of fds in sorted order
- use a dict to store fds and generate fdarry lazily
- keep track of allocated length and used length for ufds, so that fewer reallocs are required
Each of these suggestions has some added complexity, so I'm not sure that I like any of them.

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

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=100852&group_id=5470


From ping@server1.lfw.org  Tue Jul 25 21:50:20 2000
From: ping@server1.lfw.org (Ka-Ping Yee)
Date: Tue, 25 Jul 2000 15:50:20 -0500
Subject: [Patches] #100852: akuchling -> akuchling [Open] Add poll() to select module
Message-ID: <200007252050.PAA24527@server1.lfw.org>

http://sourceforge.net/patch/?func=detailpatch&patch_id=100852&group_id=5470

Status: Open
Submitted By: akuchling
Category: None
Summary: Add poll() to select module
Assigned To: akuchling
Patch: View Raw Patch
Date: 2000-Jul-11 04:22

2000-Jul-25 13:30 - jhylton wrote:
    Several style nits changed, mostly to do with whitespace.
    
    Substantive changes:
    1. include poll.h instead of sys/poll.h; this works on Linux and is recommended by Stevens
    2. add symbolic constants for POLLIN, ..., POLLNVAL, ... POLLWRBAND
    
    One more Open Issue:
    I worry about the linear search and realloc that occur every time a fd is registered or unregistered. Possible solutions:
    - interface to register many fds at once
    - keep the list of fds in sorted order
    - use a dict to store fds and generate fdarry lazily
    - keep track of allocated length and used length for ufds, so that fewer reallocs are required
    Each of these suggestions has some added complexity, so I'm not sure that I like any of them.

2000-Jul-25 10:25 - akuchling wrote:
    Update patch to latest version, which adds poll() to the select() module.

2000-Jul-24 17:54 - akuchling wrote:
    Assigned to Jeremy for review; feel free to bounce it to someone else.

2000-Jul-21 06:33 - akuchling wrote:
    Updated version of the patch, which adds poll() to the select module.
    .register() and .unregister() add/remove fds, and .poll() performs the system call. 
    
    Open question: what should register/unregister do if you attempt to register a fd twice? Or remove a fd that isn't registered? In this version, 
    no exception is raised. IMHO the second case should definitely be an error (ValueError?). I'm not sure about the first case, but maybe it should continue to be ignored.
    
    Open question: should there be a function or attribute to get the list of 
    registered fds?
    
    Still to do: write documentation, add the test case.

2000-Jul-11 04:25 - akuchling wrote:
    Derived from Sam Rushing's pollmodule.c that forms
    part of Medusa. Once I get a second opinion about the patch, I'll check it in.

2000-Jul-25 13:30 - jhylton changed Patch Code (previously Modified - New Version)
2000-Jul-25 13:30 - jhylton changed assigned_to (previously jhylton)
2000-Jul-25 10:25 - akuchling changed Patch Code (previously Modified - New Version)
2000-Jul-25 10:25 - akuchling changed summary (previously Add poll() to posix module)
2000-Jul-24 17:54 - akuchling changed assigned_to (previously akuchling)
2000-Jul-11 04:25 - akuchling changed assigned_to (previously none)


From noreply@sourceforge.net  Tue Jul 25 21:35:26 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 25 Jul 2000 13:35:26 -0700
Subject: [Patches] [Patch #100979] support for out-of-tree "make TAGS"
Message-ID: <200007252035.NAA13093@delerium.i.sourceforge.net>

Patch #100979 has been updated. 

Project: 
Category: None
Status: Open
Summary: support for out-of-tree "make TAGS"

Follow-Ups:

Date: 2000-Jul-25 10:24
By: mwh

Comment:
this (dead simple!) patch lets "make TAGS" work when $(srcdir) != "." (which funnily enough is how I do it...).

"make tags" now fails with

$ make tags
ctags -w -t ../src/Include/*.h
ctags: Unknown option: -t

... but I don't know what the correct fix is (just remove the "-t"?)
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=100979&group_id=5470


From ping@server1.lfw.org  Tue Jul 25 21:54:23 2000
From: ping@server1.lfw.org (Ka-Ping Yee)
Date: Tue, 25 Jul 2000 15:54:23 -0500
Subject: [Patches] #100979: mwh -> fdrake [Open] support for out-of-tree "make TAGS"
Message-ID: <200007252054.PAA24540@server1.lfw.org>

http://sourceforge.net/patch/?func=detailpatch&patch_id=100979&group_id=5470

Status: Open
Submitted By: mwh
Category: None
Summary: support for out-of-tree "make TAGS"
Assigned To: fdrake
Patch: View Raw Patch
Date: 2000-Jul-25 10:21

2000-Jul-25 10:24 - mwh wrote:
    this (dead simple!) patch lets "make TAGS" work when $(srcdir) != "." (which funnily enough is how I do it...).
    
    "make tags" now fails with
    
    $ make tags
    ctags -w -t ../src/Include/*.h
    ctags: Unknown option: -t
    
    ... but I don't know what the correct fix is (just remove the "-t"?)

2000-Jul-25 13:35 - jhylton changed assigned_to (previously none)


From noreply@sourceforge.net  Tue Jul 25 21:36:27 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 25 Jul 2000 13:36:27 -0700
Subject: [Patches] [Patch #100955] eptags: regex->re, 4 char indent.
Message-ID: <200007252036.NAA01909@bush.i.sourceforge.net>

Patch #100955 has been updated. 

Project: 
Category: None
Status: Open
Summary: eptags: regex->re, 4 char indent.

Follow-Ups:

Date: 2000-Jul-22 01:35
By: hooft

Comment:
This is another time waster. But now at least I know how a TAGS file is constructed, and I know that re is a lot slower than regex.
-------------------------------------------------------

Date: 2000-Jul-22 23:44
By: moshez

Comment:
I'm not sure that this patch is worth it -- it seems backwards to analyse Python programs with re -- why not simply use the parser module if we really want this?
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=100955&group_id=5470


From ping@server1.lfw.org  Tue Jul 25 21:55:35 2000
From: ping@server1.lfw.org (Ka-Ping Yee)
Date: Tue, 25 Jul 2000 15:55:35 -0500
Subject: [Patches] #100955: hooft -> tim_one [Open] eptags: regex->re, 4 char indent.
Message-ID: <200007252055.PAA24557@server1.lfw.org>

http://sourceforge.net/patch/?func=detailpatch&patch_id=100955&group_id=5470

Status: Open
Submitted By: hooft
Category: None
Summary: eptags: regex->re, 4 char indent.
Assigned To: tim_one
Patch: View Raw Patch
Date: 2000-Jul-22 01:34

2000-Jul-22 23:44 - moshez wrote:
    I'm not sure that this patch is worth it -- it seems backwards to analyse Python programs with re -- why not simply use the parser module if we really want this?

2000-Jul-22 01:35 - hooft wrote:
    This is another time waster. But now at least I know how a TAGS file is constructed, and I know that re is a lot slower than regex.

2000-Jul-25 13:36 - jhylton changed assigned_to (previously none)


From noreply@sourceforge.net  Tue Jul 25 21:41:19 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 25 Jul 2000 13:41:19 -0700
Subject: [Patches] [Patch #100852] Add poll() to select module
Message-ID: <200007252041.NAA13390@delerium.i.sourceforge.net>

Patch #100852 has been updated. 

Project: 
Category: None
Status: Open
Summary: Add poll() to select module

Follow-Ups:

Date: 2000-Jul-11 04:25
By: akuchling

Comment:
Derived from Sam Rushing's pollmodule.c that forms
part of Medusa.  Once I get a second opinion about the patch, I'll check it in.


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

Date: 2000-Jul-21 06:33
By: akuchling

Comment:
Updated version of the patch, which adds poll() to the select module.
.register() and .unregister() add/remove fds, and .poll() performs the system call.  

Open question: what should register/unregister do if you attempt to register a fd twice?  Or remove a fd that isn't registered?  In this version, 
no exception is raised.  IMHO the second case should definitely be an error (ValueError?).  I'm not sure about the first case, but maybe it should continue to be ignored.

Open question: should there be a function or attribute to get the list of 
registered fds?

Still to do: write documentation, add the test case.

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

Date: 2000-Jul-24 17:54
By: akuchling

Comment:
Assigned to Jeremy for review; feel free to bounce it to someone else.
-------------------------------------------------------

Date: 2000-Jul-25 10:25
By: akuchling

Comment:
Update patch to latest version, which adds poll() to the select() module.
-------------------------------------------------------

Date: 2000-Jul-25 13:30
By: jhylton

Comment:
Several style nits changed, mostly to do with whitespace.

Substantive changes:
1. include poll.h instead of sys/poll.h; this works on Linux and is recommended by Stevens
2. add symbolic constants for POLLIN, ..., POLLNVAL, ... POLLWRBAND

One more Open Issue:
I worry about the linear search and realloc that occur every time a fd is registered or unregistered.  Possible solutions:
- interface to register many fds at once
- keep the list of fds in sorted order
- use a dict to store fds and generate fdarry lazily
- keep track of allocated length and used length for ufds, so that fewer reallocs are required
Each of these suggestions has some added complexity, so I'm not sure that I like any of them.

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

Date: 2000-Jul-25 13:41
By: akuchling

Comment:
I wondered about the linear search, too; it means balancing 
efficiency versus the lines of code to write this one object?  IMHO implementing both #1 and #3 would be
good; allow passing an arbitrary # of fds to register (and
unregister?), store them in a dict, and then lazily generate the ufd
array when needed.  Or is there some built-in more suited than a dict for this?

Hmm... you could also return the dict as an attribute of the polling object, and modifying it directly would also register or remove descriptors.
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=100852&group_id=5470


From ping@server1.lfw.org  Tue Jul 25 22:01:26 2000
From: ping@server1.lfw.org (Ka-Ping Yee)
Date: Tue, 25 Jul 2000 16:01:26 -0500
Subject: [Patches] #100852: akuchling -> akuchling [Open] Add poll() to select module
Message-ID: <200007252101.QAA24593@server1.lfw.org>

http://sourceforge.net/patch/?func=detailpatch&patch_id=100852&group_id=5470

Status: Open
Submitted By: akuchling
Category: None
Summary: Add poll() to select module
Assigned To: akuchling
Patch: View Raw Patch
Date: 2000-Jul-11 04:22

2000-Jul-25 13:41 - akuchling wrote:
    I wondered about the linear search, too; it means balancing 
    efficiency versus the lines of code to write this one object? IMHO implementing both #1 and #3 would be
    good; allow passing an arbitrary # of fds to register (and
    unregister?), store them in a dict, and then lazily generate the ufd
    array when needed. Or is there some built-in more suited than a dict for this?
    
    Hmm... you could also return the dict as an attribute of the polling object, and modifying it directly would also register or remove descriptors.

2000-Jul-25 13:30 - jhylton wrote:
    Several style nits changed, mostly to do with whitespace.
    
    Substantive changes:
    1. include poll.h instead of sys/poll.h; this works on Linux and is recommended by Stevens
    2. add symbolic constants for POLLIN, ..., POLLNVAL, ... POLLWRBAND
    
    One more Open Issue:
    I worry about the linear search and realloc that occur every time a fd is registered or unregistered. Possible solutions:
    - interface to register many fds at once
    - keep the list of fds in sorted order
    - use a dict to store fds and generate fdarry lazily
    - keep track of allocated length and used length for ufds, so that fewer reallocs are required
    Each of these suggestions has some added complexity, so I'm not sure that I like any of them.

2000-Jul-25 10:25 - akuchling wrote:
    Update patch to latest version, which adds poll() to the select() module.

2000-Jul-24 17:54 - akuchling wrote:
    Assigned to Jeremy for review; feel free to bounce it to someone else.

2000-Jul-21 06:33 - akuchling wrote:
    Updated version of the patch, which adds poll() to the select module.
    .register() and .unregister() add/remove fds, and .poll() performs the system call. 
    
    Open question: what should register/unregister do if you attempt to register a fd twice? Or remove a fd that isn't registered? In this version, 
    no exception is raised. IMHO the second case should definitely be an error (ValueError?). I'm not sure about the first case, but maybe it should continue to be ignored.
    
    Open question: should there be a function or attribute to get the list of 
    registered fds?
    
    Still to do: write documentation, add the test case.

2000-Jul-11 04:25 - akuchling wrote:
    Derived from Sam Rushing's pollmodule.c that forms
    part of Medusa. Once I get a second opinion about the patch, I'll check it in.

2000-Jul-25 13:30 - jhylton changed Patch Code (previously Modified - New Version)
2000-Jul-25 13:30 - jhylton changed assigned_to (previously jhylton)
2000-Jul-25 10:25 - akuchling changed Patch Code (previously Modified - New Version)
2000-Jul-25 10:25 - akuchling changed summary (previously Add poll() to posix module)
2000-Jul-24 17:54 - akuchling changed assigned_to (previously akuchling)
2000-Jul-11 04:25 - akuchling changed assigned_to (previously none)


From noreply@sourceforge.net  Tue Jul 25 21:51:54 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 25 Jul 2000 13:51:54 -0700
Subject: [Patches] [Patch #100979] support for out-of-tree "make TAGS"
Message-ID: <200007252051.NAA02469@bush.i.sourceforge.net>

Patch #100979 has been updated. 

Project: 
Category: None
Status: Open
Summary: support for out-of-tree "make TAGS"

Follow-Ups:

Date: 2000-Jul-25 10:24
By: mwh

Comment:
this (dead simple!) patch lets "make TAGS" work when $(srcdir) != "." (which funnily enough is how I do it...).

"make tags" now fails with

$ make tags
ctags -w -t ../src/Include/*.h
ctags: Unknown option: -t

... but I don't know what the correct fix is (just remove the "-t"?)
-------------------------------------------------------

Date: 2000-Jul-25 13:51
By: gvanrossum

Comment:
Hm.  I thought, just what I need, because my build directory is also in a different place as my source directory. But it turns out I want my TAGS file in the source directory! So now I'm indifferent on this.

The "make tags" works for me -- maybe you have a nonstandard ctags?

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

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=100979&group_id=5470


From ping@server1.lfw.org  Tue Jul 25 22:10:26 2000
From: ping@server1.lfw.org (Ka-Ping Yee)
Date: Tue, 25 Jul 2000 16:10:26 -0500
Subject: [Patches] #100979: mwh -> fdrake [Open] support for out-of-tree "make TAGS"
Message-ID: <200007252110.QAA24625@server1.lfw.org>

http://sourceforge.net/patch/?func=detailpatch&patch_id=100979&group_id=5470

Status: Open
Submitted By: mwh
Category: None
Summary: support for out-of-tree "make TAGS"
Assigned To: fdrake
Patch: View Raw Patch
Date: 2000-Jul-25 10:21

2000-Jul-25 13:51 - gvanrossum wrote:
    Hm. I thought, just what I need, because my build directory is also in a different place as my source directory. But it turns out I want my TAGS file in the source directory! So now I'm indifferent on this.
    
    The "make tags" works for me -- maybe you have a nonstandard ctags?

2000-Jul-25 10:24 - mwh wrote:
    this (dead simple!) patch lets "make TAGS" work when $(srcdir) != "." (which funnily enough is how I do it...).
    
    "make tags" now fails with
    
    $ make tags
    ctags -w -t ../src/Include/*.h
    ctags: Unknown option: -t
    
    ... but I don't know what the correct fix is (just remove the "-t"?)

2000-Jul-25 13:35 - jhylton changed assigned_to (previously none)


From noreply@sourceforge.net  Tue Jul 25 21:57:05 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 25 Jul 2000 13:57:05 -0700
Subject: [Patches] [Patch #100955] eptags: regex->re, 4 char indent.
Message-ID: <200007252057.NAA02745@bush.i.sourceforge.net>

Patch #100955 has been updated. 

Project: 
Category: None
Status: Accepted
Summary: eptags: regex->re, 4 char indent.

Follow-Ups:

Date: 2000-Jul-22 01:35
By: hooft

Comment:
This is another time waster. But now at least I know how a TAGS file is constructed, and I know that re is a lot slower than regex.
-------------------------------------------------------

Date: 2000-Jul-22 23:44
By: moshez

Comment:
I'm not sure that this patch is worth it -- it seems backwards to analyse Python programs with re -- why not simply use the parser module if we really want this?
-------------------------------------------------------

Date: 2000-Jul-25 13:57
By: gvanrossum

Comment:
SRE should be faster again, right?

The parser module is a very big gun for this simple app -- look at it as an example for text processing (and documentation for TAGS files :-).

I say go for it.
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=100955&group_id=5470


From ping@server1.lfw.org  Tue Jul 25 22:16:24 2000
From: ping@server1.lfw.org (Ka-Ping Yee)
Date: Tue, 25 Jul 2000 16:16:24 -0500
Subject: [Patches] #100955: hooft -> moshez [Accepted] eptags: regex->re, 4 char indent.
Message-ID: <200007252116.QAA24647@server1.lfw.org>

http://sourceforge.net/patch/?func=detailpatch&patch_id=100955&group_id=5470

Status: Accepted
Submitted By: hooft
Category: None
Summary: eptags: regex->re, 4 char indent.
Assigned To: moshez
Patch: View Raw Patch
Date: 2000-Jul-22 01:34

2000-Jul-25 13:57 - gvanrossum wrote:
    SRE should be faster again, right?
    
    The parser module is a very big gun for this simple app -- look at it as an example for text processing (and documentation for TAGS files :-).
    
    I say go for it.

2000-Jul-22 23:44 - moshez wrote:
    I'm not sure that this patch is worth it -- it seems backwards to analyse Python programs with re -- why not simply use the parser module if we really want this?

2000-Jul-22 01:35 - hooft wrote:
    This is another time waster. But now at least I know how a TAGS file is constructed, and I know that re is a lot slower than regex.

2000-Jul-25 13:57 - gvanrossum changed patch_status_id (previously Open)
2000-Jul-25 13:57 - gvanrossum changed assigned_to (previously tim_one)
2000-Jul-25 13:36 - jhylton changed assigned_to (previously none)


From mwh21@cam.ac.uk  Tue Jul 25 22:04:12 2000
From: mwh21@cam.ac.uk (Michael Hudson)
Date: 25 Jul 2000 22:04:12 +0100
Subject: [Patches] [Patch #100979] support for out-of-tree "make TAGS"
In-Reply-To: noreply@sourceforge.net's message of "Tue, 25 Jul 2000 13:51:54 -0700"
References: <200007252051.NAA02469@bush.i.sourceforge.net>
Message-ID: <m3u2ddc46r.fsf@atrus.jesus.cam.ac.uk>

[well, patches@python.org is no longer quiet... it's now just a bit
confusing!]

> Date: 2000-Jul-25 13:51
> By: gvanrossum
> 
> Comment:
> Hm.  I thought, just what I need, because my build directory is also
> in a different place as my source directory. But it turns out I want
> my TAGS file in the source directory! So now I'm indifferent on
> this.

Well, then change Makefile.in to something like:

TAGS::
                (cd $(srcdir) ; etags Include/*.h ;\
                for i in $(SUBDIRS); do etags -a $$i/*.[ch]; done )

I'm not that bothered, but what we have now is definitely broken.

I like to keep the source directory pristine in general, but that's
screwed anyway (because of .pycs made during "make test" - and
probably at other times).

(I guess I should use lndir...).

> The "make tags" works for me -- maybe you have a nonstandard ctags?

I have what came with redhat 6.1 (and as I'm an emacs boy, don't do
anything for my sake...).

Cheers,
M.



From noreply@sourceforge.net  Tue Jul 25 22:40:43 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 25 Jul 2000 14:40:43 -0700
Subject: [Patches] [Patch #100852] Add poll() to select module
Message-ID: <200007252140.OAA15304@delerium.i.sourceforge.net>

Patch #100852 has been updated. 

Project: 
Category: None
Status: Open
Summary: Add poll() to select module

Follow-Ups:

Date: 2000-Jul-11 04:25
By: akuchling

Comment:
Derived from Sam Rushing's pollmodule.c that forms
part of Medusa.  Once I get a second opinion about the patch, I'll check it in.


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

Date: 2000-Jul-21 06:33
By: akuchling

Comment:
Updated version of the patch, which adds poll() to the select module.
.register() and .unregister() add/remove fds, and .poll() performs the system call.  

Open question: what should register/unregister do if you attempt to register a fd twice?  Or remove a fd that isn't registered?  In this version, 
no exception is raised.  IMHO the second case should definitely be an error (ValueError?).  I'm not sure about the first case, but maybe it should continue to be ignored.

Open question: should there be a function or attribute to get the list of 
registered fds?

Still to do: write documentation, add the test case.

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

Date: 2000-Jul-24 17:54
By: akuchling

Comment:
Assigned to Jeremy for review; feel free to bounce it to someone else.
-------------------------------------------------------

Date: 2000-Jul-25 10:25
By: akuchling

Comment:
Update patch to latest version, which adds poll() to the select() module.
-------------------------------------------------------

Date: 2000-Jul-25 13:30
By: jhylton

Comment:
Several style nits changed, mostly to do with whitespace.

Substantive changes:
1. include poll.h instead of sys/poll.h; this works on Linux and is recommended by Stevens
2. add symbolic constants for POLLIN, ..., POLLNVAL, ... POLLWRBAND

One more Open Issue:
I worry about the linear search and realloc that occur every time a fd is registered or unregistered.  Possible solutions:
- interface to register many fds at once
- keep the list of fds in sorted order
- use a dict to store fds and generate fdarry lazily
- keep track of allocated length and used length for ufds, so that fewer reallocs are required
Each of these suggestions has some added complexity, so I'm not sure that I like any of them.

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

Date: 2000-Jul-25 13:41
By: akuchling

Comment:
I wondered about the linear search, too; it means balancing 
efficiency versus the lines of code to write this one object?  IMHO implementing both #1 and #3 would be
good; allow passing an arbitrary # of fds to register (and
unregister?), store them in a dict, and then lazily generate the ufd
array when needed.  Or is there some built-in more suited than a dict for this?

Hmm... you could also return the dict as an attribute of the polling object, and modifying it directly would also register or remove descriptors.
-------------------------------------------------------

Date: 2000-Jul-25 14:40
By: jhylton

Comment:
I think a dict is the right data structure, but I don't think it should be exposed directly.  If it is not exposed, then the ufd array need only be generated for poll calls after a register or unregister.  If there are multiple polls without a change, the same array can be re-used.

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

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=100852&group_id=5470


From ping@server1.lfw.org  Tue Jul 25 22:59:25 2000
From: ping@server1.lfw.org (Ka-Ping Yee)
Date: Tue, 25 Jul 2000 16:59:25 -0500
Subject: [Patches] #100852: akuchling -> akuchling [Open] Add poll() to select module
Message-ID: <200007252159.QAA24867@server1.lfw.org>

http://sourceforge.net/patch/?func=detailpatch&patch_id=100852&group_id=5470

Status: Open
Submitted By: akuchling
Category: None
Summary: Add poll() to select module
Assigned To: akuchling
Patch: View Raw Patch
Date: 2000-Jul-11 04:22

2000-Jul-25 14:40 - jhylton wrote:
    I think a dict is the right data structure, but I don't think it should be exposed directly. If it is not exposed, then the ufd array need only be generated for poll calls after a register or unregister. If there are multiple polls without a change, the same array can be re-used.

2000-Jul-25 13:41 - akuchling wrote:
    I wondered about the linear search, too; it means balancing 
    efficiency versus the lines of code to write this one object? IMHO implementing both #1 and #3 would be
    good; allow passing an arbitrary # of fds to register (and
    unregister?), store them in a dict, and then lazily generate the ufd
    array when needed. Or is there some built-in more suited than a dict for this?
    
    Hmm... you could also return the dict as an attribute of the polling object, and modifying it directly would also register or remove descriptors.

2000-Jul-25 13:30 - jhylton wrote:
    Several style nits changed, mostly to do with whitespace.
    
    Substantive changes:
    1. include poll.h instead of sys/poll.h; this works on Linux and is recommended by Stevens
    2. add symbolic constants for POLLIN, ..., POLLNVAL, ... POLLWRBAND
    
    One more Open Issue:
    I worry about the linear search and realloc that occur every time a fd is registered or unregistered. Possible solutions:
    - interface to register many fds at once
    - keep the list of fds in sorted order
    - use a dict to store fds and generate fdarry lazily
    - keep track of allocated length and used length for ufds, so that fewer reallocs are required
    Each of these suggestions has some added complexity, so I'm not sure that I like any of them.

2000-Jul-25 10:25 - akuchling wrote:
    Update patch to latest version, which adds poll() to the select() module.

2000-Jul-24 17:54 - akuchling wrote:
    Assigned to Jeremy for review; feel free to bounce it to someone else.

2000-Jul-21 06:33 - akuchling wrote:
    Updated version of the patch, which adds poll() to the select module.
    .register() and .unregister() add/remove fds, and .poll() performs the system call. 
    
    Open question: what should register/unregister do if you attempt to register a fd twice? Or remove a fd that isn't registered? In this version, 
    no exception is raised. IMHO the second case should definitely be an error (ValueError?). I'm not sure about the first case, but maybe it should continue to be ignored.
    
    Open question: should there be a function or attribute to get the list of 
    registered fds?
    
    Still to do: write documentation, add the test case.

2000-Jul-11 04:25 - akuchling wrote:
    Derived from Sam Rushing's pollmodule.c that forms
    part of Medusa. Once I get a second opinion about the patch, I'll check it in.

2000-Jul-25 13:30 - jhylton changed Patch Code (previously Modified - New Version)
2000-Jul-25 13:30 - jhylton changed assigned_to (previously jhylton)
2000-Jul-25 10:25 - akuchling changed Patch Code (previously Modified - New Version)
2000-Jul-25 10:25 - akuchling changed summary (previously Add poll() to posix module)
2000-Jul-24 17:54 - akuchling changed assigned_to (previously akuchling)
2000-Jul-11 04:25 - akuchling changed assigned_to (previously none)


From noreply@sourceforge.net  Tue Jul 25 23:56:52 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 25 Jul 2000 15:56:52 -0700
Subject: [Patches] [Patch #100888] Fix UCNs machine with >= 32bit longs
Message-ID: <200007252256.PAA17844@delerium.i.sourceforge.net>

Patch #100888 has been updated. 

Project: 
Category: None
Status: Open
Summary: Fix UCNs machine with >= 32bit longs

Follow-Ups:

Date: 2000-Jul-14 07:28
By: jhylton

Comment:
Trent, Can you test this on a machine with >32 bits
-------------------------------------------------------

Date: 2000-Jul-16 06:49
By: lemburg

Comment:
Is the ucnhash.c part of this patch still needed in the light of Fredrik's new module ?
-------------------------------------------------------

Date: 2000-Jul-16 13:43
By: btutt

Comment:
Nope the ucnhash.c stuff isn't needed given Fredrik's new patch.

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

Date: 2000-Jul-17 10:24
By: tmick

Comment:
I haven't yet looked at the patch but I will (after Monterey).

> Nope the ucnhash.c stuff isn't needed given Fredrik's new 
> patch

DOes this mean that the patch is obselete now or that part of it needs to removed? Pardon if this is a stupid question. (As I said above I will look at this after Monterey).

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

Date: 2000-Jul-25 15:56
By: tmick

Comment:
I applied the patch on Linux64. test_ucn.py now passes. An email from Bill Tutt on python-dev indicated that I don't need to test it on Win64.

Back to Bill.
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=100888&group_id=5470


From ping@server1.lfw.org  Wed Jul 26 00:17:18 2000
From: ping@server1.lfw.org (Ka-Ping Yee)
Date: Tue, 25 Jul 2000 18:17:18 -0500
Subject: [Patches] #100888: btutt -> jhylton [Open] Fix UCNs machine with >= 32bit longs
Message-ID: <200007252317.SAA25302@server1.lfw.org>

http://sourceforge.net/patch/?func=detailpatch&patch_id=100888&group_id=5470

Status: Open
Submitted By: btutt
Category: None
Summary: Fix UCNs machine with >= 32bit longs
Assigned To: jhylton
Patch: View Raw Patch
Date: 2000-Jul-14 05:22

2000-Jul-25 15:56 - tmick wrote:
    I applied the patch on Linux64. test_ucn.py now passes. An email from Bill Tutt on python-dev indicated that I don't need to test it on Win64.
    
    Back to Bill.

2000-Jul-17 10:24 - tmick wrote:
    I haven't yet looked at the patch but I will (after Monterey).
    
    > Nope the ucnhash.c stuff isn't needed given Fredrik's new 
    > patch
    
    DOes this mean that the patch is obselete now or that part of it needs to removed? Pardon if this is a stupid question. (As I said above I will look at this after Monterey).

2000-Jul-16 13:43 - btutt wrote:
    Nope the ucnhash.c stuff isn't needed given Fredrik's new patch.

2000-Jul-16 06:49 - lemburg wrote:
    Is the ucnhash.c part of this patch still needed in the light of Fredrik's new module ?

2000-Jul-14 07:28 - jhylton wrote:
    Trent, Can you test this on a machine with >32 bits

2000-Jul-25 15:56 - tmick changed assigned_to (previously tmick)
2000-Jul-14 07:28 - jhylton changed assigned_to (previously none)


From noreply@sourceforge.net  Wed Jul 26 04:56:52 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 25 Jul 2000 20:56:52 -0700
Subject: [Patches] [Patch #100888] Fix UCNs machine with >= 32bit longs
Message-ID: <200007260356.UAA26240@delerium.i.sourceforge.net>

Patch #100888 has been updated. 

Project: 
Category: None
Status: Closed
Summary: Fix UCNs machine with >= 32bit longs

Follow-Ups:

Date: 2000-Jul-14 07:28
By: jhylton

Comment:
Trent, Can you test this on a machine with >32 bits
-------------------------------------------------------

Date: 2000-Jul-16 06:49
By: lemburg

Comment:
Is the ucnhash.c part of this patch still needed in the light of Fredrik's new module ?
-------------------------------------------------------

Date: 2000-Jul-16 13:43
By: btutt

Comment:
Nope the ucnhash.c stuff isn't needed given Fredrik's new patch.

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

Date: 2000-Jul-17 10:24
By: tmick

Comment:
I haven't yet looked at the patch but I will (after Monterey).

> Nope the ucnhash.c stuff isn't needed given Fredrik's new 
> patch

DOes this mean that the patch is obselete now or that part of it needs to removed? Pardon if this is a stupid question. (As I said above I will look at this after Monterey).

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

Date: 2000-Jul-25 15:56
By: tmick

Comment:
I applied the patch on Linux64. test_ucn.py now passes. An email from Bill Tutt on python-dev indicated that I don't need to test it on Win64.

Back to Bill.
-------------------------------------------------------

Date: 2000-Jul-25 20:56
By: jhylton

Comment:
We have decided to go w /F's database which does not use the ucnhash stuff.  The ucnhash is too esoteric for the Python core, so Andrew will be maintaining it from his own Web pages.   I've committed the changes anyway; until the larger issue is resolve, test_ucn works in Linux64.
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=100888&group_id=5470


From ping@server1.lfw.org  Wed Jul 26 05:15:48 2000
From: ping@server1.lfw.org (Ka-Ping Yee)
Date: Tue, 25 Jul 2000 23:15:48 -0500
Subject: [Patches] #100888: btutt -> jhylton [Closed] Fix UCNs machine with >= 32bit longs
Message-ID: <200007260415.XAA26352@server1.lfw.org>

http://sourceforge.net/patch/?func=detailpatch&patch_id=100888&group_id=5470

Status: Closed
Submitted By: btutt
Category: None
Summary: Fix UCNs machine with >= 32bit longs
Assigned To: jhylton
Patch: View Raw Patch
Date: 2000-Jul-14 05:22

2000-Jul-25 20:56 - jhylton wrote:
    We have decided to go w /F's database which does not use the ucnhash stuff. The ucnhash is too esoteric for the Python core, so Andrew will be maintaining it from his own Web pages. I've committed the changes anyway; until the larger issue is resolve, test_ucn works in Linux64.

2000-Jul-25 15:56 - tmick wrote:
    I applied the patch on Linux64. test_ucn.py now passes. An email from Bill Tutt on python-dev indicated that I don't need to test it on Win64.
    
    Back to Bill.

2000-Jul-17 10:24 - tmick wrote:
    I haven't yet looked at the patch but I will (after Monterey).
    
    > Nope the ucnhash.c stuff isn't needed given Fredrik's new 
    > patch
    
    DOes this mean that the patch is obselete now or that part of it needs to removed? Pardon if this is a stupid question. (As I said above I will look at this after Monterey).

2000-Jul-16 13:43 - btutt wrote:
    Nope the ucnhash.c stuff isn't needed given Fredrik's new patch.

2000-Jul-16 06:49 - lemburg wrote:
    Is the ucnhash.c part of this patch still needed in the light of Fredrik's new module ?

2000-Jul-14 07:28 - jhylton wrote:
    Trent, Can you test this on a machine with >32 bits

2000-Jul-25 20:56 - jhylton changed patch_status_id (previously Open)
2000-Jul-25 20:56 - jhylton changed close_date (previously 1969-Dec-31 16:00)
2000-Jul-25 15:56 - tmick changed assigned_to (previously tmick)
2000-Jul-14 07:28 - jhylton changed assigned_to (previously none)


From noreply@sourceforge.net  Wed Jul 26 06:31:51 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 25 Jul 2000 22:31:51 -0700
Subject: [Patches] [Patch #100872] change SimpleHTTPServer to use copyfileobj to copy files
Message-ID: <200007260531.WAA28854@delerium.i.sourceforge.net>

Patch #100872 has been updated. 

Project: 
Category: None
Status: Accepted
Summary: change SimpleHTTPServer to use copyfileobj to copy files

Follow-Ups:

Date: 2000-Jul-12 08:21
By: gvanrossum

Comment:
OK, but check your indentation -- seems to be a tab/space issue.
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=100872&group_id=5470


From ping@server1.lfw.org  Wed Jul 26 07:23:38 2000
From: ping@server1.lfw.org (Ka-Ping Yee)
Date: Wed, 26 Jul 2000 01:23:38 -0500
Subject: [Patches] #100872: moshez -> moshez [Accepted] change SimpleHTTPServer to use copyfileobj to copy files
Message-ID: <200007260623.BAA26628@server1.lfw.org>

http://sourceforge.net/patch/?func=detailpatch&patch_id=100872&group_id=5470

Status: Accepted
Submitted By: moshez
Category: None
Summary: change SimpleHTTPServer to use copyfileobj to copy files
Assigned To: moshez
Patch: View Raw Patch
Date: 2000-Jul-12 07:31

2000-Jul-12 08:21 - gvanrossum wrote:
    OK, but check your indentation -- seems to be a tab/space issue.

2000-Jul-25 22:31 - moshez changed Patch Code (previously Modified - New Version)
2000-Jul-12 08:21 - gvanrossum changed patch_status_id (previously Open)
2000-Jul-12 08:21 - gvanrossum changed assigned_to (previously none)


From noreply@sourceforge.net  Wed Jul 26 07:47:47 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 25 Jul 2000 23:47:47 -0700
Subject: [Patches] [Patch #100873] Use registry to find proxies for urllib on Win32
Message-ID: <200007260647.XAA22478@bush.i.sourceforge.net>

Patch #100873 has been updated. 

Project: 
Category: None
Status: Accepted
Summary: Use registry to find proxies for urllib on Win32

Follow-Ups:

Date: 2000-Jul-12 19:27
By: gvanrossum

Comment:
Mark, can you have a look at this? If it's okay, pass it on to Tim. If you don't have time, assign it to Greg.

One immediate problem: a huge block of hairy code inside an unqualified try-except is a no-no!
-------------------------------------------------------

Date: 2000-Jul-13 07:45
By: moshez

Comment:
I think that if you change the "except", to "except whatever_error_winreg_raises" it should be all right
-------------------------------------------------------

Date: 2000-Jul-13 07:57
By: mhammond

Comment:
Im happy with this patch.  I'll be back in Oz in a week - I will test and approve the patch then - if this delay is a problem, I'm happy for it to be re-assigned.
-------------------------------------------------------

Date: 2000-Jul-15 01:07
By: btutt

Comment:
Its not that simple....
See KB #Q226473 that spells out all of the relavent details about why this is a not so good idea:

http://support.microsoft.com/support/kb/articles/Q226/4/73.ASP



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

Date: 2000-Jul-15 18:59
By: mhammond

Comment:
OK - so it wont be perfect - but are you suggesting that this patch is not an improvement?  Even after reading that page, I'm inclined to suggest it is better than the code we have now.
-------------------------------------------------------

Date: 2000-Jul-17 16:46
By: btutt

Comment:
Its better than we have now, but I defiantely dislike using the registry to acquire data when theres an API that exposes the same data. 

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

Date: 2000-Jul-23 21:50
By: mhammond

Comment:
I agree with Bill's comments, although there is no clear place to put the C code necessary to do this.  Further, the point about multiple proxy settings isnt that useful, as we can not predict what internet connection should be used for the proxy settings - we don't have much choice other than to use the default.

However, I just confirmed that Mozilla, for example, doesnt use this registry key.  I assume that Netscape 4.x also doesnt (but I don't have that installed - does anyone know?) So in effect, we are providing a patch that will allow IE users to have their proxy configuration for their default connection to be used.

For non IE users, this patch is a problem, as it provides no technique for overriding the (presumably empty) registry.  And for IE users with multiple connections, this may not be what they want (and allowing Python to select which connection via some GUI is definately beyond the scope of this patch)

I propose that the patch be modified to allow the existing scheme of environment variables, and to only go sniffing the registry if this variable doesnt exist.  This will allow _anyone_ to set a variable to get their specific preference at any time, while still allowing the majority of users (ie, IE users with a single internet connection) to not specify this variable, but still work.

Comments please!
-------------------------------------------------------

Date: 2000-Jul-23 23:26
By: nyamatongwe

Comment:
The Navigator/Mozilla proxy information is found in the prefs.js file in the preferred profile directory. The default profile is named "default". It looks like:

user_pref("network.proxy.http", "127.0.0.1");
user_pref("network.proxy.http_port", 8080);
user_pref("network.proxy.type", 1);

Not worth the fiddling IMHO.

This registry key is not just for IE, as it is used by other applications such as WinAmp but this may only be read at install-time. You can change the settings in the Internet Options applet inside the Control Panel.

Looking in the environment first is fine.
-------------------------------------------------------

Date: 2000-Jul-24 00:36
By: mhammond

Comment:
I agree with Bill's comments, although there is no clear place to put the C code necessary to do this.  Further, the point about multiple proxy settings isnt that useful, as we can not predict what internet connection should be used for the proxy settings - we don't have much choice other than to use the default.

However, I just confirmed that Mozilla, for example, doesnt use this registry key.  I assume that Netscape 4.x also doesnt (but I don't have that installed - does anyone know?) So in effect, we are providing a patch that will allow IE users to have their proxy configuration for their default connection to be used.

For non IE users, this patch is a problem, as it provides no technique for overriding the (presumably empty) registry.  And for IE users with multiple connections, this may not be what they want (and allowing Python to select which connection via some GUI is definately beyond the scope of this patch)

I propose that the patch be modified to allow the existing scheme of environment variables, and to only go sniffing the registry if this variable doesnt exist.  This will allow _anyone_ to set a variable to get their specific preference at any time, while still allowing the majority of users (ie, IE users with a single internet connection) to not specify this variable, but still work.

Comments please!
-------------------------------------------------------

Date: 2000-Jul-24 16:16
By: mhammond

Comment:
As discussed, this version uses the environment, and failing that, the registry.

The patch is now a little more intrusive in an attempt to avoid cut-and-paste of the environment logic.  It is now also trivial for the Mac to also use the same "environment first" trick, but I havent touched that!

Has been tested on Windows and vaguely tested on Debian Linux.  Re-assigned to Tim, so he can check the style etc (eg, there is one line that _just_ reaches over 80 chars, and IMO is far more ugly to fix than to leave).  Tim - feel free to reassign back and I will make corrections and checkin if necessary (although Guido explicitly asked that it be assigned to you - obviously you need more work thrown at you <wink>).
-------------------------------------------------------

Date: 2000-Jul-25 23:47
By: tim_one

Comment:
Accepted & assigned back to Mark.  I don't know anything about proxies, so I didn't review that.  Style looks OK to me, and I agree the "long line" isn't an unforgivable sin in this case.  One suggestion:
x    ... name[-6:] == '_proxy'
is clearer as
x    ... name.endswith('_proxy')
Unfortunately, the hard-coded 6 on the line following that one is harder to get rid of.

I'd sure like to see more testing on Linux, but maybe checking it in is the best way to make that happen!

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

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=100873&group_id=5470


From ping@server1.lfw.org  Wed Jul 26 08:07:29 2000
From: ping@server1.lfw.org (Ka-Ping Yee)
Date: Wed, 26 Jul 2000 02:07:29 -0500
Subject: [Patches] #100873: nyamatongwe -> mhammond [Accepted] Use registry to find proxies for urllib on Win32
Message-ID: <200007260707.CAA26734@server1.lfw.org>

http://sourceforge.net/patch/?func=detailpatch&patch_id=100873&group_id=5470

Status: Accepted
Submitted By: nyamatongwe
Category: None
Summary: Use registry to find proxies for urllib on Win32
Assigned To: mhammond
Patch: View Raw Patch
Date: 2000-Jul-12 19:20

2000-Jul-25 23:47 - tim_one wrote:
    Accepted &amp; assigned back to Mark. I don't know anything about proxies, so I didn't review that. Style looks OK to me, and I agree the "long line" isn't an unforgivable sin in this case. One suggestion:
    x ... name[-6:] == '_proxy'
    is clearer as
    x ... name.endswith('_proxy')
    Unfortunately, the hard-coded 6 on the line following that one is harder to get rid of.
    
    I'd sure like to see more testing on Linux, but maybe checking it in is the best way to make that happen!

2000-Jul-24 16:16 - mhammond wrote:
    As discussed, this version uses the environment, and failing that, the registry.
    
    The patch is now a little more intrusive in an attempt to avoid cut-and-paste of the environment logic. It is now also trivial for the Mac to also use the same "environment first" trick, but I havent touched that!
    
    Has been tested on Windows and vaguely tested on Debian Linux. Re-assigned to Tim, so he can check the style etc (eg, there is one line that _just_ reaches over 80 chars, and IMO is far more ugly to fix than to leave). Tim - feel free to reassign back and I will make corrections and checkin if necessary (although Guido explicitly asked that it be assigned to you - obviously you need more work thrown at you <wink>).

2000-Jul-24 00:36 - mhammond wrote:
    I agree with Bill's comments, although there is no clear place to put the C code necessary to do this. Further, the point about multiple proxy settings isnt that useful, as we can not predict what internet connection should be used for the proxy settings - we don't have much choice other than to use the default.
    
    However, I just confirmed that Mozilla, for example, doesnt use this registry key. I assume that Netscape 4.x also doesnt (but I don't have that installed - does anyone know?) So in effect, we are providing a patch that will allow IE users to have their proxy configuration for their default connection to be used.
    
    For non IE users, this patch is a problem, as it provides no technique for overriding the (presumably empty) registry. And for IE users with multiple connections, this may not be what they want (and allowing Python to select which connection via some GUI is definately beyond the scope of this patch)
    
    I propose that the patch be modified to allow the existing scheme of environment variables, and to only go sniffing the registry if this variable doesnt exist. This will allow _anyone_ to set a variable to get their specific preference at any time, while still allowing the majority of users (ie, IE users with a single internet connection) to not specify this variable, but still work.
    
    Comments please!

2000-Jul-23 23:26 - nyamatongwe wrote:
    The Navigator/Mozilla proxy information is found in the prefs.js file in the preferred profile directory. The default profile is named "default". It looks like:
    
    user_pref("network.proxy.http", "127.0.0.1");
    user_pref("network.proxy.http_port", 8080);
    user_pref("network.proxy.type", 1);
    
    Not worth the fiddling IMHO.
    
    This registry key is not just for IE, as it is used by other applications such as WinAmp but this may only be read at install-time. You can change the settings in the Internet Options applet inside the Control Panel.
    
    Looking in the environment first is fine.

2000-Jul-23 21:50 - mhammond wrote:
    I agree with Bill's comments, although there is no clear place to put the C code necessary to do this. Further, the point about multiple proxy settings isnt that useful, as we can not predict what internet connection should be used for the proxy settings - we don't have much choice other than to use the default.
    
    However, I just confirmed that Mozilla, for example, doesnt use this registry key. I assume that Netscape 4.x also doesnt (but I don't have that installed - does anyone know?) So in effect, we are providing a patch that will allow IE users to have their proxy configuration for their default connection to be used.
    
    For non IE users, this patch is a problem, as it provides no technique for overriding the (presumably empty) registry. And for IE users with multiple connections, this may not be what they want (and allowing Python to select which connection via some GUI is definately beyond the scope of this patch)
    
    I propose that the patch be modified to allow the existing scheme of environment variables, and to only go sniffing the registry if this variable doesnt exist. This will allow _anyone_ to set a variable to get their specific preference at any time, while still allowing the majority of users (ie, IE users with a single internet connection) to not specify this variable, but still work.
    
    Comments please!

2000-Jul-17 16:46 - btutt wrote:
    Its better than we have now, but I defiantely dislike using the registry to acquire data when theres an API that exposes the same data.

2000-Jul-15 18:59 - mhammond wrote:
    OK - so it wont be perfect - but are you suggesting that this patch is not an improvement? Even after reading that page, I'm inclined to suggest it is better than the code we have now.

2000-Jul-15 01:07 - btutt wrote:
    Its not that simple....
    See KB #Q226473 that spells out all of the relavent details about why this is a not so good idea:
    
    http://support.microsoft.com/support/kb/articles/Q226/4/73.ASP

2000-Jul-13 07:57 - mhammond wrote:
    Im happy with this patch. I'll be back in Oz in a week - I will test and approve the patch then - if this delay is a problem, I'm happy for it to be re-assigned.

2000-Jul-13 07:45 - moshez wrote:
    I think that if you change the "except", to "except whatever_error_winreg_raises" it should be all right

2000-Jul-12 19:27 - gvanrossum wrote:
    Mark, can you have a look at this? If it's okay, pass it on to Tim. If you don't have time, assign it to Greg.
    
    One immediate problem: a huge block of hairy code inside an unqualified try-except is a no-no!

2000-Jul-25 23:47 - tim_one changed patch_status_id (previously Open)
2000-Jul-25 23:47 - tim_one changed assigned_to (previously tim_one)
2000-Jul-24 16:16 - mhammond changed Patch Code (previously Modified - New Version)
2000-Jul-24 16:16 - mhammond changed assigned_to (previously mhammond)
2000-Jul-12 19:27 - gvanrossum changed assigned_to (previously none)


From noreply@sourceforge.net  Wed Jul 26 07:56:55 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 25 Jul 2000 23:56:55 -0700
Subject: [Patches] [Patch #100874] Better error message with UnboundLocalError
Message-ID: <200007260656.XAA31300@delerium.i.sourceforge.net>

Patch #100874 has been updated. 

Project: 
Category: None
Status: Accepted
Summary: Better error message with UnboundLocalError

Follow-Ups:

Date: 2000-Jul-12 21:56
By: tim_one

Comment:
Rejected and assigned back to Paul.  I like the idea fine, the rejection is for style reasons and a repeated security hole.  Please make the code look like the rest of ceval.c -- idiosyncracies (that aren't Guido's <0.3 wink>) are harmful in group-maintained code.  Examples:

>    PyObject *nm=NULL;

Should be a space on each side of "=".  Ditto throughout the patch.  BTW, is "nm" meant to be an abbreviation for "name"?  If so, please spell out the two extra letters.  If it's meant to be an abbreviation for New Mexico, capitalize it <wink>.

>    if(!nm) break;

"if" isn't a function call:  use a space between "if" and "(".  It's also bad to slop "break" on the same line:  makes it much harder to set a useful breakpoint here in a debugger.  Everywhere else in the code this line would be spelled (if Guido wrote it -- and the "\t" business here is because SF comments don't preserve indentation):

\tif (!nm)
\t\tbreak

>  sprintf( buf, "Local variable %s

No space between "(" and "buf" here.

>    PyExc_UnboundLocalError, buf );

No space between "buf" and ")" here.

>   char buf[500];
> ... followed by an unchecked sprintf into buf.

This is a security hole:  Python doesn't restrict identifiers to being no longer than 500 chars, so a hacker can easily trick this code into overwriting the buffer bounds.  Easy but tedious to fix (e.g., #define the buf length, and use runtime code in conjunction with strncpy to guarantee buf's bounds are respected).

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

Date: 2000-Jul-14 14:17
By: prescod

Comment:
Small helper function format_exc_check_arg makes it easy to generate one string and a argument-type exceptions. It may be overkill in terms of null checking...reviewer can decide. Otherwise, error messages are added to NameErrors and UnboundLocalErrors. That means that all exceptions thrown in ceval have associated error messages.

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

Date: 2000-Jul-18 06:32
By: twouters

Comment:
The helper function is declared 'static', but not defined as such.

Rest of the style issues seem solved ;)
-------------------------------------------------------

Date: 2000-Jul-25 23:56
By: tim_one

Comment:
Accepted and assigned back to Paul.  Paul, the new format_exc_check_arg function is defined K&R-style, but we've moved to ANSI almost everywhere else in the source.  Would be nice if you fix that before checking this in.  Else I'll look for it and fix it myself.  Sorry for the delay in getting back to this!
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=100874&group_id=5470


From ping@server1.lfw.org  Wed Jul 26 08:16:28 2000
From: ping@server1.lfw.org (Ka-Ping Yee)
Date: Wed, 26 Jul 2000 02:16:28 -0500
Subject: [Patches] #100874: prescod -> prescod [Accepted] Better error message with UnboundLocalError
Message-ID: <200007260716.CAA26769@server1.lfw.org>

http://sourceforge.net/patch/?func=detailpatch&patch_id=100874&group_id=5470

Status: Accepted
Submitted By: prescod
Category: None
Summary: Better error message with UnboundLocalError
Assigned To: prescod
Patch: View Raw Patch
Date: 2000-Jul-12 20:29

2000-Jul-25 23:56 - tim_one wrote:
    Accepted and assigned back to Paul. Paul, the new format_exc_check_arg function is defined K&amp;R-style, but we've moved to ANSI almost everywhere else in the source. Would be nice if you fix that before checking this in. Else I'll look for it and fix it myself. Sorry for the delay in getting back to this!

2000-Jul-18 06:32 - twouters wrote:
    The helper function is declared 'static', but not defined as such.
    
    Rest of the style issues seem solved ;)

2000-Jul-14 14:17 - prescod wrote:
    Small helper function format_exc_check_arg makes it easy to generate one string and a argument-type exceptions. It may be overkill in terms of null checking...reviewer can decide. Otherwise, error messages are added to NameErrors and UnboundLocalErrors. That means that all exceptions thrown in ceval have associated error messages.

2000-Jul-12 21:56 - tim_one wrote:
    Rejected and assigned back to Paul. I like the idea fine, the rejection is for style reasons and a repeated security hole. Please make the code look like the rest of ceval.c -- idiosyncracies (that aren't Guido's <0.3 wink>) are harmful in group-maintained code. Examples:
    
    > PyObject *nm=NULL;
    
    Should be a space on each side of "=". Ditto throughout the patch. BTW, is "nm" meant to be an abbreviation for "name"? If so, please spell out the two extra letters. If it's meant to be an abbreviation for New Mexico, capitalize it <wink>.
    
    > if(!nm) break;
    
    "if" isn't a function call: use a space between "if" and "(". It's also bad to slop "break" on the same line: makes it much harder to set a useful breakpoint here in a debugger. Everywhere else in the code this line would be spelled (if Guido wrote it -- and the "\t" business here is because SF comments don't preserve indentation):
    
    \tif (!nm)
    \t\tbreak
    
    > sprintf( buf, "Local variable %s
    
    No space between "(" and "buf" here.
    
    > PyExc_UnboundLocalError, buf );
    
    No space between "buf" and ")" here.
    
    > char buf[500];
    > ... followed by an unchecked sprintf into buf.
    
    This is a security hole: Python doesn't restrict identifiers to being no longer than 500 chars, so a hacker can easily trick this code into overwriting the buffer bounds. Easy but tedious to fix (e.g., #define the buf length, and use runtime code in conjunction with strncpy to guarantee buf's bounds are respected).

2000-Jul-25 23:56 - tim_one changed patch_status_id (previously Open)
2000-Jul-25 23:56 - tim_one changed assigned_to (previously tim_one)
2000-Jul-18 08:01 - prescod changed Patch Code (previously Modified - New Version)
2000-Jul-14 14:17 - prescod changed Patch Code (previously Modified - New Version)
2000-Jul-14 14:17 - prescod changed patch_status_id (previously Rejected)
2000-Jul-14 14:17 - prescod changed assigned_to (previously prescod)
2000-Jul-12 21:56 - tim_one changed patch_status_id (previously Open)
2000-Jul-12 21:56 - tim_one changed assigned_to (previously tim_one)
2000-Jul-12 20:50 - prescod changed assigned_to (previously none)
2000-Jul-12 20:50 - prescod changed summary (previously Better error message with UnboundLocalError (for Tim Peters))


From noreply@sourceforge.net  Wed Jul 26 08:00:32 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 26 Jul 2000 00:00:32 -0700
Subject: [Patches] [Patch #100873] Use registry to find proxies for urllib on Win32
Message-ID: <200007260700.AAA22882@bush.i.sourceforge.net>

Patch #100873 has been updated. 

Project: 
Category: None
Status: Closed
Summary: Use registry to find proxies for urllib on Win32

Follow-Ups:

Date: 2000-Jul-12 19:27
By: gvanrossum

Comment:
Mark, can you have a look at this? If it's okay, pass it on to Tim. If you don't have time, assign it to Greg.

One immediate problem: a huge block of hairy code inside an unqualified try-except is a no-no!
-------------------------------------------------------

Date: 2000-Jul-13 07:45
By: moshez

Comment:
I think that if you change the "except", to "except whatever_error_winreg_raises" it should be all right
-------------------------------------------------------

Date: 2000-Jul-13 07:57
By: mhammond

Comment:
Im happy with this patch.  I'll be back in Oz in a week - I will test and approve the patch then - if this delay is a problem, I'm happy for it to be re-assigned.
-------------------------------------------------------

Date: 2000-Jul-15 01:07
By: btutt

Comment:
Its not that simple....
See KB #Q226473 that spells out all of the relavent details about why this is a not so good idea:

http://support.microsoft.com/support/kb/articles/Q226/4/73.ASP



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

Date: 2000-Jul-15 18:59
By: mhammond

Comment:
OK - so it wont be perfect - but are you suggesting that this patch is not an improvement?  Even after reading that page, I'm inclined to suggest it is better than the code we have now.
-------------------------------------------------------

Date: 2000-Jul-17 16:46
By: btutt

Comment:
Its better than we have now, but I defiantely dislike using the registry to acquire data when theres an API that exposes the same data. 

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

Date: 2000-Jul-23 21:50
By: mhammond

Comment:
I agree with Bill's comments, although there is no clear place to put the C code necessary to do this.  Further, the point about multiple proxy settings isnt that useful, as we can not predict what internet connection should be used for the proxy settings - we don't have much choice other than to use the default.

However, I just confirmed that Mozilla, for example, doesnt use this registry key.  I assume that Netscape 4.x also doesnt (but I don't have that installed - does anyone know?) So in effect, we are providing a patch that will allow IE users to have their proxy configuration for their default connection to be used.

For non IE users, this patch is a problem, as it provides no technique for overriding the (presumably empty) registry.  And for IE users with multiple connections, this may not be what they want (and allowing Python to select which connection via some GUI is definately beyond the scope of this patch)

I propose that the patch be modified to allow the existing scheme of environment variables, and to only go sniffing the registry if this variable doesnt exist.  This will allow _anyone_ to set a variable to get their specific preference at any time, while still allowing the majority of users (ie, IE users with a single internet connection) to not specify this variable, but still work.

Comments please!
-------------------------------------------------------

Date: 2000-Jul-23 23:26
By: nyamatongwe

Comment:
The Navigator/Mozilla proxy information is found in the prefs.js file in the preferred profile directory. The default profile is named "default". It looks like:

user_pref("network.proxy.http", "127.0.0.1");
user_pref("network.proxy.http_port", 8080);
user_pref("network.proxy.type", 1);

Not worth the fiddling IMHO.

This registry key is not just for IE, as it is used by other applications such as WinAmp but this may only be read at install-time. You can change the settings in the Internet Options applet inside the Control Panel.

Looking in the environment first is fine.
-------------------------------------------------------

Date: 2000-Jul-24 00:36
By: mhammond

Comment:
I agree with Bill's comments, although there is no clear place to put the C code necessary to do this.  Further, the point about multiple proxy settings isnt that useful, as we can not predict what internet connection should be used for the proxy settings - we don't have much choice other than to use the default.

However, I just confirmed that Mozilla, for example, doesnt use this registry key.  I assume that Netscape 4.x also doesnt (but I don't have that installed - does anyone know?) So in effect, we are providing a patch that will allow IE users to have their proxy configuration for their default connection to be used.

For non IE users, this patch is a problem, as it provides no technique for overriding the (presumably empty) registry.  And for IE users with multiple connections, this may not be what they want (and allowing Python to select which connection via some GUI is definately beyond the scope of this patch)

I propose that the patch be modified to allow the existing scheme of environment variables, and to only go sniffing the registry if this variable doesnt exist.  This will allow _anyone_ to set a variable to get their specific preference at any time, while still allowing the majority of users (ie, IE users with a single internet connection) to not specify this variable, but still work.

Comments please!
-------------------------------------------------------

Date: 2000-Jul-24 16:16
By: mhammond

Comment:
As discussed, this version uses the environment, and failing that, the registry.

The patch is now a little more intrusive in an attempt to avoid cut-and-paste of the environment logic.  It is now also trivial for the Mac to also use the same "environment first" trick, but I havent touched that!

Has been tested on Windows and vaguely tested on Debian Linux.  Re-assigned to Tim, so he can check the style etc (eg, there is one line that _just_ reaches over 80 chars, and IMO is far more ugly to fix than to leave).  Tim - feel free to reassign back and I will make corrections and checkin if necessary (although Guido explicitly asked that it be assigned to you - obviously you need more work thrown at you <wink>).
-------------------------------------------------------

Date: 2000-Jul-25 23:47
By: tim_one

Comment:
Accepted & assigned back to Mark.  I don't know anything about proxies, so I didn't review that.  Style looks OK to me, and I agree the "long line" isn't an unforgivable sin in this case.  One suggestion:
x    ... name[-6:] == '_proxy'
is clearer as
x    ... name.endswith('_proxy')
Unfortunately, the hard-coded 6 on the line following that one is harder to get rid of.

I'd sure like to see more testing on Linux, but maybe checking it in is the best way to make that happen!

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

Date: 2000-Jul-26 00:00
By: mhammond

Comment:
Thanks Tim.  I have left the hard-coded 6 as-is:  As you mention, the second "6" is harder to remove, but more to the point, this code has existed and worked for ages, and I'm really not in a position to thoroughly test this - I dont have a valid proxy I can use.

Setting to closed, and applying the new version.
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=100873&group_id=5470


From ping@server1.lfw.org  Wed Jul 26 08:19:28 2000
From: ping@server1.lfw.org (Ka-Ping Yee)
Date: Wed, 26 Jul 2000 02:19:28 -0500
Subject: [Patches] #100873: nyamatongwe -> mhammond [Closed] Use registry to find proxies for urllib on Win32
Message-ID: <200007260719.CAA26785@server1.lfw.org>

http://sourceforge.net/patch/?func=detailpatch&patch_id=100873&group_id=5470

Status: Closed
Submitted By: nyamatongwe
Category: None
Summary: Use registry to find proxies for urllib on Win32
Assigned To: mhammond
Patch: View Raw Patch
Date: 2000-Jul-12 19:20

2000-Jul-26 00:00 - mhammond wrote:
    Thanks Tim. I have left the hard-coded 6 as-is: As you mention, the second "6" is harder to remove, but more to the point, this code has existed and worked for ages, and I'm really not in a position to thoroughly test this - I dont have a valid proxy I can use.
    
    Setting to closed, and applying the new version.

2000-Jul-25 23:47 - tim_one wrote:
    Accepted &amp; assigned back to Mark. I don't know anything about proxies, so I didn't review that. Style looks OK to me, and I agree the "long line" isn't an unforgivable sin in this case. One suggestion:
    x ... name[-6:] == '_proxy'
    is clearer as
    x ... name.endswith('_proxy')
    Unfortunately, the hard-coded 6 on the line following that one is harder to get rid of.
    
    I'd sure like to see more testing on Linux, but maybe checking it in is the best way to make that happen!

2000-Jul-24 16:16 - mhammond wrote:
    As discussed, this version uses the environment, and failing that, the registry.
    
    The patch is now a little more intrusive in an attempt to avoid cut-and-paste of the environment logic. It is now also trivial for the Mac to also use the same "environment first" trick, but I havent touched that!
    
    Has been tested on Windows and vaguely tested on Debian Linux. Re-assigned to Tim, so he can check the style etc (eg, there is one line that _just_ reaches over 80 chars, and IMO is far more ugly to fix than to leave). Tim - feel free to reassign back and I will make corrections and checkin if necessary (although Guido explicitly asked that it be assigned to you - obviously you need more work thrown at you <wink>).

2000-Jul-24 00:36 - mhammond wrote:
    I agree with Bill's comments, although there is no clear place to put the C code necessary to do this. Further, the point about multiple proxy settings isnt that useful, as we can not predict what internet connection should be used for the proxy settings - we don't have much choice other than to use the default.
    
    However, I just confirmed that Mozilla, for example, doesnt use this registry key. I assume that Netscape 4.x also doesnt (but I don't have that installed - does anyone know?) So in effect, we are providing a patch that will allow IE users to have their proxy configuration for their default connection to be used.
    
    For non IE users, this patch is a problem, as it provides no technique for overriding the (presumably empty) registry. And for IE users with multiple connections, this may not be what they want (and allowing Python to select which connection via some GUI is definately beyond the scope of this patch)
    
    I propose that the patch be modified to allow the existing scheme of environment variables, and to only go sniffing the registry if this variable doesnt exist. This will allow _anyone_ to set a variable to get their specific preference at any time, while still allowing the majority of users (ie, IE users with a single internet connection) to not specify this variable, but still work.
    
    Comments please!

2000-Jul-23 23:26 - nyamatongwe wrote:
    The Navigator/Mozilla proxy information is found in the prefs.js file in the preferred profile directory. The default profile is named "default". It looks like:
    
    user_pref("network.proxy.http", "127.0.0.1");
    user_pref("network.proxy.http_port", 8080);
    user_pref("network.proxy.type", 1);
    
    Not worth the fiddling IMHO.
    
    This registry key is not just for IE, as it is used by other applications such as WinAmp but this may only be read at install-time. You can change the settings in the Internet Options applet inside the Control Panel.
    
    Looking in the environment first is fine.

2000-Jul-23 21:50 - mhammond wrote:
    I agree with Bill's comments, although there is no clear place to put the C code necessary to do this. Further, the point about multiple proxy settings isnt that useful, as we can not predict what internet connection should be used for the proxy settings - we don't have much choice other than to use the default.
    
    However, I just confirmed that Mozilla, for example, doesnt use this registry key. I assume that Netscape 4.x also doesnt (but I don't have that installed - does anyone know?) So in effect, we are providing a patch that will allow IE users to have their proxy configuration for their default connection to be used.
    
    For non IE users, this patch is a problem, as it provides no technique for overriding the (presumably empty) registry. And for IE users with multiple connections, this may not be what they want (and allowing Python to select which connection via some GUI is definately beyond the scope of this patch)
    
    I propose that the patch be modified to allow the existing scheme of environment variables, and to only go sniffing the registry if this variable doesnt exist. This will allow _anyone_ to set a variable to get their specific preference at any time, while still allowing the majority of users (ie, IE users with a single internet connection) to not specify this variable, but still work.
    
    Comments please!

2000-Jul-17 16:46 - btutt wrote:
    Its better than we have now, but I defiantely dislike using the registry to acquire data when theres an API that exposes the same data.

2000-Jul-15 18:59 - mhammond wrote:
    OK - so it wont be perfect - but are you suggesting that this patch is not an improvement? Even after reading that page, I'm inclined to suggest it is better than the code we have now.

2000-Jul-15 01:07 - btutt wrote:
    Its not that simple....
    See KB #Q226473 that spells out all of the relavent details about why this is a not so good idea:
    
    http://support.microsoft.com/support/kb/articles/Q226/4/73.ASP

2000-Jul-13 07:57 - mhammond wrote:
    Im happy with this patch. I'll be back in Oz in a week - I will test and approve the patch then - if this delay is a problem, I'm happy for it to be re-assigned.

2000-Jul-13 07:45 - moshez wrote:
    I think that if you change the "except", to "except whatever_error_winreg_raises" it should be all right

2000-Jul-12 19:27 - gvanrossum wrote:
    Mark, can you have a look at this? If it's okay, pass it on to Tim. If you don't have time, assign it to Greg.
    
    One immediate problem: a huge block of hairy code inside an unqualified try-except is a no-no!

2000-Jul-26 00:00 - mhammond changed patch_status_id (previously Accepted)
2000-Jul-26 00:00 - mhammond changed close_date (previously 1969-Dec-31 16:00)
2000-Jul-25 23:47 - tim_one changed patch_status_id (previously Open)
2000-Jul-25 23:47 - tim_one changed assigned_to (previously tim_one)
2000-Jul-24 16:16 - mhammond changed Patch Code (previously Modified - New Version)
2000-Jul-24 16:16 - mhammond changed assigned_to (previously mhammond)
2000-Jul-12 19:27 - gvanrossum changed assigned_to (previously none)


From noreply@sourceforge.net  Wed Jul 26 15:12:48 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 26 Jul 2000 07:12:48 -0700
Subject: [Patches] [Patch #100955] ptags, eptags: regex->re, 4 char indent.
Message-ID: <200007261412.HAA12203@delerium.i.sourceforge.net>

Patch #100955 has been updated. 

Project: 
Category: None
Status: Accepted
Summary: ptags, eptags: regex->re, 4 char indent.

Follow-Ups:

Date: 2000-Jul-22 01:35
By: hooft

Comment:
This is another time waster. But now at least I know how a TAGS file is constructed, and I know that re is a lot slower than regex.
-------------------------------------------------------

Date: 2000-Jul-22 23:44
By: moshez

Comment:
I'm not sure that this patch is worth it -- it seems backwards to analyse Python programs with re -- why not simply use the parser module if we really want this?
-------------------------------------------------------

Date: 2000-Jul-25 13:57
By: gvanrossum

Comment:
SRE should be faster again, right?

The parser module is a very big gun for this simple app -- look at it as an example for text processing (and documentation for TAGS files :-).

I say go for it.
-------------------------------------------------------

Date: 2000-Jul-26 07:12
By: moshez

Comment:
Somehow it passed through me, so I added ptags change too.
Anyway, Jeremy, Guido is for this.

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

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=100955&group_id=5470


From noreply@sourceforge.net  Wed Jul 26 15:20:43 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 26 Jul 2000 07:20:43 -0700
Subject: [Patches] [Patch #100974] Vlad's dynamic introspective memory allocator for Python
Message-ID: <200007261420.HAA12425@delerium.i.sourceforge.net>

Patch #100974 has been updated. 

Project: 
Category: None
Status: Open
Summary: Vlad's dynamic introspective memory allocator for Python

Follow-Ups:

Date: 2000-Jul-26 07:20
By: marangoz

Comment:
Thanks for uploading the patch, but I'm not happy with it for the following
reasons:
- some Makefile dependencies are missing
- obmalloc.c should go into Objects/ (or Modules)
- there's a working obmalloc.c~ file in there
- there's no configure option for enabling/disabling it

And the "introspective" thing doesn't hold for the moment, although
I've uploaded to starship a newer version. This is also why I haven't
uploaded a patch myself.

If I can't upload a new patch over this one, I suggest you delete the
patch until I upload a version I'm happy with (or update yours taking into
account the above points).  Thanks.
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=100974&group_id=5470


From noreply@sourceforge.net  Wed Jul 26 16:43:50 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 26 Jul 2000 08:43:50 -0700
Subject: [Patches] [Patch #100974] Vlad's dynamic introspective memory allocator for Python
Message-ID: <200007261543.IAA15350@delerium.i.sourceforge.net>

Patch #100974 has been updated. 

Project: 
Category: None
Status: Rejected
Summary: Vlad's dynamic introspective memory allocator for Python

Follow-Ups:

Date: 2000-Jul-26 07:20
By: marangoz

Comment:
Thanks for uploading the patch, but I'm not happy with it for the following
reasons:
- some Makefile dependencies are missing
- obmalloc.c should go into Objects/ (or Modules)
- there's a working obmalloc.c~ file in there
- there's no configure option for enabling/disabling it

And the "introspective" thing doesn't hold for the moment, although
I've uploaded to starship a newer version. This is also why I haven't
uploaded a patch myself.

If I can't upload a new patch over this one, I suggest you delete the
patch until I upload a version I'm happy with (or update yours taking into
account the above points).  Thanks.
-------------------------------------------------------

Date: 2000-Jul-26 08:43
By: nowonder

Comment:
Waiting for Vladimir uploading a version that will make him more happy.
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=100974&group_id=5470


From noreply@sourceforge.net  Thu Jul 27 03:04:27 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 26 Jul 2000 19:04:27 -0700
Subject: [Patches] [Patch #100890] findall function in sdist.py chokes on broken links
Message-ID: <200007270204.TAB28793@bush.i.sourceforge.net>

Patch #100890 has been updated. 

Project: 
Category: distutils
Status: Rejected
Summary: findall function in sdist.py chokes on broken links

Follow-Ups:

Date: 2000-Jul-15 20:47
By: fdrake

Comment:
Distutils -- assigned to Greg Ward (even though he's on vacation)
-------------------------------------------------------

Date: 2000-Jul-26 19:04
By: gward

Comment:
Not a serious problem; would be nice to warn on broken links, but crashing is acceptable (IMHO).  Also doesn't fix the whole problem: we'd still crash (when making the tree of hardlinks) if the build_py command finds stumbles across a broken link.  And finally, I don't like moving 'findall()' into the sdist class.
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=100890&group_id=5470


From noreply@sourceforge.net  Thu Jul 27 03:05:21 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 26 Jul 2000 19:05:21 -0700
Subject: [Patches] [Patch #100907] Typos distutils
Message-ID: <200007270205.TAA28803@bush.i.sourceforge.net>

Patch #100907 has been updated. 

Project: 
Category: distutils
Status: Open
Summary: Typos distutils

Follow-Ups:

Date: 2000-Jul-18 02:26
By: moshez

Comment:
Greg, this seems all right, though it could use another set of eye balls. You might object to English->American spellings, though they seem (sadly) the standard. 
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=100907&group_id=5470


From noreply@sourceforge.net  Thu Jul 27 03:13:33 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 26 Jul 2000 19:13:33 -0700
Subject: [Patches] [Patch #100907] Typos distutils
Message-ID: <200007270213.TAA29004@bush.i.sourceforge.net>

Patch #100907 has been updated. 

Project: 
Category: distutils
Status: Closed
Summary: Typos distutils

Follow-Ups:

Date: 2000-Jul-18 02:26
By: moshez

Comment:
Greg, this seems all right, though it could use another set of eye balls. You might object to English->American spellings, though they seem (sadly) the standard. 
-------------------------------------------------------

Date: 2000-Jul-26 19:13
By: gward

Comment:
grumble: "behaviour" and "honour" are *not* typos!
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=100907&group_id=5470


From noreply@sourceforge.net  Thu Jul 27 03:15:04 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 26 Jul 2000 19:15:04 -0700
Subject: [Patches] [Patch #100707] Improvement in shlex sourcing facility
Message-ID: <200007270215.TAA03327@delerium.i.sourceforge.net>

Patch #100707 has been updated. 

Project: 
Category: library
Status: Closed
Summary: Improvement in shlex sourcing facility

Follow-Ups:

Date: 2000-Jul-03 02:57
By: fdrake

Comment:
Accepted, with documentation markup adjustments.
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=100707&group_id=5470


From noreply@sourceforge.net  Thu Jul 27 07:48:28 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 26 Jul 2000 23:48:28 -0700
Subject: [Patches] [Patch #100913] Optional pad character (or string) for rjust, ljust
Message-ID: <200007270648.XAA11402@delerium.i.sourceforge.net>

Patch #100913 has been updated. 

Project: 
Category: None
Status: Open
Summary: Optional pad character (or string) for rjust, ljust

Follow-Ups:

Date: 2000-Jul-17 04:45
By: effbot

Comment:
looks fine to me, but you should really change the
unicode string type too (unicodeobject.c)
-------------------------------------------------------

Date: 2000-Jul-17 04:55
By: twouters

Comment:
And don't forget Lib/UserString.py ! :-)
+1 on the patch, though. I always had a nagging feeling this needed fixing, but I've never used it myself, and I thought there was another way to go 'bout it.

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

Date: 2000-Jul-25 07:45
By: jhylton

Comment:
Can you also add code to the test suite to exercise this feature? Look in Lib/test/string_tests.py

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

Date: 2000-Jul-26 23:48
By: moshez

Comment:
The semantics for strings are a bit confusing, and I'm not sure it's worth the complexity. Also, doing it once for strings and once for unicode is a bit redundant, when you can do it in pure Python for both types with ease...wouldn't it be better to to have ljust and rjust (with optional padding) remain in the string module, and make them work on both regular and unicode strings by polymorphism.

def rjust(s, l, pad=' '):
    missing = l-len(s)
    if missing > 0:
        return s+(pad*missing)
    else:
        return s

def ljust(s, l, pad=' '):
    missing = l-len(s)
    if missing > 0:
        return (pad*missing)+s
    else:
        return s

(Or the other way around, could never tell the difference between left and right)

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

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=100913&group_id=5470


From noreply@sourceforge.net  Thu Jul 27 15:18:37 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 27 Jul 2000 07:18:37 -0700
Subject: [Patches] [Patch #100893] new EXTENDED_ARG opcode, elimiate 16-bit oparg limit
Message-ID: <200007271418.HAA25489@delerium.i.sourceforge.net>

Patch #100893 has been updated. 

Project: 
Category: core (C code)
Status: Rejected
Summary: new EXTENDED_ARG opcode, elimiate 16-bit oparg limit

Follow-Ups:

Date: 2000-Jul-15 05:24
By: twouters

Comment:
Can you elaborate on the point of this patch ? It removes the current 32k expression limit, but the cost is pretty high. Is the 32k limit really a problem ? Would a 64k limit, by fixing the current signed-byte problems, suffice ? Also, the patch seems to rely on the fact that ints are always 32bit. That is bound to be an unsafe assumption in the long run.


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

Date: 2000-Jul-15 18:32
By: cgw

Comment:
I don't think it's really true that the cost of
this patch is high.  I did timing tests, on 3
different machines; my (admittedly somewhat
unscientific) test was to run "python pystone.py"
100x and collect statistics on the results, for both
the original and patched Python interpreters.  Values
cited are PyStones.
 
Here are the results: 
============================================= 
On an SGI IRIX64 6.5 IP27 
  built with native compiler MIPSpro Compilers: Version 7.2.1  
 Unpatched:  N=100 mean=2638.05 std. dev.=42.8 
 Patched:    N=100 mean=2656.19 std. dev.=14.8 
 Difference: +0.7% 
 
 built with gcc version 2.95.2 19991024 (release) 
 Unpatched:  N=100 mean=2171.77 std. dev.=8.69 
 Patched:    N=100 mean=2192.73 std. dev.=9.80 
 Difference: +1% 
============================================= 
On a SunOS  5.6  sun4u sparc Ultra-Enterprise 
 built with native compiler WorkShop Compilers 4.2  
 Unpatched:  N=100 mean=1962.32 std dev=29.79 
 Patched:    N=100 mean=1913.84 std dev=8.705 
 Difference: -2.5% 
 built with gcc version 2.95.2 19991024 (release)                        
 Unpatched:  N=100 mean=1859.08 std dev=11.68 
 Patched:    N=100 mean=1939.78 std dev=11.97 
 Difference: +4.3% 
============================================= 
On Linux 2.2.16 SMP  
 built with gcc version 2.95.2 19991024 (release) 
 Unpatched:  N=100 mean=4498.78 std dev=102.61 
 Patched:    N=100 mean=4592.40 std dev=102.38 
 Difference: +2%  
 
I think that looking ahead in the instruction stream
is not costly because the bytecode at instruction n+2
is probably already in the CPU's level 1 or level 2 
cache; if not, "prefetching" this instruction does not
have any adverse affects on performace, because then
this instruction will be available when it is needed
(which will usually be almost immediately).  In many
cases, actually, the code with my patch runs a bit
faster.  I've also reduced the amount of arithmetic required
in the case of little-endian machines - rather than
bit-shifting and adding to get a short out of two bytes,
I simply use a pointer-cast.  Anyhow, try the patch out,
I think the speed difference is negligible.

To answer your other points - yes, I think the 32K limit is
a problem - I've seen cases where machine-generated files are longer than this.  And I'm not too happy with the idea
of replacing a 32K limit with a 64K limit.  

Finally, I don't see where I'm assuming that ints are
always 32 bit - I assume that a long is at least 32
bits, but unless I'm missing something this code will work
just fine on 64-bit machines.

Feedback is of course always welcome....


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

Date: 2000-Jul-16 02:16
By: twouters

Comment:
I wasn't talking as much about speed cost as about complexity cost, but it's good to see that speed cost is negligible. I'm a bit worried that this extra logic in NEXTARG() is a bit too complex, but then I've never come close to the 32k limit, and I don't see a better solution without rewriting the entire instruction stream thing. Isn't it easier to adjust the code-generator to add more groupings ? I'm not sure if that'll work in all cases, though, as I haven't such a code-generator ;)

The reason the patch is `dangerous' is that you rely on ints small enough to represent in 4 bytes: you removed the overflow check, which means that on 64bit machines, if you have more than 2**31 child nodes, you'll generate faulty bytecode.

I'd say Tim or Guido need to take a look at this, and I guess they're too busy packing (or, in  Tim's case, unpacking stuff he doesn't want to take ;) for ORA's OSCON.


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

Date: 2000-Jul-16 16:16
By: cgw

Comment:
It looks like I took out all the overflow checking, but in
fact the code is safe.  com_addbyte in compile.c checks
that its (int) argument is in the range 0<=x<=255.

The checks against SHRT_MAX that my patch removes were only added recently, and are unneccessary if EXTENDED_ARG is 
available.


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

Date: 2000-Jul-27 07:18
By: gvanrossum

Comment:
This will be too slow -- it adds a lot of complexity to the decoding of *each* instruction, and that's the most time-sensitive code in all of ceval.c. I would consider a patch that introduces a new opcode that specifies the high two bytes of oparg as a prefix, repeats the opcode decoding inline,  and then jumps to the top of the switch -- this should only cost when 32-bit opargs are needed (plus a little bit due to code rearrangements, but that's unavoidable).  Pseudo-code:

label:
  switch  (opcode) {
  case LONG_ARG
    realopcode = NEXTOP();
    oparg = oparg<<16 | NEXTARG();
    goto label;
  ...other cases as before...
  }

Thus, for a REAL_OP with a 32-bit oparg, the code generator should generate code like:

  LONG_ARG <high 16 bits of oparg>
  <REAL_OP> <low 16 bits of oparg>
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=100893&group_id=5470


From noreply@sourceforge.net  Thu Jul 27 15:46:54 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 27 Jul 2000 07:46:54 -0700
Subject: [Patches] [Patch #100990] disable partial UTF-16 support in unicodeobject.c
Message-ID: <200007271446.HAA26437@delerium.i.sourceforge.net>

Patch #100990 has been updated. 

Project: 
Category: None
Status: Open
Summary: disable partial UTF-16 support in unicodeobject.c

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=100990&group_id=5470


From noreply@sourceforge.net  Thu Jul 27 20:44:29 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 27 Jul 2000 12:44:29 -0700
Subject: [Patches] [Patch #100994] Allow JPython to use more tests
Message-ID: <200007271944.MAA01537@bush.i.sourceforge.net>

Patch #100994 has been updated. 

Project: 
Category: None
Status: Open
Summary: Allow JPython to use more tests

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=100994&group_id=5470


From noreply@sourceforge.net  Thu Jul 27 20:52:31 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 27 Jul 2000 12:52:31 -0700
Subject: [Patches] [Patch #100994] Allow JPython to use more tests
Message-ID: <200007271952.MAA01389@delerium.i.sourceforge.net>

Patch #100994 has been updated. 

Project: 
Category: library
Status: Accepted
Summary: Allow JPython to use more tests

Follow-Ups:

Date: 2000-Jul-27 12:47
By: bckfnn

Comment:
Several test can almost but not quite be used from JPython. 

test_b1:

JPython does no longer have a strop module. Instead the builtin "time" module is used.

test_exceptions.py:

In JPython the builtin exception does not have type ClassType but type TypeType. 
The TypeType is a subclass of ClassType which make the isinstance work for both pythons.

test_pkg.py:

JPython does not insert __builtins__ in the module namespace. I hope that removing __builtins__ 
from the output does not devaluate the test.

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

Date: 2000-Jul-27 12:52
By: gvanrossum

Comment:
Note that Lib/test/output/test_pkg must be changed too! Regenerate it by running "regrtest.py -g test_pkh".
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=100994&group_id=5470


From noreply@sourceforge.net  Thu Jul 27 21:03:24 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 27 Jul 2000 13:03:24 -0700
Subject: [Patches] [Patch #100740] gzip: readline(), readlines() patch
Message-ID: <200007272003.NAA01899@bush.i.sourceforge.net>

Patch #100740 has been updated. 

Project: 
Category: None
Status: Rejected
Summary: gzip: readline(), readlines() patch

Follow-Ups:

Date: 2000-Jul-05 18:15
By: akuchling

Comment:
Patch from Wolfgang Grafen <wolfgang.grafen@marconicomms.com> that I didn't want to lose.  From his e-mail:

- readline accepts readsize argument
- readlines accepts readsize argument
- readlines accepts optional 'strip_cr' arguments, which is often convenient for me and also speeds up the routine :)

[amk] The strip_cr thing is a non-starter, but I'll look at adding the other changes.
-------------------------------------------------------

Date: 2000-Jul-27 13:03
By: gvanrossum

Comment:
His addition of readsize to readline() doesn't do the same as readline(n) does for regular files -- there it reads at most n characters, period.

The only part of this patch I like is the readsize argument to readlines(), which *does* (roughly) do the same as for regular files.

You can rework this to implement readline(maxread=-1) and readlines(sizehint=0) and then I'd be okay.
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=100740&group_id=5470


From noreply@sourceforge.net  Thu Jul 27 21:04:45 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 27 Jul 2000 13:04:45 -0700
Subject: [Patches] [Patch #100977] This patch makes whichdb recognize Python's dumbdbm database
Message-ID: <200007272004.NAA01660@delerium.i.sourceforge.net>

Patch #100977 has been updated. 

Project: 
Category: library
Status: Rejected
Summary: This patch makes whichdb recognize Python's dumbdbm database

Follow-Ups:

Date: 2000-Jul-25 04:25
By: moshez

Comment:
This patch solves bug 202 on the jitterbug database.
-------------------------------------------------------

Date: 2000-Jul-25 04:46
By: gvanrossum

Comment:
I believe this is not good enough. The original Unix db also has a .dir and .dat, I believe. Isn't there a magical number to test? (I changed status to Rejected; feel free to revert to Open if you upload a new patch. Is this the right protocol?)
-------------------------------------------------------

Date: 2000-Jul-25 06:15
By: moshez

Comment:
New version -- a bit more checking inside the file.
BTW: this fixes 200, not 202. My bad.

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

Date: 2000-Jul-27 13:04
By: gvanrossum

Comment:
Please resubmit, checking for either ' or " as first character.

Then I'm okay with it.
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=100977&group_id=5470


From noreply@sourceforge.net  Thu Jul 27 21:08:30 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 27 Jul 2000 13:08:30 -0700
Subject: [Patches] [Patch #100654] list comprehensions in Python (for 1.7)
Message-ID: <200007272008.NAA01739@delerium.i.sourceforge.net>

Patch #100654 has been updated. 

Project: 
Category: core (C code)
Status: Rejected
Summary: list comprehensions in Python (for 1.7)

Follow-Ups:

Date: 2000-Jun-28 07:07
By: gvanrossum

Comment:
This one's for Tim to thaw later.
-------------------------------------------------------

Date: 2000-Jul-09 15:45
By: twouters

Comment:
The new patch is a CVS diff, which makes it kind of hard to apply (it'll only apply with the right GNU patch, with 'POSIXLY_CORRECT' defined, and with the moon in the right phase, which it currently isn't, apparently ;)
POSIXLY_CORRECT also has some other effects, like that patch refuses to create new files :P Can I ask for a normal recursive-diff so I can recreate the range-list-literal patch relative to this one ?

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

Date: 2000-Jul-24 06:15
By: montanaro

Comment:
This new patch is simply an update to keep up with the recent ANSIfication of the Python source...

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

Date: 2000-Jul-27 13:08
By: gvanrossum

Comment:
I actually like this a lot (am running with it myself!), but the patch needs to be reworked so that it requires [(x,x) for x in ...] instead of allowing [x,x for x in ...].

It also may require integration with the range literals syntax, but that should be relatively minor.
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=100654&group_id=5470


From noreply@sourceforge.net  Thu Jul 27 21:15:20 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 27 Jul 2000 13:15:20 -0700
Subject: [Patches] [Patch #100664] Fix for bug no. 48 (Annoyance in ftpmirror.py script)
Message-ID: <200007272015.NAA02165@bush.i.sourceforge.net>

Patch #100664 has been updated. 

Project: 
Category: demos and tools
Status: Rejected
Summary: Fix for bug no. 48 (Annoyance in ftpmirror.py script)

Follow-Ups:

Date: 2000-Jun-28 13:25
By: karl-sve

Comment:
Added fixes for the other scripts too.
-------------------------------------------------------

Date: 2000-Jun-28 13:46
By: gvanrossum

Comment:
This is trivial stuff, but I'm not too keen on this.

Many of the scripts here really are embarrassing when viewed as modules. Why should we encourage their use as modules? Modules should live inside the Lib tree.
-------------------------------------------------------

Date: 2000-Jun-28 14:12
By: karl-sve

Comment:
Ok, I see your point. Maybe move bug #48 to notabug, or at least post your reply there too?
-------------------------------------------------------

Date: 2000-Jun-29 19:33
By: gvanrossum

Comment:
Since I'm not rejecting it, it's my responsibility to look at it at a later date.
-------------------------------------------------------

Date: 2000-Jul-27 13:15
By: gvanrossum

Comment:
Now I'm rejecting it -- not worth it.  I'll address the bug entry.
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=100664&group_id=5470


From noreply@sourceforge.net  Thu Jul 27 21:18:12 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 27 Jul 2000 13:18:12 -0700
Subject: [Patches] [Patch #100717] Don't link with the libieee library if it's not necessary
Message-ID: <200007272018.NAA02226@bush.i.sourceforge.net>

Patch #100717 has been updated. 

Project: 
Category: None
Status: Accepted
Summary: Don't link with the libieee library if it's not necessary

Follow-Ups:

Date: 2000-Jul-03 16:59
By: tim_one

Comment:
Assigned to Guido, because he loves Unix configuration hassles <ahem>.  This one looks simple.
-------------------------------------------------------

Date: 2000-Jul-27 13:18
By: gvanrossum

Comment:
Jeremy, please check this in (assuming it works).
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=100717&group_id=5470


From noreply@sourceforge.net  Thu Jul 27 21:22:50 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 27 Jul 2000 13:22:50 -0700
Subject: [Patches] [Patch #100720] We don't want to link with libnet on non-BeOS systems
Message-ID: <200007272022.NAA02222@delerium.i.sourceforge.net>

Patch #100720 has been updated. 

Project: 
Category: None
Status: Accepted
Summary: We don't want to link with libnet on non-BeOS systems

Follow-Ups:

Date: 2000-Jul-03 17:18
By: tim_one

Comment:
Assigned to Guido (another short config fix).
-------------------------------------------------------

Date: 2000-Jul-27 13:22
By: gvanrossum

Comment:
Sure, check it in.

(I think this might have been needed on other platforms at some point -- if that's still needed, we'll find out soon enough.)
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=100720&group_id=5470


From noreply@sourceforge.net  Thu Jul 27 21:29:18 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 27 Jul 2000 13:29:18 -0700
Subject: [Patches] [Patch #100853] merging my*.h into pyport.h
Message-ID: <200007272029.NAA02429@delerium.i.sourceforge.net>

Patch #100853 has been updated. 

Project: 
Category: None
Status: Postponed
Summary: merging my*.h into pyport.h

Follow-Ups:

Date: 2000-Jul-11 09:34
By: gvanrossum

Comment:
Python.h already includes pyport.h, so you can eliminate all those #import pyport.h from the .c files. (Not from *all* C files, because a few may not include Python.h, but the majority do.)

Also, please ask Jack Jansen to see if  SYMANTEC_FFM68K and MC68K and other Mac symbols are still wanted.

Maybe much of the Mac-specific madness could be collected in a separate file included only #ifdef macintosh?
-------------------------------------------------------

Date: 2000-Jul-11 09:43
By: gvanrossum

Comment:
Also, you can delete the my*.h files (if indeed there are no references to them any more in the Python core source code).
-------------------------------------------------------

Date: 2000-Jul-11 15:45
By: nowonder

Comment:
Okay, I'll rework the patch. May take some time. Have to do some real work in between python sessions <wink>.
-------------------------------------------------------

Date: 2000-Jul-27 13:29
By: gvanrossum

Comment:
So, it's been a few weeks.  Do you still want to do this?
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=100853&group_id=5470


From noreply@sourceforge.net  Thu Jul 27 21:25:22 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 27 Jul 2000 13:25:22 -0700
Subject: [Patches] [Patch #100851] traceback.py, with unicode exceptions
Message-ID: <200007272025.NAA02560@bush.i.sourceforge.net>

Patch #100851 has been updated. 

Project: 
Category: None
Status: Rejected
Summary: traceback.py, with unicode exceptions

Follow-Ups:

Date: 2000-Jul-11 03:58
By: htrd

Comment:
traceback.py can format an exception as a string - but what happens when an exception is raised during the string conversion?

In this case it is better to discard the inner exception, to allow the original exception to be reported.

The migration to unicode strings makes this quite common. Old code might report a failue with something like....
raise IWasntExpectingThisError('nobody expects %s' % x)

An alternative fix is to change __str__ for exceptions to handle the exception. This would be neater, but I chose to follow the example set by PyErr_PrintEx which has a comment:
/* If an error happened here, don't show it.
   XXX This is wrong, but too many callers rely on this behavior. */

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

Date: 2000-Jul-27 13:25
By: gvanrossum

Comment:
Actually I like this, but instead of the id() of the value you should show its type, e.g. "<unprintable %s object>" % type(value).
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=100851&group_id=5470


From noreply@sourceforge.net  Thu Jul 27 21:27:30 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 27 Jul 2000 13:27:30 -0700
Subject: [Patches] [Patch #100912] modified \x behaviour for unicode strings
Message-ID: <200007272027.NAA02397@delerium.i.sourceforge.net>

Patch #100912 has been updated. 

Project: 
Category: None
Status: Closed
Summary: modified \x behaviour for unicode strings

Follow-Ups:

Date: 2000-Jul-17 07:21
By: effbot

Comment:
(might be reopened when Guido's back from OSCON.  it might be better not to support \x at all...)
-------------------------------------------------------

Date: 2000-Jul-17 12:31
By: lemburg

Comment:
I think that the status "postponed" is the right one for delaying patches or discussions on them. 

I hope you don't mind me fixing the status -- I was looking for your latest developments here after the initial discussion on python-dev.
-------------------------------------------------------

Date: 2000-Jul-27 13:27
By: gvanrossum

Comment:
Effbot already checked this in, so it should be closed.
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=100912&group_id=5470


From noreply@sourceforge.net  Thu Jul 27 21:29:54 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 27 Jul 2000 13:29:54 -0700
Subject: [Patches] [Patch #100654] list comprehensions in Python (for 1.7)
Message-ID: <200007272029.NAA02767@bush.i.sourceforge.net>

Patch #100654 has been updated. 

Project: 
Category: core (C code)
Status: Rejected
Summary: list comprehensions in Python (for 1.7)

Follow-Ups:

Date: 2000-Jun-28 07:07
By: gvanrossum

Comment:
This one's for Tim to thaw later.
-------------------------------------------------------

Date: 2000-Jul-09 15:45
By: twouters

Comment:
The new patch is a CVS diff, which makes it kind of hard to apply (it'll only apply with the right GNU patch, with 'POSIXLY_CORRECT' defined, and with the moon in the right phase, which it currently isn't, apparently ;)
POSIXLY_CORRECT also has some other effects, like that patch refuses to create new files :P Can I ask for a normal recursive-diff so I can recreate the range-list-literal patch relative to this one ?

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

Date: 2000-Jul-24 06:15
By: montanaro

Comment:
This new patch is simply an update to keep up with the recent ANSIfication of the Python source...

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

Date: 2000-Jul-27 13:08
By: gvanrossum

Comment:
I actually like this a lot (am running with it myself!), but the patch needs to be reworked so that it requires [(x,x) for x in ...] instead of allowing [x,x for x in ...].

It also may require integration with the range literals syntax, but that should be relatively minor.
-------------------------------------------------------

Date: 2000-Jul-27 13:29
By: montanaro

Comment:
Okay, the grammar stuff is a little bit beyond me and I don't have the time to investigate it fully at the moment.  
*** Perhaps someone can give me a little direction... ***


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

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=100654&group_id=5470


From noreply@sourceforge.net  Thu Jul 27 22:06:16 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 27 Jul 2000 14:06:16 -0700
Subject: [Patches] [Patch #100717] Don't link with the libieee library if it's not necessary
Message-ID: <200007272106.OAA04153@bush.i.sourceforge.net>

Patch #100717 has been updated. 

Project: 
Category: None
Status: Closed
Summary: Don't link with the libieee library if it's not necessary

Follow-Ups:

Date: 2000-Jul-03 16:59
By: tim_one

Comment:
Assigned to Guido, because he loves Unix configuration hassles <ahem>.  This one looks simple.
-------------------------------------------------------

Date: 2000-Jul-27 13:18
By: gvanrossum

Comment:
Jeremy, please check this in (assuming it works).
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=100717&group_id=5470


From noreply@sourceforge.net  Thu Jul 27 22:06:53 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 27 Jul 2000 14:06:53 -0700
Subject: [Patches] [Patch #100933] base64: move "def test()" into "if __main__" program
Message-ID: <200007272106.OAA03770@delerium.i.sourceforge.net>

Patch #100933 has been updated. 

Project: 
Category: None
Status: Closed
Summary: base64: move "def test()" into "if __main__" program

Follow-Ups:

Date: 2000-Jul-19 01:43
By: effbot

Comment:
why?  it doesn't change anything in real life (the compiler still generates code for that function), except that you can no longer do "import base64; base64.test()"
-------------------------------------------------------

Date: 2000-Jul-19 01:59
By: hooft

Comment:
Exactly. base64.test() actually waits for stdin, which is a bit annoying. I wrote an accompanying message on c.l.py explaining that there are ~20 modules that define a test() this way, some 15 others define _test(). The latter is already a lot better for the unhappy few that use "from base64 import *". But you're right: actually I think the whole test business should be moved to the test-suite, such that no space is taken by dead code in
user programs.
-------------------------------------------------------

Date: 2000-Jul-19 02:47
By: moshez

Comment:
I'm -1 on this patch. test() is useful enough when you import base64. Why deny this functionality? It doesn't save any parsing time for the common case!
-------------------------------------------------------

Date: 2000-Jul-19 02:53
By: hooft

Comment:
Please note that the test() and test1() are undocumented hence surprising. Moving them does not deny any described functionality.
Wow... This patch proposal is generating some comments...
-------------------------------------------------------

Date: 2000-Jul-19 04:33
By: twouters

Comment:
Note that Guido already revoked a patch made by Eric Raymond that did the same (to a different module.) I think we can safely say this one is rejected in advance.

Also, it might break stuff. test() might not be documented, but I think it's bad form to move something just for the hell of it. I'd rather break someone's habit of 'from base64 import *' than the habit of reading a module source and seeing a nifty function that isn't documented externally.

test1(), though, is a different story. I have no problem with renaming that to _test1().
-------------------------------------------------------

Date: 2000-Jul-19 04:40
By: hooft

Comment:
I give up :-) Hope you're all not  too angry with me for spoiling your time. Here is a new version of the patch that just renames test1, and corrects the usage message.
-------------------------------------------------------

Date: 2000-Jul-25 07:35
By: jhylton

Comment:
I applied part of the patch, but did not change the name of test1.  (Applying the adage "If it ain't broke, don't fix it.")

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

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=100933&group_id=5470


From noreply@sourceforge.net  Thu Jul 27 22:27:54 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 27 Jul 2000 14:27:54 -0700
Subject: [Patches] [Patch #100998] experimental support for extended slicing on lists
Message-ID: <200007272127.OAA04564@delerium.i.sourceforge.net>

Patch #100998 has been updated. 

Project: 
Category: core (C code)
Status: Open
Summary: experimental support for extended slicing on lists

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=100998&group_id=5470


From noreply@sourceforge.net  Fri Jul 28 02:58:06 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 27 Jul 2000 18:58:06 -0700
Subject: [Patches] [Patch #101006] fix mmapmodule test failures
Message-ID: <200007280158.SAA13543@delerium.i.sourceforge.net>

Patch #101006 has been updated. 

Project: 
Category: library
Status: Open
Summary: fix mmapmodule test failures

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=101006&group_id=5470


From noreply@sourceforge.net  Fri Jul 28 03:03:04 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 27 Jul 2000 19:03:04 -0700
Subject: [Patches] [Patch #101006] fix mmapmodule test failures
Message-ID: <200007280203.TAA13712@delerium.i.sourceforge.net>

Patch #101006 has been updated. 

Project: 
Category: library
Status: Open
Summary: fix mmapmodule test failures

Follow-Ups:

Date: 2000-Jul-27 19:03
By: mhammond

Comment:
This patch addresses the test_mmap failures on Windows.  Also took the opportunity to clean up the windows code in a few ways.  IMO, the "INT_PTR" casts can also be removed.

This patch:
* Duplicates the mmap file handle, so the Python code can close the file and still allow the mmap file to be resized.
* Ensures that the "tagname" structure element is intialized correctly.
* Ensures that memory is correctly freed in error conditions.
* Ensures we dont call the win32api to free bad resources (we still don't check the results of these functions).

The test code has also been updated to ensure that the resize appears to work - ie, that we can't seek beyond the new size.

This patch has been tested on Windows and Debian 2.2.12

Assigned to Tim, cos he has nothing better to do <wink>.  Im happy to have it assigned back to me for application.
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=101006&group_id=5470


From noreply@sourceforge.net  Fri Jul 28 03:12:27 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 27 Jul 2000 19:12:27 -0700
Subject: [Patches] [Patch #101006] fix mmapmodule test failures
Message-ID: <200007280212.TAA14481@bush.i.sourceforge.net>

Patch #101006 has been updated. 

Project: 
Category: library
Status: Open
Summary: fix mmapmodule test failures

Follow-Ups:

Date: 2000-Jul-27 19:03
By: mhammond

Comment:
This patch addresses the test_mmap failures on Windows.  Also took the opportunity to clean up the windows code in a few ways.  IMO, the "INT_PTR" casts can also be removed.

This patch:
* Duplicates the mmap file handle, so the Python code can close the file and still allow the mmap file to be resized.
* Ensures that the "tagname" structure element is intialized correctly.
* Ensures that memory is correctly freed in error conditions.
* Ensures we dont call the win32api to free bad resources (we still don't check the results of these functions).

The test code has also been updated to ensure that the resize appears to work - ie, that we can't seek beyond the new size.

This patch has been tested on Windows and Debian 2.2.12

Assigned to Tim, cos he has nothing better to do <wink>.  Im happy to have it assigned back to me for application.
-------------------------------------------------------

Date: 2000-Jul-27 19:12
By: mhammond

Comment:
Added a missing Py_DECREF in error condition, and avoided a non-NULL check when we know damn well it aint NULL!
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=101006&group_id=5470


From noreply@sourceforge.net  Fri Jul 28 03:27:05 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 27 Jul 2000 19:27:05 -0700
Subject: [Patches] [Patch #100740] gzip: readline(), readlines() patch
Message-ID: <200007280227.TAA14508@delerium.i.sourceforge.net>

Patch #100740 has been updated. 

Project: 
Category: library
Status: Open
Summary: gzip: readline(), readlines() patch

Follow-Ups:

Date: 2000-Jul-05 18:15
By: akuchling

Comment:
Patch from Wolfgang Grafen <wolfgang.grafen@marconicomms.com> that I didn't want to lose.  From his e-mail:

- readline accepts readsize argument
- readlines accepts readsize argument
- readlines accepts optional 'strip_cr' arguments, which is often convenient for me and also speeds up the routine :)

[amk] The strip_cr thing is a non-starter, but I'll look at adding the other changes.
-------------------------------------------------------

Date: 2000-Jul-27 13:03
By: gvanrossum

Comment:
His addition of readsize to readline() doesn't do the same as readline(n) does for regular files -- there it reads at most n characters, period.

The only part of this patch I like is the readsize argument to readlines(), which *does* (roughly) do the same as for regular files.

You can rework this to implement readline(maxread=-1) and readlines(sizehint=0) and then I'd be okay.
-------------------------------------------------------

Date: 2000-Jul-27 19:27
By: akuchling

Comment:
Completely revised this patch and changed status from 'rejected' to 'open'.  This version gives now the optional
integer arguments to .readline() and .readlines() the same
semantics as they have for regular file objects.  

(The patch also rearranges a few import statements, and completes a sentence fragment in a comment.)

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

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=100740&group_id=5470


From noreply@sourceforge.net  Fri Jul 28 06:50:28 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 27 Jul 2000 22:50:28 -0700
Subject: [Patches] [Patch #100893] new EXTENDED_ARG opcode, elimiate 16-bit oparg limit
Message-ID: <200007280550.WAA21188@bush.i.sourceforge.net>

Patch #100893 has been updated. 

Project: 
Category: core (C code)
Status: Rejected
Summary: new EXTENDED_ARG opcode, elimiate 16-bit oparg limit

Follow-Ups:

Date: 2000-Jul-15 05:24
By: twouters

Comment:
Can you elaborate on the point of this patch ? It removes the current 32k expression limit, but the cost is pretty high. Is the 32k limit really a problem ? Would a 64k limit, by fixing the current signed-byte problems, suffice ? Also, the patch seems to rely on the fact that ints are always 32bit. That is bound to be an unsafe assumption in the long run.


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

Date: 2000-Jul-15 18:32
By: cgw

Comment:
I don't think it's really true that the cost of
this patch is high.  I did timing tests, on 3
different machines; my (admittedly somewhat
unscientific) test was to run "python pystone.py"
100x and collect statistics on the results, for both
the original and patched Python interpreters.  Values
cited are PyStones.
 
Here are the results: 
============================================= 
On an SGI IRIX64 6.5 IP27 
  built with native compiler MIPSpro Compilers: Version 7.2.1  
 Unpatched:  N=100 mean=2638.05 std. dev.=42.8 
 Patched:    N=100 mean=2656.19 std. dev.=14.8 
 Difference: +0.7% 
 
 built with gcc version 2.95.2 19991024 (release) 
 Unpatched:  N=100 mean=2171.77 std. dev.=8.69 
 Patched:    N=100 mean=2192.73 std. dev.=9.80 
 Difference: +1% 
============================================= 
On a SunOS  5.6  sun4u sparc Ultra-Enterprise 
 built with native compiler WorkShop Compilers 4.2  
 Unpatched:  N=100 mean=1962.32 std dev=29.79 
 Patched:    N=100 mean=1913.84 std dev=8.705 
 Difference: -2.5% 
 built with gcc version 2.95.2 19991024 (release)                        
 Unpatched:  N=100 mean=1859.08 std dev=11.68 
 Patched:    N=100 mean=1939.78 std dev=11.97 
 Difference: +4.3% 
============================================= 
On Linux 2.2.16 SMP  
 built with gcc version 2.95.2 19991024 (release) 
 Unpatched:  N=100 mean=4498.78 std dev=102.61 
 Patched:    N=100 mean=4592.40 std dev=102.38 
 Difference: +2%  
 
I think that looking ahead in the instruction stream
is not costly because the bytecode at instruction n+2
is probably already in the CPU's level 1 or level 2 
cache; if not, "prefetching" this instruction does not
have any adverse affects on performace, because then
this instruction will be available when it is needed
(which will usually be almost immediately).  In many
cases, actually, the code with my patch runs a bit
faster.  I've also reduced the amount of arithmetic required
in the case of little-endian machines - rather than
bit-shifting and adding to get a short out of two bytes,
I simply use a pointer-cast.  Anyhow, try the patch out,
I think the speed difference is negligible.

To answer your other points - yes, I think the 32K limit is
a problem - I've seen cases where machine-generated files are longer than this.  And I'm not too happy with the idea
of replacing a 32K limit with a 64K limit.  

Finally, I don't see where I'm assuming that ints are
always 32 bit - I assume that a long is at least 32
bits, but unless I'm missing something this code will work
just fine on 64-bit machines.

Feedback is of course always welcome....


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

Date: 2000-Jul-16 02:16
By: twouters

Comment:
I wasn't talking as much about speed cost as about complexity cost, but it's good to see that speed cost is negligible. I'm a bit worried that this extra logic in NEXTARG() is a bit too complex, but then I've never come close to the 32k limit, and I don't see a better solution without rewriting the entire instruction stream thing. Isn't it easier to adjust the code-generator to add more groupings ? I'm not sure if that'll work in all cases, though, as I haven't such a code-generator ;)

The reason the patch is `dangerous' is that you rely on ints small enough to represent in 4 bytes: you removed the overflow check, which means that on 64bit machines, if you have more than 2**31 child nodes, you'll generate faulty bytecode.

I'd say Tim or Guido need to take a look at this, and I guess they're too busy packing (or, in  Tim's case, unpacking stuff he doesn't want to take ;) for ORA's OSCON.


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

Date: 2000-Jul-16 16:16
By: cgw

Comment:
It looks like I took out all the overflow checking, but in
fact the code is safe.  com_addbyte in compile.c checks
that its (int) argument is in the range 0<=x<=255.

The checks against SHRT_MAX that my patch removes were only added recently, and are unneccessary if EXTENDED_ARG is 
available.


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

Date: 2000-Jul-27 07:18
By: gvanrossum

Comment:
This will be too slow -- it adds a lot of complexity to the decoding of *each* instruction, and that's the most time-sensitive code in all of ceval.c. I would consider a patch that introduces a new opcode that specifies the high two bytes of oparg as a prefix, repeats the opcode decoding inline,  and then jumps to the top of the switch -- this should only cost when 32-bit opargs are needed (plus a little bit due to code rearrangements, but that's unavoidable).  Pseudo-code:

label:
  switch  (opcode) {
  case LONG_ARG
    realopcode = NEXTOP();
    oparg = oparg<<16 | NEXTARG();
    goto label;
  ...other cases as before...
  }

Thus, for a REAL_OP with a 32-bit oparg, the code generator should generate code like:

  LONG_ARG <high 16 bits of oparg>
  <REAL_OP> <low 16 bits of oparg>
-------------------------------------------------------

Date: 2000-Jul-27 22:50
By: tim_one

Comment:
Sorry, guys -- there was so much email today that I didn't even see this until now.

Yes, I saw the timing results, and wasn't surprised.  As the one one-time professional optimization guy <wink> hanging out on c.l.py, I get sucked into these things a lot.  Across architectures and compilers, there's no way to predict whether a small change will speed up or slow down.  And ceval.c pushes current combos to their limits:  Marc-Andre once put an *unexecuted* printf into the main loop and measured a ~15% slowdown on his combo as a result.  On my combo, it appeared to yield a slight speedup.

That doesn't mean it's hopeless, though!  Over time, the length of the critical path through the code is the best predictor of how well compilers and architectures will eventually perform.  Reduce the operation count on the critical path, and you almost always win in the end; increase it, and you almost always lose.  That's my real objection to the original patch:  instruction decode *is* on the critical path, and sticking another test+branch in there is a long-term loser no matter what tests say today on a handful of combos.  Optimizers get better over time, and architectures reward simpler code over time.

Greg Ewing had another interesting suggestion on c.l.py today:  don't even fetch the second byte of 2-byte instructions at the top of loop; wait until you're in the cases that actually need the next byte.  The amount of code duplication in that is unattractive, though, and the switch in ceval is definitely fat enough that 2nd-order effects like instruction cache behavior can make a real difference (indeed, that's what I believe was going on with Marc-Andre's passive printf).

BTW, you cannot assume that a short is 2 bytes!  Python runs on machines where sizeof(short) == 8.

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

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=100893&group_id=5470


From noreply@sourceforge.net  Fri Jul 28 10:00:48 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 28 Jul 2000 02:00:48 -0700
Subject: [Patches] [Patch #100853] merging my*.h into pyport.h
Message-ID: <200007280900.CAA26558@delerium.i.sourceforge.net>

Patch #100853 has been updated. 

Project: 
Category: None
Status: Postponed
Summary: merging my*.h into pyport.h

Follow-Ups:

Date: 2000-Jul-11 09:34
By: gvanrossum

Comment:
Python.h already includes pyport.h, so you can eliminate all those #import pyport.h from the .c files. (Not from *all* C files, because a few may not include Python.h, but the majority do.)

Also, please ask Jack Jansen to see if  SYMANTEC_FFM68K and MC68K and other Mac symbols are still wanted.

Maybe much of the Mac-specific madness could be collected in a separate file included only #ifdef macintosh?
-------------------------------------------------------

Date: 2000-Jul-11 09:43
By: gvanrossum

Comment:
Also, you can delete the my*.h files (if indeed there are no references to them any more in the Python core source code).
-------------------------------------------------------

Date: 2000-Jul-11 15:45
By: nowonder

Comment:
Okay, I'll rework the patch. May take some time. Have to do some real work in between python sessions <wink>.
-------------------------------------------------------

Date: 2000-Jul-27 13:29
By: gvanrossum

Comment:
So, it's been a few weeks.  Do you still want to do this?
-------------------------------------------------------

Date: 2000-Jul-28 02:00
By: nowonder

Comment:
Yes. I just wanted to wait until Thomas has dealt with that platform specific clutter.

It's on my list for next week. Maybe that means I'll do something about it ...
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=100853&group_id=5470


From noreply@sourceforge.net  Fri Jul 28 11:25:36 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 28 Jul 2000 03:25:36 -0700
Subject: [Patches] [Patch #100740] gzip: readline(), readlines() patch
Message-ID: <200007281025.DAA28944@delerium.i.sourceforge.net>

Patch #100740 has been updated. 

Project: 
Category: library
Status: Rejected
Summary: gzip: readline(), readlines() patch

Follow-Ups:

Date: 2000-Jul-05 18:15
By: akuchling

Comment:
Patch from Wolfgang Grafen <wolfgang.grafen@marconicomms.com> that I didn't want to lose.  From his e-mail:

- readline accepts readsize argument
- readlines accepts readsize argument
- readlines accepts optional 'strip_cr' arguments, which is often convenient for me and also speeds up the routine :)

[amk] The strip_cr thing is a non-starter, but I'll look at adding the other changes.
-------------------------------------------------------

Date: 2000-Jul-27 13:03
By: gvanrossum

Comment:
His addition of readsize to readline() doesn't do the same as readline(n) does for regular files -- there it reads at most n characters, period.

The only part of this patch I like is the readsize argument to readlines(), which *does* (roughly) do the same as for regular files.

You can rework this to implement readline(maxread=-1) and readlines(sizehint=0) and then I'd be okay.
-------------------------------------------------------

Date: 2000-Jul-27 19:27
By: akuchling

Comment:
Completely revised this patch and changed status from 'rejected' to 'open'.  This version gives now the optional
integer arguments to .readline() and .readlines() the same
semantics as they have for regular file objects.  

(The patch also rearranges a few import statements, and completes a sentence fragment in a comment.)

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

Date: 2000-Jul-28 03:25
By: gvanrossum

Comment:
Almost right.  The docs for file objects specifically imply that a negative arg to readline() or a zero arg to readlines() is the same as no args; your defaults are sys.maxint so an explicit -1 or 0 won't do the right thing. (This is important for wrapper classes that want to implement the same conventions.)

This is my only objection; you can check it in if you fix this.
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=100740&group_id=5470


From noreply@sourceforge.net  Fri Jul 28 13:41:57 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 28 Jul 2000 05:41:57 -0700
Subject: [Patches] [Patch #100740] gzip: readline(), readlines() patch
Message-ID: <200007281241.FAA00475@delerium.i.sourceforge.net>

Patch #100740 has been updated. 

Project: 
Category: library
Status: Open
Summary: gzip: readline(), readlines() patch

Follow-Ups:

Date: 2000-Jul-05 18:15
By: akuchling

Comment:
Patch from Wolfgang Grafen <wolfgang.grafen@marconicomms.com> that I didn't want to lose.  From his e-mail:

- readline accepts readsize argument
- readlines accepts readsize argument
- readlines accepts optional 'strip_cr' arguments, which is often convenient for me and also speeds up the routine :)

[amk] The strip_cr thing is a non-starter, but I'll look at adding the other changes.
-------------------------------------------------------

Date: 2000-Jul-27 13:03
By: gvanrossum

Comment:
His addition of readsize to readline() doesn't do the same as readline(n) does for regular files -- there it reads at most n characters, period.

The only part of this patch I like is the readsize argument to readlines(), which *does* (roughly) do the same as for regular files.

You can rework this to implement readline(maxread=-1) and readlines(sizehint=0) and then I'd be okay.
-------------------------------------------------------

Date: 2000-Jul-27 19:27
By: akuchling

Comment:
Completely revised this patch and changed status from 'rejected' to 'open'.  This version gives now the optional
integer arguments to .readline() and .readlines() the same
semantics as they have for regular file objects.  

(The patch also rearranges a few import statements, and completes a sentence fragment in a comment.)

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

Date: 2000-Jul-28 03:25
By: gvanrossum

Comment:
Almost right.  The docs for file objects specifically imply that a negative arg to readline() or a zero arg to readlines() is the same as no args; your defaults are sys.maxint so an explicit -1 or 0 won't do the right thing. (This is important for wrapper classes that want to implement the same conventions.)

This is my only objection; you can check it in if you fix this.
-------------------------------------------------------

Date: 2000-Jul-28 05:41
By: akuchling

Comment:
Two-line change to give -1 and 0 the correct semantics
for readline and readlines.  
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=100740&group_id=5470


From noreply@sourceforge.net  Fri Jul 28 14:39:15 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 28 Jul 2000 06:39:15 -0700
Subject: [Patches] [Patch #100740] gzip: readline(), readlines() patch
Message-ID: <200007281339.GAA02391@delerium.i.sourceforge.net>

Patch #100740 has been updated. 

Project: 
Category: library
Status: Open
Summary: gzip: readline(), readlines() patch

Follow-Ups:

Date: 2000-Jul-05 18:15
By: akuchling

Comment:
Patch from Wolfgang Grafen <wolfgang.grafen@marconicomms.com> that I didn't want to lose.  From his e-mail:

- readline accepts readsize argument
- readlines accepts readsize argument
- readlines accepts optional 'strip_cr' arguments, which is often convenient for me and also speeds up the routine :)

[amk] The strip_cr thing is a non-starter, but I'll look at adding the other changes.
-------------------------------------------------------

Date: 2000-Jul-27 13:03
By: gvanrossum

Comment:
His addition of readsize to readline() doesn't do the same as readline(n) does for regular files -- there it reads at most n characters, period.

The only part of this patch I like is the readsize argument to readlines(), which *does* (roughly) do the same as for regular files.

You can rework this to implement readline(maxread=-1) and readlines(sizehint=0) and then I'd be okay.
-------------------------------------------------------

Date: 2000-Jul-27 19:27
By: akuchling

Comment:
Completely revised this patch and changed status from 'rejected' to 'open'.  This version gives now the optional
integer arguments to .readline() and .readlines() the same
semantics as they have for regular file objects.  

(The patch also rearranges a few import statements, and completes a sentence fragment in a comment.)

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

Date: 2000-Jul-28 03:25
By: gvanrossum

Comment:
Almost right.  The docs for file objects specifically imply that a negative arg to readline() or a zero arg to readlines() is the same as no args; your defaults are sys.maxint so an explicit -1 or 0 won't do the right thing. (This is important for wrapper classes that want to implement the same conventions.)

This is my only objection; you can check it in if you fix this.
-------------------------------------------------------

Date: 2000-Jul-28 05:41
By: akuchling

Comment:
Two-line change to give -1 and 0 the correct semantics
for readline and readlines.  
-------------------------------------------------------

Date: 2000-Jul-28 06:39
By: gvanrossum

Comment:
Argh!  You seem to have reversed the -1 and 0.  (I apologize for the confusion.)

The default is readline(-1), readlines(0).
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=100740&group_id=5470


From postbox@counter4all.com  Fri Jul 28 15:28:17 2000
From: postbox@counter4all.com (postbox@counter4all.com)
Date: Fri, 28 Jul 2000 16:28:17 +0200
Subject: [Patches] RE: Professional statistics for your homepage
Message-ID: <PLUTOcioPo9dFtMwk9I0000102c@www.counter4all.dk>

Hi patches@python.org

Check http://www.counter4all.com/omcounter.asp



From noreply@sourceforge.net  Fri Jul 28 17:25:16 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 28 Jul 2000 09:25:16 -0700
Subject: [Patches] [Patch #100740] gzip: readline(), readlines() patch
Message-ID: <200007281625.JAA08775@bush.i.sourceforge.net>

Patch #100740 has been updated. 

Project: 
Category: library
Status: Open
Summary: gzip: readline(), readlines() patch

Follow-Ups:

Date: 2000-Jul-05 18:15
By: akuchling

Comment:
Patch from Wolfgang Grafen <wolfgang.grafen@marconicomms.com> that I didn't want to lose.  From his e-mail:

- readline accepts readsize argument
- readlines accepts readsize argument
- readlines accepts optional 'strip_cr' arguments, which is often convenient for me and also speeds up the routine :)

[amk] The strip_cr thing is a non-starter, but I'll look at adding the other changes.
-------------------------------------------------------

Date: 2000-Jul-27 13:03
By: gvanrossum

Comment:
His addition of readsize to readline() doesn't do the same as readline(n) does for regular files -- there it reads at most n characters, period.

The only part of this patch I like is the readsize argument to readlines(), which *does* (roughly) do the same as for regular files.

You can rework this to implement readline(maxread=-1) and readlines(sizehint=0) and then I'd be okay.
-------------------------------------------------------

Date: 2000-Jul-27 19:27
By: akuchling

Comment:
Completely revised this patch and changed status from 'rejected' to 'open'.  This version gives now the optional
integer arguments to .readline() and .readlines() the same
semantics as they have for regular file objects.  

(The patch also rearranges a few import statements, and completes a sentence fragment in a comment.)

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

Date: 2000-Jul-28 03:25
By: gvanrossum

Comment:
Almost right.  The docs for file objects specifically imply that a negative arg to readline() or a zero arg to readlines() is the same as no args; your defaults are sys.maxint so an explicit -1 or 0 won't do the right thing. (This is important for wrapper classes that want to implement the same conventions.)

This is my only objection; you can check it in if you fix this.
-------------------------------------------------------

Date: 2000-Jul-28 05:41
By: akuchling

Comment:
Two-line change to give -1 and 0 the correct semantics
for readline and readlines.  
-------------------------------------------------------

Date: 2000-Jul-28 06:39
By: gvanrossum

Comment:
Argh!  You seem to have reversed the -1 and 0.  (I apologize for the confusion.)

The default is readline(-1), readlines(0).
-------------------------------------------------------

Date: 2000-Jul-28 09:25
By: akuchling

Comment:
Revised patch to swap the default values.

I also want to beef up the test suite to exercise the new functionality --
will work on that tonight.
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=100740&group_id=5470


From noreply@sourceforge.net  Fri Jul 28 20:55:16 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 28 Jul 2000 12:55:16 -0700
Subject: [Patches] [Patch #101010] replace use of INT_PTR with uintptr_t (fix MSVC 5.0 build)
Message-ID: <200007281955.MAA16058@bush.i.sourceforge.net>

Patch #101010 has been updated. 

Project: 
Category: core (C code)
Status: Open
Summary: replace use of INT_PTR with uintptr_t (fix MSVC 5.0 build)

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=101010&group_id=5470


From noreply@sourceforge.net  Fri Jul 28 20:58:46 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 28 Jul 2000 12:58:46 -0700
Subject: [Patches] [Patch #101010] replace use of INT_PTR with uintptr_t (fix MSVC 5.0 build)
Message-ID: <200007281958.MAA16203@bush.i.sourceforge.net>

Patch #101010 has been updated. 

Project: 
Category: core (C code)
Status: Open
Summary: replace use of INT_PTR with uintptr_t (fix MSVC 5.0 build)

Follow-Ups:

Date: 2000-Jul-28 12:58
By: tmick

Comment:
This replaces a stopgap fix for MSVC 5.0 building of thread_nt.h by Fredrik. See the thread on python-dev:
http://www.python.org/pipermail/python-dev/2000-June/011766.html

Fredrik, could you see if this patch works for you (compiling with MSVC 5.0) and then assign it back to me?

Thanks
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=101010&group_id=5470


From noreply@sourceforge.net  Sat Jul 29 21:15:56 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 29 Jul 2000 13:15:56 -0700
Subject: [Patches] [Patch #100740] gzip: readline(), readlines() patch
Message-ID: <200007292015.NAA28087@delerium.i.sourceforge.net>

Patch #100740 has been updated. 

Project: 
Category: library
Status: Closed
Summary: gzip: readline(), readlines() patch

Follow-Ups:

Date: 2000-Jul-05 18:15
By: akuchling

Comment:
Patch from Wolfgang Grafen <wolfgang.grafen@marconicomms.com> that I didn't want to lose.  From his e-mail:

- readline accepts readsize argument
- readlines accepts readsize argument
- readlines accepts optional 'strip_cr' arguments, which is often convenient for me and also speeds up the routine :)

[amk] The strip_cr thing is a non-starter, but I'll look at adding the other changes.
-------------------------------------------------------

Date: 2000-Jul-27 13:03
By: gvanrossum

Comment:
His addition of readsize to readline() doesn't do the same as readline(n) does for regular files -- there it reads at most n characters, period.

The only part of this patch I like is the readsize argument to readlines(), which *does* (roughly) do the same as for regular files.

You can rework this to implement readline(maxread=-1) and readlines(sizehint=0) and then I'd be okay.
-------------------------------------------------------

Date: 2000-Jul-27 19:27
By: akuchling

Comment:
Completely revised this patch and changed status from 'rejected' to 'open'.  This version gives now the optional
integer arguments to .readline() and .readlines() the same
semantics as they have for regular file objects.  

(The patch also rearranges a few import statements, and completes a sentence fragment in a comment.)

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

Date: 2000-Jul-28 03:25
By: gvanrossum

Comment:
Almost right.  The docs for file objects specifically imply that a negative arg to readline() or a zero arg to readlines() is the same as no args; your defaults are sys.maxint so an explicit -1 or 0 won't do the right thing. (This is important for wrapper classes that want to implement the same conventions.)

This is my only objection; you can check it in if you fix this.
-------------------------------------------------------

Date: 2000-Jul-28 05:41
By: akuchling

Comment:
Two-line change to give -1 and 0 the correct semantics
for readline and readlines.  
-------------------------------------------------------

Date: 2000-Jul-28 06:39
By: gvanrossum

Comment:
Argh!  You seem to have reversed the -1 and 0.  (I apologize for the confusion.)

The default is readline(-1), readlines(0).
-------------------------------------------------------

Date: 2000-Jul-28 09:25
By: akuchling

Comment:
Revised patch to swap the default values.

I also want to beef up the test suite to exercise the new functionality --
will work on that tonight.
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=100740&group_id=5470


From noreply@sourceforge.net  Sun Jul 30 02:34:12 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 29 Jul 2000 18:34:12 -0700
Subject: [Patches] [Patch #100673] minor fix to make 1.6 compile under MSVC 5.0
Message-ID: <200007300134.SAA04988@delerium.i.sourceforge.net>

Patch #100673 has been updated. 

Project: 
Category: None
Status: Closed
Summary: minor fix to make 1.6 compile under MSVC 5.0

Follow-Ups:

Date: 2000-Jun-29 03:27
By: effbot

Comment:
note that in the MSDN documentation, and in the 5.0
header files, the return value is declared to be an
"unsigned long".

maybe INT_PTR is just plain wrong?
-------------------------------------------------------

Date: 2000-Jun-29 10:29
By: effbot

Comment:
committed (as a stopgap measure for 1.6b1).  hopefully,
trent will come up with a cleaner solution.
-------------------------------------------------------

Date: 2000-Jun-29 17:32
By: tim_one

Comment:
Assigned this to Trent, since I didn't commit it and the next step is in Trent's court.

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

Date: 2000-Jul-29 18:34
By: tmick

Comment:
I came up with a cleaner solution, as promised to Guido. See:

http://sourceforge.net/patch/?func=detailpatch&patch_id=101010&group_id=5470
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=100673&group_id=5470


From noreply@sourceforge.net  Sun Jul 30 03:15:52 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 29 Jul 2000 19:15:52 -0700
Subject: [Patches] [Patch #101006] fix mmapmodule test failures
Message-ID: <200007300215.TAA07438@bush.i.sourceforge.net>

Patch #101006 has been updated. 

Project: 
Category: library
Status: Accepted
Summary: fix mmapmodule test failures

Follow-Ups:

Date: 2000-Jul-27 19:03
By: mhammond

Comment:
This patch addresses the test_mmap failures on Windows.  Also took the opportunity to clean up the windows code in a few ways.  IMO, the "INT_PTR" casts can also be removed.

This patch:
* Duplicates the mmap file handle, so the Python code can close the file and still allow the mmap file to be resized.
* Ensures that the "tagname" structure element is intialized correctly.
* Ensures that memory is correctly freed in error conditions.
* Ensures we dont call the win32api to free bad resources (we still don't check the results of these functions).

The test code has also been updated to ensure that the resize appears to work - ie, that we can't seek beyond the new size.

This patch has been tested on Windows and Debian 2.2.12

Assigned to Tim, cos he has nothing better to do <wink>.  Im happy to have it assigned back to me for application.
-------------------------------------------------------

Date: 2000-Jul-27 19:12
By: mhammond

Comment:
Added a missing Py_DECREF in error condition, and avoided a non-NULL check when we know damn well it aint NULL!
-------------------------------------------------------

Date: 2000-Jul-29 19:15
By: mhammond

Comment:
Reassigning to myself - Ive gotta get more in the habit of "commit now, repent later" <wink>
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=101006&group_id=5470


From noreply@sourceforge.net  Sun Jul 30 03:22:59 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 29 Jul 2000 19:22:59 -0700
Subject: [Patches] [Patch #101006] fix mmapmodule test failures
Message-ID: <200007300222.TAA07689@bush.i.sourceforge.net>

Patch #101006 has been updated. 

Project: 
Category: library
Status: Closed
Summary: fix mmapmodule test failures

Follow-Ups:

Date: 2000-Jul-27 19:03
By: mhammond

Comment:
This patch addresses the test_mmap failures on Windows.  Also took the opportunity to clean up the windows code in a few ways.  IMO, the "INT_PTR" casts can also be removed.

This patch:
* Duplicates the mmap file handle, so the Python code can close the file and still allow the mmap file to be resized.
* Ensures that the "tagname" structure element is intialized correctly.
* Ensures that memory is correctly freed in error conditions.
* Ensures we dont call the win32api to free bad resources (we still don't check the results of these functions).

The test code has also been updated to ensure that the resize appears to work - ie, that we can't seek beyond the new size.

This patch has been tested on Windows and Debian 2.2.12

Assigned to Tim, cos he has nothing better to do <wink>.  Im happy to have it assigned back to me for application.
-------------------------------------------------------

Date: 2000-Jul-27 19:12
By: mhammond

Comment:
Added a missing Py_DECREF in error condition, and avoided a non-NULL check when we know damn well it aint NULL!
-------------------------------------------------------

Date: 2000-Jul-29 19:15
By: mhammond

Comment:
Reassigning to myself - Ive gotta get more in the habit of "commit now, repent later" <wink>
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=101006&group_id=5470


From noreply@sourceforge.net  Sun Jul 30 09:16:55 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 30 Jul 2000 01:16:55 -0700
Subject: [Patches] [Patch #101019] Opcode reordering
Message-ID: <200007300816.BAA16317@delerium.i.sourceforge.net>

Patch #101019 has been updated. 

Project: 
Category: core (C code)
Status: Open
Summary: Opcode reordering

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=101019&group_id=5470


From noreply@sourceforge.net  Sun Jul 30 09:34:19 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 30 Jul 2000 01:34:19 -0700
Subject: [Patches] [Patch #101019] Opcode reordering
Message-ID: <200007300834.BAA18030@bush.i.sourceforge.net>

Patch #101019 has been updated. 

Project: 
Category: core (C code)
Status: Open
Summary: Opcode reordering

Follow-Ups:

Date: 2000-Jul-30 01:34
By: marangoz

Comment:
Mainly for peace of mind - as discussed on python-dev,
aims at reducing cache effects.

The Top5 opcodes have been moved to the beginning of
the main loop, ordered by decreasing frequency according
to DXP and MAL's statistics.

LOAD_FAST & LOAD_CONST have been slightly tweaked
so that the code sequence is 'unique' amongst the other opcodes.
Otherwise, the optimizer is likely to generate a jump to another
common block later in the loop which obviates the whole point
of moving these opcodes to the top.

- The condition in LOAD_FAST is inversed
- LOAD_CONST has been changed from 'break' to 'continue'.
   Indeed, if x == NULL, we would have dumped core at the
   Py_INCREF(x) preceding the break...

Some testing on Lunix, Solaris and AIX shows no slowdowns <wink>.
There seems to be some speedup, but in some cases it is barely
noticeable.

I dropped the idea of folding opcodes. The bahavior is unpredictable.
If someone wants to spend her entire life between balancing caching
and pipelining in ceval.c, no problem <wink>. I'm out of this game.

As usual, please test (notably on Windows)
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=101019&group_id=5470


From noreply@sourceforge.net  Sun Jul 30 10:30:20 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 30 Jul 2000 02:30:20 -0700
Subject: [Patches] [Patch #101006] fix mmapmodule test failures
Message-ID: <200007300930.CAA18222@delerium.i.sourceforge.net>

Patch #101006 has been updated. 

Project: 
Category: library
Status: Closed
Summary: fix mmapmodule test failures

Follow-Ups:

Date: 2000-Jul-27 19:03
By: mhammond

Comment:
This patch addresses the test_mmap failures on Windows.  Also took the opportunity to clean up the windows code in a few ways.  IMO, the "INT_PTR" casts can also be removed.

This patch:
* Duplicates the mmap file handle, so the Python code can close the file and still allow the mmap file to be resized.
* Ensures that the "tagname" structure element is intialized correctly.
* Ensures that memory is correctly freed in error conditions.
* Ensures we dont call the win32api to free bad resources (we still don't check the results of these functions).

The test code has also been updated to ensure that the resize appears to work - ie, that we can't seek beyond the new size.

This patch has been tested on Windows and Debian 2.2.12

Assigned to Tim, cos he has nothing better to do <wink>.  Im happy to have it assigned back to me for application.
-------------------------------------------------------

Date: 2000-Jul-27 19:12
By: mhammond

Comment:
Added a missing Py_DECREF in error condition, and avoided a non-NULL check when we know damn well it aint NULL!
-------------------------------------------------------

Date: 2000-Jul-29 19:15
By: mhammond

Comment:
Reassigning to myself - Ive gotta get more in the habit of "commit now, repent later" <wink>
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=101006&group_id=5470


From noreply@sourceforge.net  Mon Jul 31 00:08:45 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 30 Jul 2000 16:08:45 -0700
Subject: [Patches] [Patch #101022] Removal of SET_LINENO (experimental)
Message-ID: <200007302308.QAA13461@delerium.i.sourceforge.net>

Patch #101022 has been updated. 

Project: 
Category: core (C code)
Status: Open
Summary: Removal of SET_LINENO (experimental)

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=101022&group_id=5470


From noreply@sourceforge.net  Mon Jul 31 00:12:33 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 30 Jul 2000 16:12:33 -0700
Subject: [Patches] [Patch #101022] Removal of SET_LINENO (experimental)
Message-ID: <200007302312.QAA14621@bush.i.sourceforge.net>

Patch #101022 has been updated. 

Project: 
Category: core (C code)
Status: Open
Summary: Removal of SET_LINENO (experimental)

Follow-Ups:

Date: 2000-Jul-30 16:12
By: marangoz

Comment:
For testing, as discussed on python-dev. For a gentle summary, see:
http://www.python.org/pipermail/python-dev/2000-July/014364.html

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

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=101022&group_id=5470


From noreply@sourceforge.net  Mon Jul 31 02:16:08 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 30 Jul 2000 18:16:08 -0700
Subject: [Patches] [Patch #101022] Removal of SET_LINENO (experimental)
Message-ID: <200007310116.SAA17277@delerium.i.sourceforge.net>

Patch #101022 has been updated. 

Project: 
Category: core (C code)
Status: Open
Summary: Removal of SET_LINENO (experimental)

Follow-Ups:

Date: 2000-Jul-30 16:12
By: marangoz

Comment:
For testing, as discussed on python-dev. For a gentle summary, see:
http://www.python.org/pipermail/python-dev/2000-July/014364.html

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

Date: 2000-Jul-30 18:16
By: marangoz

Comment:
A nit: inline the argfetch in CALL_TRACE and goto the switch,
instead of jumping to get_oparg which splits the sequence
[fetch opcode, fetch oparg] -- this can slow things down.

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

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=101022&group_id=5470


From noreply@sourceforge.net  Mon Jul 31 07:12:33 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 30 Jul 2000 23:12:33 -0700
Subject: [Patches] [Patch #100872] change SimpleHTTPServer to use copyfileobj to copy files
Message-ID: <200007310612.XAA27258@bush.i.sourceforge.net>

Patch #100872 has been updated. 

Project: 
Category: None
Status: Closed
Summary: change SimpleHTTPServer to use copyfileobj to copy files

Follow-Ups:

Date: 2000-Jul-12 08:21
By: gvanrossum

Comment:
OK, but check your indentation -- seems to be a tab/space issue.
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=100872&group_id=5470


From noreply@sourceforge.net  Mon Jul 31 07:13:14 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 30 Jul 2000 23:13:14 -0700
Subject: [Patches] [Patch #100977] This patch makes whichdb recognize Python's dumbdbm database
Message-ID: <200007310613.XAA27274@bush.i.sourceforge.net>

Patch #100977 has been updated. 

Project: 
Category: library
Status: Closed
Summary: This patch makes whichdb recognize Python's dumbdbm database

Follow-Ups:

Date: 2000-Jul-25 04:25
By: moshez

Comment:
This patch solves bug 202 on the jitterbug database.
-------------------------------------------------------

Date: 2000-Jul-25 04:46
By: gvanrossum

Comment:
I believe this is not good enough. The original Unix db also has a .dir and .dat, I believe. Isn't there a magical number to test? (I changed status to Rejected; feel free to revert to Open if you upload a new patch. Is this the right protocol?)
-------------------------------------------------------

Date: 2000-Jul-25 06:15
By: moshez

Comment:
New version -- a bit more checking inside the file.
BTW: this fixes 200, not 202. My bad.

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

Date: 2000-Jul-27 13:04
By: gvanrossum

Comment:
Please resubmit, checking for either ' or " as first character.

Then I'm okay with it.
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=100977&group_id=5470


From noreply@sourceforge.net  Mon Jul 31 09:40:37 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 31 Jul 2000 01:40:37 -0700
Subject: [Patches] [Patch #100853] merging my*.h into pyport.h
Message-ID: <200007310840.BAA30495@delerium.i.sourceforge.net>

Patch #100853 has been updated. 

Project: 
Category: core (C code)
Status: Open
Summary: merging my*.h into pyport.h

Follow-Ups:

Date: 2000-Jul-11 09:34
By: gvanrossum

Comment:
Python.h already includes pyport.h, so you can eliminate all those #import pyport.h from the .c files. (Not from *all* C files, because a few may not include Python.h, but the majority do.)

Also, please ask Jack Jansen to see if  SYMANTEC_FFM68K and MC68K and other Mac symbols are still wanted.

Maybe much of the Mac-specific madness could be collected in a separate file included only #ifdef macintosh?
-------------------------------------------------------

Date: 2000-Jul-11 09:43
By: gvanrossum

Comment:
Also, you can delete the my*.h files (if indeed there are no references to them any more in the Python core source code).
-------------------------------------------------------

Date: 2000-Jul-11 15:45
By: nowonder

Comment:
Okay, I'll rework the patch. May take some time. Have to do some real work in between python sessions <wink>.
-------------------------------------------------------

Date: 2000-Jul-27 13:29
By: gvanrossum

Comment:
So, it's been a few weeks.  Do you still want to do this?
-------------------------------------------------------

Date: 2000-Jul-28 02:00
By: nowonder

Comment:
Yes. I just wanted to wait until Thomas has dealt with that platform specific clutter.

It's on my list for next week. Maybe that means I'll do something about it ...
-------------------------------------------------------

Date: 2000-Jul-31 01:40
By: nowonder

Comment:
reworked the patch. please review it.
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=100853&group_id=5470


From noreply@sourceforge.net  Mon Jul 31 09:45:32 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 31 Jul 2000 01:45:32 -0700
Subject: [Patches] [Patch #100884] arraymodule: adding count, extend, index, pop, remove
Message-ID: <200007310845.BAA30642@delerium.i.sourceforge.net>

Patch #100884 has been updated. 

Project: 
Category: None
Status: Open
Summary: arraymodule: adding count, extend, index, pop, remove

Follow-Ups:

Date: 2000-Jul-31 01:45
By: nowonder

Comment:
needs reviewing. includes test and documentation update. works fine on all tests.
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=100884&group_id=5470


From noreply@sourceforge.net  Mon Jul 31 09:46:21 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 31 Jul 2000 01:46:21 -0700
Subject: [Patches] [Patch #100803] puremodule: ANSI-fication (UNTESTED!)
Message-ID: <200007310846.BAA31736@bush.i.sourceforge.net>

Patch #100803 has been updated. 

Project: 
Category: None
Status: Open
Summary: puremodule: ANSI-fication (UNTESTED!)

Follow-Ups:

Date: 2000-Jul-10 10:16
By: nowonder

Comment:
cannot test this, maybe Barry can
-------------------------------------------------------

Date: 2000-Jul-31 01:46
By: nowonder

Comment:
should I just check it in? Did you get around to review it?
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=100803&group_id=5470


From noreply@sourceforge.net  Mon Jul 31 10:49:05 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 31 Jul 2000 02:49:05 -0700
Subject: [Patches] [Patch #100913] Optional pad character (or string) for rjust, ljust
Message-ID: <200007310949.CAA01253@bush.i.sourceforge.net>

Patch #100913 has been updated. 

Project: 
Category: None
Status: Open
Summary: Optional pad character (or string) for rjust, ljust

Follow-Ups:

Date: 2000-Jul-17 04:45
By: effbot

Comment:
looks fine to me, but you should really change the
unicode string type too (unicodeobject.c)
-------------------------------------------------------

Date: 2000-Jul-17 04:55
By: twouters

Comment:
And don't forget Lib/UserString.py ! :-)
+1 on the patch, though. I always had a nagging feeling this needed fixing, but I've never used it myself, and I thought there was another way to go 'bout it.

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

Date: 2000-Jul-25 07:45
By: jhylton

Comment:
Can you also add code to the test suite to exercise this feature? Look in Lib/test/string_tests.py

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

Date: 2000-Jul-26 23:48
By: moshez

Comment:
The semantics for strings are a bit confusing, and I'm not sure it's worth the complexity. Also, doing it once for strings and once for unicode is a bit redundant, when you can do it in pure Python for both types with ease...wouldn't it be better to to have ljust and rjust (with optional padding) remain in the string module, and make them work on both regular and unicode strings by polymorphism.

def rjust(s, l, pad=' '):
    missing = l-len(s)
    if missing > 0:
        return s+(pad*missing)
    else:
        return s

def ljust(s, l, pad=' '):
    missing = l-len(s)
    if missing > 0:
        return (pad*missing)+s
    else:
        return s

(Or the other way around, could never tell the difference between left and right)

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

Date: 2000-Jul-31 02:49
By: nowonder

Comment:
It would be nice to also have the documentation patched.

BTW: I like the semantics for strings, but the pad=='' case is a bit strange:

"hello".rjust(10,'') gives "hello" (as far as I can see).
I would expect "hello".rjust(10,somestring) to return a string of length 10 regardless of the value of somestring.
On the other hand an empty string could be used to switch off padding. But that's a bit too magic for me. Maybe this should raise a ValueError?
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=100913&group_id=5470


From noreply@sourceforge.net  Mon Jul 31 14:21:18 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 31 Jul 2000 06:21:18 -0700
Subject: [Patches] [Patch #100913] Optional pad character (or string) for rjust, ljust
Message-ID: <200007311321.GAA06775@delerium.i.sourceforge.net>

Patch #100913 has been updated. 

Project: 
Category: None
Status: Rejected
Summary: Optional pad character (or string) for rjust, ljust

Follow-Ups:

Date: 2000-Jul-17 04:45
By: effbot

Comment:
looks fine to me, but you should really change the
unicode string type too (unicodeobject.c)
-------------------------------------------------------

Date: 2000-Jul-17 04:55
By: twouters

Comment:
And don't forget Lib/UserString.py ! :-)
+1 on the patch, though. I always had a nagging feeling this needed fixing, but I've never used it myself, and I thought there was another way to go 'bout it.

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

Date: 2000-Jul-25 07:45
By: jhylton

Comment:
Can you also add code to the test suite to exercise this feature? Look in Lib/test/string_tests.py

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

Date: 2000-Jul-26 23:48
By: moshez

Comment:
The semantics for strings are a bit confusing, and I'm not sure it's worth the complexity. Also, doing it once for strings and once for unicode is a bit redundant, when you can do it in pure Python for both types with ease...wouldn't it be better to to have ljust and rjust (with optional padding) remain in the string module, and make them work on both regular and unicode strings by polymorphism.

def rjust(s, l, pad=' '):
    missing = l-len(s)
    if missing > 0:
        return s+(pad*missing)
    else:
        return s

def ljust(s, l, pad=' '):
    missing = l-len(s)
    if missing > 0:
        return (pad*missing)+s
    else:
        return s

(Or the other way around, could never tell the difference between left and right)

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

Date: 2000-Jul-31 02:49
By: nowonder

Comment:
It would be nice to also have the documentation patched.

BTW: I like the semantics for strings, but the pad=='' case is a bit strange:

"hello".rjust(10,'') gives "hello" (as far as I can see).
I would expect "hello".rjust(10,somestring) to return a string of length 10 regardless of the value of somestring.
On the other hand an empty string could be used to switch off padding. But that's a bit too magic for me. Maybe this should raise a ValueError?
-------------------------------------------------------

Date: 2000-Jul-31 06:21
By: gvanrossum

Comment:
Rejected: I think this is of too little value to be worth the added complexity in code and documentation.
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=100913&group_id=5470


From noreply@sourceforge.net  Mon Jul 31 14:30:52 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 31 Jul 2000 06:30:52 -0700
Subject: [Patches] [Patch #100884] arraymodule: adding count, extend, index, pop, remove
Message-ID: <200007311330.GAA08315@bush.i.sourceforge.net>

Patch #100884 has been updated. 

Project: 
Category: None
Status: Rejected
Summary: arraymodule: adding count, extend, index, pop, remove

Follow-Ups:

Date: 2000-Jul-31 01:45
By: nowonder

Comment:
needs reviewing. includes test and documentation update. works fine on all tests.
-------------------------------------------------------

Date: 2000-Jul-31 06:30
By: gvanrossum

Comment:
Rejected: the idea is good, but the code buggy:

- getarrayitem() returns a new reference, so you must DECREF it after using the value (except the one place where you INCREF it unnecessarily)

- PyErr_BadArgument() is a poor diagnostic for extend() with an array of the wrong kind.

Please fix the patch and resubmit!
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=100884&group_id=5470


From noreply@sourceforge.net  Mon Jul 31 14:37:12 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 31 Jul 2000 06:37:12 -0700
Subject: [Patches] [Patch #100884] arraymodule: adding count, extend, index, pop, remove
Message-ID: <200007311337.GAA07304@delerium.i.sourceforge.net>

Patch #100884 has been updated. 

Project: 
Category: None
Status: Rejected
Summary: arraymodule: adding count, extend, index, pop, remove

Follow-Ups:

Date: 2000-Jul-31 01:45
By: nowonder

Comment:
needs reviewing. includes test and documentation update. works fine on all tests.
-------------------------------------------------------

Date: 2000-Jul-31 06:30
By: gvanrossum

Comment:
Rejected: the idea is good, but the code buggy:

- getarrayitem() returns a new reference, so you must DECREF it after using the value (except the one place where you INCREF it unnecessarily)

- PyErr_BadArgument() is a poor diagnostic for extend() with an array of the wrong kind.

Please fix the patch and resubmit!
-------------------------------------------------------

Date: 2000-Jul-31 06:37
By: fdrake

Comment:
The documentation update looks fine to me.
The methods in the C module should use PyArg_ParseTuple() instead of PyArg_Parse(); there's rarely a good reason to use the older version, and the _ParseTuple() version allows the function nam e to be included in the error messages.
(Plus Guido's comments need to be addressed.)
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=100884&group_id=5470


From noreply@sourceforge.net  Mon Jul 31 14:40:47 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 31 Jul 2000 06:40:47 -0700
Subject: [Patches] [Patch #101022] Removal of SET_LINENO (experimental)
Message-ID: <200007311340.GAA07434@delerium.i.sourceforge.net>

Patch #101022 has been updated. 

Project: 
Category: core (C code)
Status: Postponed
Summary: Removal of SET_LINENO (experimental)

Follow-Ups:

Date: 2000-Jul-30 16:12
By: marangoz

Comment:
For testing, as discussed on python-dev. For a gentle summary, see:
http://www.python.org/pipermail/python-dev/2000-July/014364.html

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

Date: 2000-Jul-30 18:16
By: marangoz

Comment:
A nit: inline the argfetch in CALL_TRACE and goto the switch,
instead of jumping to get_oparg which splits the sequence
[fetch opcode, fetch oparg] -- this can slow things down.

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

Date: 2000-Jul-31 06:40
By: gvanrossum

Comment:
Status set to postponed to indicate that this is still experimental.
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=101022&group_id=5470


From noreply@sourceforge.net  Mon Jul 31 14:43:18 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 31 Jul 2000 06:43:18 -0700
Subject: [Patches] [Patch #101019] Opcode reordering
Message-ID: <200007311343.GAA08691@bush.i.sourceforge.net>

Patch #101019 has been updated. 

Project: 
Category: core (C code)
Status: Postponed
Summary: Opcode reordering

Follow-Ups:

Date: 2000-Jul-30 01:34
By: marangoz

Comment:
Mainly for peace of mind - as discussed on python-dev,
aims at reducing cache effects.

The Top5 opcodes have been moved to the beginning of
the main loop, ordered by decreasing frequency according
to DXP and MAL's statistics.

LOAD_FAST & LOAD_CONST have been slightly tweaked
so that the code sequence is 'unique' amongst the other opcodes.
Otherwise, the optimizer is likely to generate a jump to another
common block later in the loop which obviates the whole point
of moving these opcodes to the top.

- The condition in LOAD_FAST is inversed
- LOAD_CONST has been changed from 'break' to 'continue'.
   Indeed, if x == NULL, we would have dumped core at the
   Py_INCREF(x) preceding the break...

Some testing on Lunix, Solaris and AIX shows no slowdowns <wink>.
There seems to be some speedup, but in some cases it is barely
noticeable.

I dropped the idea of folding opcodes. The bahavior is unpredictable.
If someone wants to spend her entire life between balancing caching
and pipelining in ceval.c, no problem <wink>. I'm out of this game.

As usual, please test (notably on Windows)
-------------------------------------------------------

Date: 2000-Jul-31 06:43
By: gvanrossum

Comment:
Status set to Postponed, just to indicate that this is still experimental and not slated for inclusion into 2.0.  Thanks for submitting this though -- it's good that it's recorded somewhere.
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=101019&group_id=5470


From noreply@sourceforge.net  Mon Jul 31 14:51:14 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 31 Jul 2000 06:51:14 -0700
Subject: [Patches] [Patch #101029] Call __getitem__ for slices when no __getslice__
Message-ID: <200007311351.GAA08994@bush.i.sourceforge.net>

Patch #101029 has been updated. 

Project: 
Category: core (C code)
Status: Open
Summary: Call __getitem__ for slices when no __getslice__

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=101029&group_id=5470


From noreply@sourceforge.net  Mon Jul 31 14:55:29 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 31 Jul 2000 06:55:29 -0700
Subject: [Patches] [Patch #101029] Call __getitem__ for slices when no __getslice__
Message-ID: <200007311355.GAA09137@bush.i.sourceforge.net>

Patch #101029 has been updated. 

Project: 
Category: core (C code)
Status: Open
Summary: Call __getitem__ for slices when no __getslice__

Follow-Ups:

Date: 2000-Jul-31 06:55
By: twouters

Comment:
Call __getitem__ if no __getslice__ is available. similar for __delslice__ and __setslice__, and for the C API: calls mp_subscript() with a slice object of (start, end, None) if there is no sq_slice(), and the same for sq_ass_slice().

Eventually the reverse should be done, too: call __getslice__ instead of __getitem__ if the object has a __getslice__, and the 3rd argument to the slice is None: That way, we can ditch the 12 silly SLICE* opcodes, and always use slice objects. This *will* result in x[::] being passed to __getslice__ (if available) instead of __getitem__, however, so it is not 100% backwards compatible.

This patch is not terribly tested: I'm not feeling well, and I want to post this patch before I head off to home and dive back in bed ;) It doesn't crash, it survives 'make test', it survives manual testing, but it might leak.


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

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=101029&group_id=5470


From Moshe Zadka <moshez@math.huji.ac.il>  Mon Jul 31 15:12:08 2000
From: Moshe Zadka <moshez@math.huji.ac.il> (Moshe Zadka)
Date: Mon, 31 Jul 2000 17:12:08 +0300 (IDT)
Subject: [Patches] [Patch #100913] Optional pad character (or string)
 for rjust, ljust
In-Reply-To: <200007311321.GAA06775@delerium.i.sourceforge.net>
Message-ID: <Pine.GSO.4.10.10007311709090.19940-100000@sundial>

On Mon, 31 Jul 2000 noreply@sourceforge.net wrote:

> Summary: Optional pad character (or string) for rjust, ljust
<snip>

[Moshe suggested a Python implementation in the "string" module]
> def rjust(s, l, pad=' '):
>     missing = l-len(s)
>     if missing > 0:
>         return s+(pad*missing)
>     else:
>         return s
> 
> def ljust(s, l, pad=' '):
>     missing = l-len(s)
>     if missing > 0:
>         return (pad*missing)+s
>     else:
>         return s
> 
> (Or the other way around, could never tell the difference between left and 
> right)
<snip>

[BDFL]
> Rejected: I think this is of too little value to be worth the added
> complexity in code and documentation.

What about putting up the Python implementation suggested above in some 
module?
--
Moshe Zadka <moshez@math.huji.ac.il>
There is no IGLU cabal.
http://advogato.org/person/moshez



From guido@beopen.com  Mon Jul 31 16:29:23 2000
From: guido@beopen.com (Guido van Rossum)
Date: Mon, 31 Jul 2000 10:29:23 -0500
Subject: [Patches] [Patch #100913] Optional pad character (or string) for rjust, ljust
In-Reply-To: Your message of "Mon, 31 Jul 2000 17:12:08 +0300."
 <Pine.GSO.4.10.10007311709090.19940-100000@sundial>
References: <Pine.GSO.4.10.10007311709090.19940-100000@sundial>
Message-ID: <200007311529.KAA20963@cj20424-a.reston1.va.home.com>

> What about putting up the Python implementation suggested above in some 
> module?

It's too easy to come up with this yourself to bother with a standard
library routine.

--Guido van Rossum (home page: http://www.pythonlabs.com/~guido/)


From noreply@sourceforge.net  Mon Jul 31 15:55:28 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 31 Jul 2000 07:55:28 -0700
Subject: [Patches] [Patch #101029] Call __getitem__ for slices when no __getslice__
Message-ID: <200007311455.HAA11127@bush.i.sourceforge.net>

Patch #101029 has been updated. 

Project: 
Category: core (C code)
Status: Open
Summary: Call __getitem__ for slices when no __getslice__

Follow-Ups:

Date: 2000-Jul-31 06:55
By: twouters

Comment:
Call __getitem__ if no __getslice__ is available. similar for __delslice__ and __setslice__, and for the C API: calls mp_subscript() with a slice object of (start, end, None) if there is no sq_slice(), and the same for sq_ass_slice().

Eventually the reverse should be done, too: call __getslice__ instead of __getitem__ if the object has a __getslice__, and the 3rd argument to the slice is None: That way, we can ditch the 12 silly SLICE* opcodes, and always use slice objects. This *will* result in x[::] being passed to __getslice__ (if available) instead of __getitem__, however, so it is not 100% backwards compatible.

This patch is not terribly tested: I'm not feeling well, and I want to post this patch before I head off to home and dive back in bed ;) It doesn't crash, it survives 'make test', it survives manual testing, but it might leak.


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

Date: 2000-Jul-31 07:55
By: gvanrossum

Comment:
Looks cool to me, except that there's a lot of code duplication.

Maybe you can add a static helper routine to create a slice out of two ints to abstract.c and one that creates a 1-tuple containing such a slice to classobject.c.  (Trying to share code across .c files would require turning it into an official API which I think is overkill.)
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=101029&group_id=5470


From noreply@sourceforge.net  Mon Jul 31 15:57:38 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 31 Jul 2000 07:57:38 -0700
Subject: [Patches] [Patch #101022] Removal of SET_LINENO (experimental)
Message-ID: <200007311457.HAA09992@delerium.i.sourceforge.net>

Patch #101022 has been updated. 

Project: 
Category: core (C code)
Status: Postponed
Summary: Removal of SET_LINENO (experimental)

Follow-Ups:

Date: 2000-Jul-30 16:12
By: marangoz

Comment:
For testing, as discussed on python-dev. For a gentle summary, see:
http://www.python.org/pipermail/python-dev/2000-July/014364.html

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

Date: 2000-Jul-30 18:16
By: marangoz

Comment:
A nit: inline the argfetch in CALL_TRACE and goto the switch,
instead of jumping to get_oparg which splits the sequence
[fetch opcode, fetch oparg] -- this can slow things down.

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

Date: 2000-Jul-31 06:40
By: gvanrossum

Comment:
Status set to postponed to indicate that this is still experimental.
-------------------------------------------------------

Date: 2000-Jul-31 07:57
By: marangoz

Comment:
Another rewrite, making this whole strategy b/w compatible according to
the 1st incompatibility point a) described in: http://www.python.org/pipermail/python-dev/2000-July/014364.html

Changes:

1. f.f_lineno is computed and updated on f_lineno attribute requests for
   f, given f.f_lasti. Correctness is ensured because f.f_lasti is updated
   on *all* attribute accesses (in LOAD_ATTR in the main loop).

2. The standard setup does not generate SET_LINENO, but uses
   co_lnotab for computing the source line number (e.g. tracebacks)
   This is equivalent to the actual "python -O".

3. With "python -d", we fall back to the current version of the
   interpreter (with SET_LINENO) thus making it easy to test whether
   this patch fully replaces SET_LINENO's behavior.
   (modulo f->f_lineno accesses from legacy C code, but this is insane).

IMO, this version already worths the pain to be truly tested and improved.

One improvement is to define a nicer public C API for breakpoints:
 - PyCode_SetBreakPointAtLine(line)
 - PyCode_SetBreakPointAtAddr(addr)
or similar, which would install a CALL_TRACE opcode in the appropriate
location of the copy of co_code.

Another idea is to avoid duplicating the entire co_code just for storing
the CALL_TRACE opcodes. We can store them in the original and keep
a table of breakpoints. Setting the breakpoints would occur whenever
the sys.settrace hook is set.
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=101022&group_id=5470


From noreply@sourceforge.net  Mon Jul 31 16:02:12 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 31 Jul 2000 08:02:12 -0700
Subject: [Patches] [Patch #100853] merging my*.h into pyport.h
Message-ID: <200007311502.IAA11362@bush.i.sourceforge.net>

Patch #100853 has been updated. 

Project: 
Category: core (C code)
Status: Accepted
Summary: merging my*.h into pyport.h

Follow-Ups:

Date: 2000-Jul-11 09:34
By: gvanrossum

Comment:
Python.h already includes pyport.h, so you can eliminate all those #import pyport.h from the .c files. (Not from *all* C files, because a few may not include Python.h, but the majority do.)

Also, please ask Jack Jansen to see if  SYMANTEC_FFM68K and MC68K and other Mac symbols are still wanted.

Maybe much of the Mac-specific madness could be collected in a separate file included only #ifdef macintosh?
-------------------------------------------------------

Date: 2000-Jul-11 09:43
By: gvanrossum

Comment:
Also, you can delete the my*.h files (if indeed there are no references to them any more in the Python core source code).
-------------------------------------------------------

Date: 2000-Jul-11 15:45
By: nowonder

Comment:
Okay, I'll rework the patch. May take some time. Have to do some real work in between python sessions <wink>.
-------------------------------------------------------

Date: 2000-Jul-27 13:29
By: gvanrossum

Comment:
So, it's been a few weeks.  Do you still want to do this?
-------------------------------------------------------

Date: 2000-Jul-28 02:00
By: nowonder

Comment:
Yes. I just wanted to wait until Thomas has dealt with that platform specific clutter.

It's on my list for next week. Maybe that means I'll do something about it ...
-------------------------------------------------------

Date: 2000-Jul-31 01:40
By: nowonder

Comment:
reworked the patch. please review it.
-------------------------------------------------------

Date: 2000-Jul-31 08:02
By: gvanrossum

Comment:
Works for me, and looks pretty innocent.

Check it in so we get some more feedback!
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=100853&group_id=5470


From noreply@sourceforge.net  Mon Jul 31 16:03:09 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 31 Jul 2000 08:03:09 -0700
Subject: [Patches] [Patch #100510] largefile support for Win64 (and some other fixes)
Message-ID: <200007311503.IAA11377@bush.i.sourceforge.net>

Patch #100510 has been updated. 

Project: 
Category: core (C code)
Status: Accepted
Summary: largefile support for Win64 (and some other fixes)

Follow-Ups:

Date: 2000-Jun-06 19:56
By: tmick

Comment:
I confirm that, to the best of my knowledge and belief, this
contribution is free of any claims of third parties under
copyright, patent or other rights or interests ("claims").  To
the extent that I have any such claims, I hereby grant to CNRI a
nonexclusive, irrevocable, royalty-free, worldwide license to
reproduce, distribute, perform and/or display publicly, prepare
derivative versions, and otherwise use this contribution as part
of the Python software and its related documentation, or any
derivative versions thereof, at no cost to CNRI or its licensed
users, and to authorize others to do so.

I acknowledge that CNRI may, at its sole discretion, decide
whether or not to incorporate this contribution in the Python
software and its related documentation.  I further grant CNRI
permission to use my name and other identifying information
provided to CNRI by me for use in connection with the Python
software and its related documentation.

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

Date: 2000-Jun-06 19:58
By: tmick

Comment:
This patch adds largefile support for Win64 and Linux64 (the latter already
motly worked I think),  and fixes some possible buffer overflows on all
systems with largefile support.

NOTE: this patch depends on my earlier patch to PC/config.h and configure.in
for SIZEOF_OFF_T and SIZEOF_FPOS_T. (see: "[Patches] changes to configure.in
and PC/config.h for 64-bit systems")

Win64 largefile support involved fixing file_seek, file_tell, and
file_truncate to properly handle large indeces and to use the proper Win64
system APIs. Win64 does not have 64-bit capable versions of ftell and fseek,
this could be worked around with fgetpos() and fsetpos() (and _telli64(), and
64-bit tell()). _portable_ftell() and _portable_fseek() were written to hold
the platform dependent logic. You are still restricted to 32-bits for single
reads and writes.

Previously _chsize was used blindly as the replacement for ftruncate() in
Win32. In fact, _chsize() is not 64-bit capable so and appropriate overflow
check was added.

There are some type histrionics involved because off_t is only 32-bits on
Win64. fpos_t is 64-bits, however, so fpos_t is used for Win64.

As well, the patch adds some necessary overflow checks (raising OverflowError
when an overflow is detected). See file_read for example.

A forthcoming patch adds a test to the test suite for this largefile support.

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

Date: 2000-Jun-27 07:50
By: gvanrossum

Comment:
Tim- after you're fine with this, please assign to someone with a Linux box for further review.
-------------------------------------------------------

Date: 2000-Jun-29 17:07
By: tim_one

Comment:
Looks good to me.  Passed on to Fred.  Fred, Guido wants someone to check this on Linux.  Since you have the 64-bit Linux development disk, you're elected <wink>.
-------------------------------------------------------

Date: 2000-Jul-09 23:37
By: tim_one

Comment:
Fred, do something with this or assign it to some other Unix geek?

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

Date: 2000-Jul-13 17:21
By: fdrake

Comment:
This looks good on platforms I have easy access to (linux/x86, linux/ia32 simulator).  I do not have Linux+LFS (large file support; a kernel patch) installed on any machines, and could not test in that environment without having a separate machine to use as a test bed.

Accepted as is; we can work out any problems that arise as needed, but it doesn't seem to break things.
-------------------------------------------------------

Date: 2000-Jul-31 08:03
By: gvanrossum

Comment:
This was accepted ages ago.  What are you waiting for?
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=100510&group_id=5470


From noreply@sourceforge.net  Mon Jul 31 16:03:44 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 31 Jul 2000 08:03:44 -0700
Subject: [Patches] [Patch #100511] test largefile support (test_largefile.py)
Message-ID: <200007311503.IAA11384@bush.i.sourceforge.net>

Patch #100511 has been updated. 

Project: 
Category: library
Status: Accepted
Summary: test largefile support (test_largefile.py)

Follow-Ups:

Date: 2000-Jun-06 19:58
By: tmick

Comment:
I confirm that, to the best of my knowledge and belief, this
contribution is free of any claims of third parties under
copyright, patent or other rights or interests ("claims").  To
the extent that I have any such claims, I hereby grant to CNRI a
nonexclusive, irrevocable, royalty-free, worldwide license to
reproduce, distribute, perform and/or display publicly, prepare
derivative versions, and otherwise use this contribution as part
of the Python software and its related documentation, or any
derivative versions thereof, at no cost to CNRI or its licensed
users, and to authorize others to do so.

I acknowledge that CNRI may, at its sole discretion, decide
whether or not to incorporate this contribution in the Python
software and its related documentation.  I further grant CNRI
permission to use my name and other identifying information
provided to CNRI by me for use in connection with the Python
software and its related documentation.

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

Date: 2000-Jun-06 19:58
By: tmick

Comment:
This patch adds a test for largefiles (creating, seeking, telling, etc.).
The test skips if there is no largefile support.

There is one further problem. The test basically involves creating a file
greater than 2GB and playing with it. On UN*X systems with sparse files this
is no problem. On Win64 (which I have heard *can* do sparse files, but not in
Python yet), however, >2GB space and a *long* time is required to run the
test. I don't think it is reasonable to turn this on by default... so here is
what I did.

I extended regrtest.py to accept the --have-resources switch. This sets
test_support.use_large_resources, which is checked in test_largefile.py.
By default 'use_large_resources' is false. On Win64, then, by default the
largefile test is skipped but can be run via the --have-resources switch to
regrtest.py or by running the test directly. This seems to me the Right
Thing.

The affected files are:
 Lib/test/regrtest.py
 Lib/test/test_support.py
 Lib/test/test_largefile.py (new)
 Lib/test/output/test_largefile (new)

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

Date: 2000-Jun-29 17:13
By: tim_one

Comment:
Fred, can you test this on a Linux with > 2Gb files (needs the --have-resources switch; read Trent's comment), or pass it on to someone who can?  I can't do more than stare at this, and nothing in my staring hit my eye.  Well, Guido may hate the long option name (--have-resources), especially given that even with all those letters <wink>, it's not really self-describing.
-------------------------------------------------------

Date: 2000-Jun-30 08:08
By: tmick

Comment:
--have-at-least-2GB-on-hard-drive-and-am-going-for-coffee-<wink>
-------------------------------------------------------

Date: 2000-Jul-09 23:37
By: tim_one

Comment:
Fred, do something with this or assign it to some other Unix geek?
-------------------------------------------------------

Date: 2000-Jul-13 17:23
By: fdrake

Comment:
Looks good to me, and properly skips the large file test on my Linux box.  A second iteration may be useful to provide separate options for different resources (cpu/disk/ram), but it's not clearly needed at this time.

Accepted as-is.
-------------------------------------------------------

Date: 2000-Jul-31 08:03
By: gvanrossum

Comment:
This was accepted ages agon -- what are you waiting for?
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=100511&group_id=5470


From noreply@sourceforge.net  Mon Jul 31 16:05:00 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 31 Jul 2000 08:05:00 -0700
Subject: [Patches] [Patch #100871] document new method in shutil (copyfileobj)
Message-ID: <200007311505.IAA11398@bush.i.sourceforge.net>

Patch #100871 has been updated. 

Project: 
Category: documentation
Status: Accepted
Summary: document new method in shutil (copyfileobj)

Follow-Ups:

Date: 2000-Jul-12 05:28
By: gvanrossum

Comment:
Note that Greg Stein says: I don't understand the comment about negative values. I certainly don't see that from the code.
-------------------------------------------------------

Date: 2000-Jul-12 05:29
By: gvanrossum

Comment:
Moshe replies: It's documented that read(negative_number) on a file object returns all the contents of the file
-------------------------------------------------------

Date: 2000-Jul-31 08:04
By: gvanrossum

Comment:
Fred, did you forget to check this in or forget to mark it as Closed?
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=100871&group_id=5470


From noreply@sourceforge.net  Mon Jul 31 16:16:32 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 31 Jul 2000 08:16:32 -0700
Subject: [Patches] [Patch #100853] merging my*.h into pyport.h
Message-ID: <200007311516.IAA10645@delerium.i.sourceforge.net>

Patch #100853 has been updated. 

Project: 
Category: core (C code)
Status: Accepted
Summary: merging my*.h into pyport.h

Follow-Ups:

Date: 2000-Jul-11 09:34
By: gvanrossum

Comment:
Python.h already includes pyport.h, so you can eliminate all those #import pyport.h from the .c files. (Not from *all* C files, because a few may not include Python.h, but the majority do.)

Also, please ask Jack Jansen to see if  SYMANTEC_FFM68K and MC68K and other Mac symbols are still wanted.

Maybe much of the Mac-specific madness could be collected in a separate file included only #ifdef macintosh?
-------------------------------------------------------

Date: 2000-Jul-11 09:43
By: gvanrossum

Comment:
Also, you can delete the my*.h files (if indeed there are no references to them any more in the Python core source code).
-------------------------------------------------------

Date: 2000-Jul-11 15:45
By: nowonder

Comment:
Okay, I'll rework the patch. May take some time. Have to do some real work in between python sessions <wink>.
-------------------------------------------------------

Date: 2000-Jul-27 13:29
By: gvanrossum

Comment:
So, it's been a few weeks.  Do you still want to do this?
-------------------------------------------------------

Date: 2000-Jul-28 02:00
By: nowonder

Comment:
Yes. I just wanted to wait until Thomas has dealt with that platform specific clutter.

It's on my list for next week. Maybe that means I'll do something about it ...
-------------------------------------------------------

Date: 2000-Jul-31 01:40
By: nowonder

Comment:
reworked the patch. please review it.
-------------------------------------------------------

Date: 2000-Jul-31 08:02
By: gvanrossum

Comment:
Works for me, and looks pretty innocent.

Check it in so we get some more feedback!
-------------------------------------------------------

Date: 2000-Jul-31 08:16
By: marangoz

Comment:
Feedback: I'm not thrilled by the fact that Python interfaces are defined
in pyport.h. Defining only the ANY & _Mem_EXTRA compatibility issues
is fine, but official PyMem_ interfaces is not so fine.

I'd prefer a separate .h file, be it mymalloc.h or pymalloc.h.
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=100853&group_id=5470


From noreply@sourceforge.net  Mon Jul 31 16:46:09 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 31 Jul 2000 08:46:09 -0700
Subject: [Patches] [Patch #100871] document new method in shutil (copyfileobj)
Message-ID: <200007311546.IAA11695@delerium.i.sourceforge.net>

Patch #100871 has been updated. 

Project: 
Category: documentation
Status: Closed
Summary: document new method in shutil (copyfileobj)

Follow-Ups:

Date: 2000-Jul-12 05:28
By: gvanrossum

Comment:
Note that Greg Stein says: I don't understand the comment about negative values. I certainly don't see that from the code.
-------------------------------------------------------

Date: 2000-Jul-12 05:29
By: gvanrossum

Comment:
Moshe replies: It's documented that read(negative_number) on a file object returns all the contents of the file
-------------------------------------------------------

Date: 2000-Jul-31 08:04
By: gvanrossum

Comment:
Fred, did you forget to check this in or forget to mark it as Closed?
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=100871&group_id=5470


From noreply@sourceforge.net  Mon Jul 31 17:08:08 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 31 Jul 2000 09:08:08 -0700
Subject: [Patches] [Patch #100884] arraymodule: adding count, extend, index, pop, remove
Message-ID: <200007311608.JAA13677@bush.i.sourceforge.net>

Patch #100884 has been updated. 

Project: 
Category: None
Status: Open
Summary: arraymodule: adding count, extend, index, pop, remove

Follow-Ups:

Date: 2000-Jul-31 01:45
By: nowonder

Comment:
needs reviewing. includes test and documentation update. works fine on all tests.
-------------------------------------------------------

Date: 2000-Jul-31 06:30
By: gvanrossum

Comment:
Rejected: the idea is good, but the code buggy:

- getarrayitem() returns a new reference, so you must DECREF it after using the value (except the one place where you INCREF it unnecessarily)

- PyErr_BadArgument() is a poor diagnostic for extend() with an array of the wrong kind.

Please fix the patch and resubmit!
-------------------------------------------------------

Date: 2000-Jul-31 06:37
By: fdrake

Comment:
The documentation update looks fine to me.
The methods in the C module should use PyArg_ParseTuple() instead of PyArg_Parse(); there's rarely a good reason to use the older version, and the _ParseTuple() version allows the function nam e to be included in the error messages.
(Plus Guido's comments need to be addressed.)
-------------------------------------------------------

Date: 2000-Jul-31 09:08
By: nowonder

Comment:
changed _parse to _parsetuple

hopefully fixed refcounting (my first try at that)
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=100884&group_id=5470


From noreply@sourceforge.net  Mon Jul 31 17:20:14 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 31 Jul 2000 09:20:14 -0700
Subject: [Patches] [Patch #100853] merging my*.h into pyport.h
Message-ID: <200007311620.JAA14099@bush.i.sourceforge.net>

Patch #100853 has been updated. 

Project: 
Category: core (C code)
Status: Closed
Summary: merging my*.h into pyport.h

Follow-Ups:

Date: 2000-Jul-11 09:34
By: gvanrossum

Comment:
Python.h already includes pyport.h, so you can eliminate all those #import pyport.h from the .c files. (Not from *all* C files, because a few may not include Python.h, but the majority do.)

Also, please ask Jack Jansen to see if  SYMANTEC_FFM68K and MC68K and other Mac symbols are still wanted.

Maybe much of the Mac-specific madness could be collected in a separate file included only #ifdef macintosh?
-------------------------------------------------------

Date: 2000-Jul-11 09:43
By: gvanrossum

Comment:
Also, you can delete the my*.h files (if indeed there are no references to them any more in the Python core source code).
-------------------------------------------------------

Date: 2000-Jul-11 15:45
By: nowonder

Comment:
Okay, I'll rework the patch. May take some time. Have to do some real work in between python sessions <wink>.
-------------------------------------------------------

Date: 2000-Jul-27 13:29
By: gvanrossum

Comment:
So, it's been a few weeks.  Do you still want to do this?
-------------------------------------------------------

Date: 2000-Jul-28 02:00
By: nowonder

Comment:
Yes. I just wanted to wait until Thomas has dealt with that platform specific clutter.

It's on my list for next week. Maybe that means I'll do something about it ...
-------------------------------------------------------

Date: 2000-Jul-31 01:40
By: nowonder

Comment:
reworked the patch. please review it.
-------------------------------------------------------

Date: 2000-Jul-31 08:02
By: gvanrossum

Comment:
Works for me, and looks pretty innocent.

Check it in so we get some more feedback!
-------------------------------------------------------

Date: 2000-Jul-31 08:16
By: marangoz

Comment:
Feedback: I'm not thrilled by the fact that Python interfaces are defined
in pyport.h. Defining only the ANY & _Mem_EXTRA compatibility issues
is fine, but official PyMem_ interfaces is not so fine.

I'd prefer a separate .h file, be it mymalloc.h or pymalloc.h.
-------------------------------------------------------

Date: 2000-Jul-31 09:20
By: nowonder

Comment:
I like pymalloc.h.

Could you (Vladimir) or anybody else with some understanding of this piece of code seperate the compatibility stuff from the interfaces?

I could only guess.
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=100853&group_id=5470


From noreply@sourceforge.net  Mon Jul 31 17:23:49 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 31 Jul 2000 09:23:49 -0700
Subject: [Patches] [Patch #100853] merging my*.h into pyport.h
Message-ID: <200007311623.JAA13137@delerium.i.sourceforge.net>

Patch #100853 has been updated. 

Project: 
Category: core (C code)
Status: Accepted
Summary: merging my*.h into pyport.h

Follow-Ups:

Date: 2000-Jul-11 09:34
By: gvanrossum

Comment:
Python.h already includes pyport.h, so you can eliminate all those #import pyport.h from the .c files. (Not from *all* C files, because a few may not include Python.h, but the majority do.)

Also, please ask Jack Jansen to see if  SYMANTEC_FFM68K and MC68K and other Mac symbols are still wanted.

Maybe much of the Mac-specific madness could be collected in a separate file included only #ifdef macintosh?
-------------------------------------------------------

Date: 2000-Jul-11 09:43
By: gvanrossum

Comment:
Also, you can delete the my*.h files (if indeed there are no references to them any more in the Python core source code).
-------------------------------------------------------

Date: 2000-Jul-11 15:45
By: nowonder

Comment:
Okay, I'll rework the patch. May take some time. Have to do some real work in between python sessions <wink>.
-------------------------------------------------------

Date: 2000-Jul-27 13:29
By: gvanrossum

Comment:
So, it's been a few weeks.  Do you still want to do this?
-------------------------------------------------------

Date: 2000-Jul-28 02:00
By: nowonder

Comment:
Yes. I just wanted to wait until Thomas has dealt with that platform specific clutter.

It's on my list for next week. Maybe that means I'll do something about it ...
-------------------------------------------------------

Date: 2000-Jul-31 01:40
By: nowonder

Comment:
reworked the patch. please review it.
-------------------------------------------------------

Date: 2000-Jul-31 08:02
By: gvanrossum

Comment:
Works for me, and looks pretty innocent.

Check it in so we get some more feedback!
-------------------------------------------------------

Date: 2000-Jul-31 08:16
By: marangoz

Comment:
Feedback: I'm not thrilled by the fact that Python interfaces are defined
in pyport.h. Defining only the ANY & _Mem_EXTRA compatibility issues
is fine, but official PyMem_ interfaces is not so fine.

I'd prefer a separate .h file, be it mymalloc.h or pymalloc.h.
-------------------------------------------------------

Date: 2000-Jul-31 09:20
By: nowonder

Comment:
I like pymalloc.h.

Could you (Vladimir) or anybody else with some understanding of this piece of code seperate the compatibility stuff from the interfaces?

I could only guess.
-------------------------------------------------------

Date: 2000-Jul-31 09:23
By: marangoz

Comment:
Include/pymem.h is a better suggestion.

pymem.h should include everything starting from the comment
/* Core memory allocator */

and should include: "pyport.h" and "config.h"
where NEED_TO_DECLARE_MALLOC_AND_FRIENDS is defined.
So the current state is clearly unacceptable, because pyport.h
does not include config.h

Also, if someone wants to redefine the core malloc
(cf. the macros) it should be able to do it from configure.

If Guido doesn't object (and I just received his request for
comments from me), could you please revamp this and take
into account the above suggestions. Otherwise, I'll submit
another patch.

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

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=100853&group_id=5470


From noreply@sourceforge.net  Mon Jul 31 17:30:25 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 31 Jul 2000 09:30:25 -0700
Subject: [Patches] [Patch #100803] puremodule: ANSI-fication (UNTESTED!)
Message-ID: <200007311630.JAA13381@delerium.i.sourceforge.net>

Patch #100803 has been updated. 

Project: 
Category: None
Status: Open
Summary: puremodule: ANSI-fication (UNTESTED!)

Follow-Ups:

Date: 2000-Jul-10 10:16
By: nowonder

Comment:
cannot test this, maybe Barry can
-------------------------------------------------------

Date: 2000-Jul-31 01:46
By: nowonder

Comment:
should I just check it in? Did you get around to review it?
-------------------------------------------------------

Date: 2000-Jul-31 09:30
By: bwarsaw

Comment:
There's one typo in nowonder's patch.  Here's a fixed version of the patch (unified).  This compiles but doesn't link.  I can't tell if this is caused by a problem with the purify stub libraries.

Meta note: because this is a commercial product which it seems no one has access to anymore, should we continue to support it in the standard distribution?
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=100803&group_id=5470


From noreply@sourceforge.net  Mon Jul 31 17:31:18 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 31 Jul 2000 09:31:18 -0700
Subject: [Patches] [Patch #100884] arraymodule: adding count, extend, index, pop, remove
Message-ID: <200007311631.JAA14533@bush.i.sourceforge.net>

Patch #100884 has been updated. 

Project: 
Category: None
Status: Open
Summary: arraymodule: adding count, extend, index, pop, remove

Follow-Ups:

Date: 2000-Jul-31 01:45
By: nowonder

Comment:
needs reviewing. includes test and documentation update. works fine on all tests.
-------------------------------------------------------

Date: 2000-Jul-31 06:30
By: gvanrossum

Comment:
Rejected: the idea is good, but the code buggy:

- getarrayitem() returns a new reference, so you must DECREF it after using the value (except the one place where you INCREF it unnecessarily)

- PyErr_BadArgument() is a poor diagnostic for extend() with an array of the wrong kind.

Please fix the patch and resubmit!
-------------------------------------------------------

Date: 2000-Jul-31 06:37
By: fdrake

Comment:
The documentation update looks fine to me.
The methods in the C module should use PyArg_ParseTuple() instead of PyArg_Parse(); there's rarely a good reason to use the older version, and the _ParseTuple() version allows the function nam e to be included in the error messages.
(Plus Guido's comments need to be addressed.)
-------------------------------------------------------

Date: 2000-Jul-31 09:08
By: nowonder

Comment:
changed _parse to _parsetuple

hopefully fixed refcounting (my first try at that)
-------------------------------------------------------

Date: 2000-Jul-31 09:31
By: fdrake

Comment:
Please don't hard code magic numbers in the methods table; use METH_VARARGS instead of 1.

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

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=100884&group_id=5470


From thomas@xs4all.net  Mon Jul 31 17:36:24 2000
From: thomas@xs4all.net (Thomas Wouters)
Date: Mon, 31 Jul 2000 18:36:24 +0200
Subject: [Patches] [Patch #100853] merging my*.h into pyport.h
In-Reply-To: <200007311516.IAA10645@delerium.i.sourceforge.net>; from noreply@sourceforge.net on Mon, Jul 31, 2000 at 08:16:32AM -0700
References: <200007311516.IAA10645@delerium.i.sourceforge.net>
Message-ID: <20000731183624.M266@xs4all.nl>

On Mon, Jul 31, 2000 at 08:16:32AM -0700, noreply@sourceforge.net wrote:

> Date: 2000-Jul-31 08:16
> By: marangoz
> 
> Comment:
> Feedback: I'm not thrilled by the fact that Python interfaces are defined
> in pyport.h. Defining only the ANY & _Mem_EXTRA compatibility issues
> is fine, but official PyMem_ interfaces is not so fine.
> 
> I'd prefer a separate .h file, be it mymalloc.h or pymalloc.h.

Agreed: pyport.h should be for platform dependant things: prototypes that
should be in standard include files, features/macros that are necessary on
some systems, etc. mymalloc.h should be renamed to pymalloc.h, because it
isn't a local copy of a system interface, but rather a seperate interface
that happens to mirror a well-known one, but can be implemented however one
wishes. It's Python's Memory Allocator ;-)

-- 
Thomas Wouters <thomas@xs4all.net>

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


From noreply@sourceforge.net  Mon Jul 31 17:38:03 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 31 Jul 2000 09:38:03 -0700
Subject: [Patches] [Patch #100853] merging my*.h into pyport.h
Message-ID: <200007311638.JAA13711@delerium.i.sourceforge.net>

Patch #100853 has been updated. 

Project: 
Category: core (C code)
Status: Accepted
Summary: merging my*.h into pyport.h

Follow-Ups:

Date: 2000-Jul-11 09:34
By: gvanrossum

Comment:
Python.h already includes pyport.h, so you can eliminate all those #import pyport.h from the .c files. (Not from *all* C files, because a few may not include Python.h, but the majority do.)

Also, please ask Jack Jansen to see if  SYMANTEC_FFM68K and MC68K and other Mac symbols are still wanted.

Maybe much of the Mac-specific madness could be collected in a separate file included only #ifdef macintosh?
-------------------------------------------------------

Date: 2000-Jul-11 09:43
By: gvanrossum

Comment:
Also, you can delete the my*.h files (if indeed there are no references to them any more in the Python core source code).
-------------------------------------------------------

Date: 2000-Jul-11 15:45
By: nowonder

Comment:
Okay, I'll rework the patch. May take some time. Have to do some real work in between python sessions <wink>.
-------------------------------------------------------

Date: 2000-Jul-27 13:29
By: gvanrossum

Comment:
So, it's been a few weeks.  Do you still want to do this?
-------------------------------------------------------

Date: 2000-Jul-28 02:00
By: nowonder

Comment:
Yes. I just wanted to wait until Thomas has dealt with that platform specific clutter.

It's on my list for next week. Maybe that means I'll do something about it ...
-------------------------------------------------------

Date: 2000-Jul-31 01:40
By: nowonder

Comment:
reworked the patch. please review it.
-------------------------------------------------------

Date: 2000-Jul-31 08:02
By: gvanrossum

Comment:
Works for me, and looks pretty innocent.

Check it in so we get some more feedback!
-------------------------------------------------------

Date: 2000-Jul-31 08:16
By: marangoz

Comment:
Feedback: I'm not thrilled by the fact that Python interfaces are defined
in pyport.h. Defining only the ANY & _Mem_EXTRA compatibility issues
is fine, but official PyMem_ interfaces is not so fine.

I'd prefer a separate .h file, be it mymalloc.h or pymalloc.h.
-------------------------------------------------------

Date: 2000-Jul-31 09:20
By: nowonder

Comment:
I like pymalloc.h.

Could you (Vladimir) or anybody else with some understanding of this piece of code seperate the compatibility stuff from the interfaces?

I could only guess.
-------------------------------------------------------

Date: 2000-Jul-31 09:23
By: marangoz

Comment:
Include/pymem.h is a better suggestion.

pymem.h should include everything starting from the comment
/* Core memory allocator */

and should include: "pyport.h" and "config.h"
where NEED_TO_DECLARE_MALLOC_AND_FRIENDS is defined.
So the current state is clearly unacceptable, because pyport.h
does not include config.h

Also, if someone wants to redefine the core malloc
(cf. the macros) it should be able to do it from configure.

If Guido doesn't object (and I just received his request for
comments from me), could you please revamp this and take
into account the above suggestions. Otherwise, I'll submit
another patch.

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

Date: 2000-Jul-31 09:38
By: marangoz

Comment:
pyport.h needs to include config.h -- imperative.
Most defines used in pyport.h are in config.h.
Thus pymem.h/pymalloc.h would only include "pyport.h"
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=100853&group_id=5470


From noreply@sourceforge.net  Mon Jul 31 17:39:35 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 31 Jul 2000 09:39:35 -0700
Subject: [Patches] [Patch #100853] merging my*.h into pyport.h
Message-ID: <200007311639.JAA13755@delerium.i.sourceforge.net>

Patch #100853 has been updated. 

Project: 
Category: core (C code)
Status: Open
Summary: merging my*.h into pyport.h

Follow-Ups:

Date: 2000-Jul-11 09:34
By: gvanrossum

Comment:
Python.h already includes pyport.h, so you can eliminate all those #import pyport.h from the .c files. (Not from *all* C files, because a few may not include Python.h, but the majority do.)

Also, please ask Jack Jansen to see if  SYMANTEC_FFM68K and MC68K and other Mac symbols are still wanted.

Maybe much of the Mac-specific madness could be collected in a separate file included only #ifdef macintosh?
-------------------------------------------------------

Date: 2000-Jul-11 09:43
By: gvanrossum

Comment:
Also, you can delete the my*.h files (if indeed there are no references to them any more in the Python core source code).
-------------------------------------------------------

Date: 2000-Jul-11 15:45
By: nowonder

Comment:
Okay, I'll rework the patch. May take some time. Have to do some real work in between python sessions <wink>.
-------------------------------------------------------

Date: 2000-Jul-27 13:29
By: gvanrossum

Comment:
So, it's been a few weeks.  Do you still want to do this?
-------------------------------------------------------

Date: 2000-Jul-28 02:00
By: nowonder

Comment:
Yes. I just wanted to wait until Thomas has dealt with that platform specific clutter.

It's on my list for next week. Maybe that means I'll do something about it ...
-------------------------------------------------------

Date: 2000-Jul-31 01:40
By: nowonder

Comment:
reworked the patch. please review it.
-------------------------------------------------------

Date: 2000-Jul-31 08:02
By: gvanrossum

Comment:
Works for me, and looks pretty innocent.

Check it in so we get some more feedback!
-------------------------------------------------------

Date: 2000-Jul-31 08:16
By: marangoz

Comment:
Feedback: I'm not thrilled by the fact that Python interfaces are defined
in pyport.h. Defining only the ANY & _Mem_EXTRA compatibility issues
is fine, but official PyMem_ interfaces is not so fine.

I'd prefer a separate .h file, be it mymalloc.h or pymalloc.h.
-------------------------------------------------------

Date: 2000-Jul-31 09:20
By: nowonder

Comment:
I like pymalloc.h.

Could you (Vladimir) or anybody else with some understanding of this piece of code seperate the compatibility stuff from the interfaces?

I could only guess.
-------------------------------------------------------

Date: 2000-Jul-31 09:23
By: marangoz

Comment:
Include/pymem.h is a better suggestion.

pymem.h should include everything starting from the comment
/* Core memory allocator */

and should include: "pyport.h" and "config.h"
where NEED_TO_DECLARE_MALLOC_AND_FRIENDS is defined.
So the current state is clearly unacceptable, because pyport.h
does not include config.h

Also, if someone wants to redefine the core malloc
(cf. the macros) it should be able to do it from configure.

If Guido doesn't object (and I just received his request for
comments from me), could you please revamp this and take
into account the above suggestions. Otherwise, I'll submit
another patch.

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

Date: 2000-Jul-31 09:38
By: marangoz

Comment:
pyport.h needs to include config.h -- imperative.
Most defines used in pyport.h are in config.h.
Thus pymem.h/pymalloc.h would only include "pyport.h"
-------------------------------------------------------

Date: 2000-Jul-31 09:39
By: gvanrossum

Comment:
Once you two agree, assign it back to me for another review and I'll accept it.
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=100853&group_id=5470


From noreply@sourceforge.net  Mon Jul 31 18:22:38 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 31 Jul 2000 10:22:38 -0700
Subject: [Patches] [Patch #100884] arraymodule: adding count, extend, index, pop, remove
Message-ID: <200007311722.KAA15308@delerium.i.sourceforge.net>

Patch #100884 has been updated. 

Project: 
Category: None
Status: Accepted
Summary: arraymodule: adding count, extend, index, pop, remove

Follow-Ups:

Date: 2000-Jul-31 01:45
By: nowonder

Comment:
needs reviewing. includes test and documentation update. works fine on all tests.
-------------------------------------------------------

Date: 2000-Jul-31 06:30
By: gvanrossum

Comment:
Rejected: the idea is good, but the code buggy:

- getarrayitem() returns a new reference, so you must DECREF it after using the value (except the one place where you INCREF it unnecessarily)

- PyErr_BadArgument() is a poor diagnostic for extend() with an array of the wrong kind.

Please fix the patch and resubmit!
-------------------------------------------------------

Date: 2000-Jul-31 06:37
By: fdrake

Comment:
The documentation update looks fine to me.
The methods in the C module should use PyArg_ParseTuple() instead of PyArg_Parse(); there's rarely a good reason to use the older version, and the _ParseTuple() version allows the function nam e to be included in the error messages.
(Plus Guido's comments need to be addressed.)
-------------------------------------------------------

Date: 2000-Jul-31 09:08
By: nowonder

Comment:
changed _parse to _parsetuple

hopefully fixed refcounting (my first try at that)
-------------------------------------------------------

Date: 2000-Jul-31 09:31
By: fdrake

Comment:
Please don't hard code magic numbers in the methods table; use METH_VARARGS instead of 1.

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

Date: 2000-Jul-31 10:22
By: gvanrossum

Comment:
Thanks -- accepted now.  Thanks for the quick turn around!

Nit: the error messages for extend() refer to append -- I'd prefer these to use the verb "extend" just to be clear.

Go check it in!
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=100884&group_id=5470


From noreply@sourceforge.net  Mon Jul 31 18:30:46 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 31 Jul 2000 10:30:46 -0700
Subject: [Patches] [Patch #100803] puremodule: ANSI-fication (UNTESTED!)
Message-ID: <200007311730.KAA15549@delerium.i.sourceforge.net>

Patch #100803 has been updated. 

Project: 
Category: None
Status: Postponed
Summary: puremodule: ANSI-fication (UNTESTED!)

Follow-Ups:

Date: 2000-Jul-10 10:16
By: nowonder

Comment:
cannot test this, maybe Barry can
-------------------------------------------------------

Date: 2000-Jul-31 01:46
By: nowonder

Comment:
should I just check it in? Did you get around to review it?
-------------------------------------------------------

Date: 2000-Jul-31 09:30
By: bwarsaw

Comment:
There's one typo in nowonder's patch.  Here's a fixed version of the patch (unified).  This compiles but doesn't link.  I can't tell if this is caused by a problem with the purify stub libraries.

Meta note: because this is a commercial product which it seems no one has access to anymore, should we continue to support it in the standard distribution?
-------------------------------------------------------

Date: 2000-Jul-31 10:30
By: gvanrossum

Comment:
Since no-one can test this, let's be conservative and not check it in.
There's no absolute requirement to move *everything* to ANSI.
Since we know the old version worked, we should leave it alone.
I vote to keep this in the distribution -- maybe someone else can use it.

If someone else can confirm that it in fact works (or make it work) I'd be happy to accept the patch at that point.
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=100803&group_id=5470


From noreply@sourceforge.net  Mon Jul 31 18:50:10 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 31 Jul 2000 10:50:10 -0700
Subject: [Patches] [Patch #101022] Removal of SET_LINENO (experimental)
Message-ID: <200007311750.KAA17434@bush.i.sourceforge.net>

Patch #101022 has been updated. 

Project: 
Category: core (C code)
Status: Postponed
Summary: Removal of SET_LINENO (experimental)

Follow-Ups:

Date: 2000-Jul-30 16:12
By: marangoz

Comment:
For testing, as discussed on python-dev. For a gentle summary, see:
http://www.python.org/pipermail/python-dev/2000-July/014364.html

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

Date: 2000-Jul-30 18:16
By: marangoz

Comment:
A nit: inline the argfetch in CALL_TRACE and goto the switch,
instead of jumping to get_oparg which splits the sequence
[fetch opcode, fetch oparg] -- this can slow things down.

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

Date: 2000-Jul-31 06:40
By: gvanrossum

Comment:
Status set to postponed to indicate that this is still experimental.
-------------------------------------------------------

Date: 2000-Jul-31 07:57
By: marangoz

Comment:
Another rewrite, making this whole strategy b/w compatible according to
the 1st incompatibility point a) described in: http://www.python.org/pipermail/python-dev/2000-July/014364.html

Changes:

1. f.f_lineno is computed and updated on f_lineno attribute requests for
   f, given f.f_lasti. Correctness is ensured because f.f_lasti is updated
   on *all* attribute accesses (in LOAD_ATTR in the main loop).

2. The standard setup does not generate SET_LINENO, but uses
   co_lnotab for computing the source line number (e.g. tracebacks)
   This is equivalent to the actual "python -O".

3. With "python -d", we fall back to the current version of the
   interpreter (with SET_LINENO) thus making it easy to test whether
   this patch fully replaces SET_LINENO's behavior.
   (modulo f->f_lineno accesses from legacy C code, but this is insane).

IMO, this version already worths the pain to be truly tested and improved.

One improvement is to define a nicer public C API for breakpoints:
 - PyCode_SetBreakPointAtLine(line)
 - PyCode_SetBreakPointAtAddr(addr)
or similar, which would install a CALL_TRACE opcode in the appropriate
location of the copy of co_code.

Another idea is to avoid duplicating the entire co_code just for storing
the CALL_TRACE opcodes. We can store them in the original and keep
a table of breakpoints. Setting the breakpoints would occur whenever
the sys.settrace hook is set.
-------------------------------------------------------

Date: 2000-Jul-31 10:50
By: marangoz

Comment:
A last tiny fix of the SET_LINENO opcode for better b/w compatibility.
Stopping here and entering standby mode for reactions & feedback.

PS: the last idea about not duplicating co_code and tweaking the
original with CALL_TRACE is a bad one. I remember Guido being
against it because co_code could be used elsewhere (copied, written
to disk, whatever) and he's right! Better operate on an internal copy
created in ceval.
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=101022&group_id=5470


From noreply@sourceforge.net  Mon Jul 31 18:55:54 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 31 Jul 2000 10:55:54 -0700
Subject: [Patches] [Patch #101030] new zip() builtin
Message-ID: <200007311755.KAA17620@bush.i.sourceforge.net>

Patch #101030 has been updated. 

Project: 
Category: core (C code)
Status: Open
Summary: new zip() builtin

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=101030&group_id=5470


From noreply@sourceforge.net  Mon Jul 31 19:00:18 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 31 Jul 2000 11:00:18 -0700
Subject: [Patches] [Patch #101030] new zip() builtin
Message-ID: <200007311800.LAA16622@delerium.i.sourceforge.net>

Patch #101030 has been updated. 

Project: 
Category: core (C code)
Status: Open
Summary: new zip() builtin

Follow-Ups:

Date: 2000-Jul-31 11:00
By: gvanrossum

Comment:
I won't even look at this until you've supplied a test_zip.py module. :-)
Fred will probably like a doc patch, too...
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=101030&group_id=5470


From noreply@sourceforge.net  Mon Jul 31 19:27:40 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 31 Jul 2000 11:27:40 -0700
Subject: [Patches] [Patch #101030] new zip() builtin
Message-ID: <200007311827.LAA18679@bush.i.sourceforge.net>

Patch #101030 has been updated. 

Project: 
Category: core (C code)
Status: Open
Summary: new zip() builtin

Follow-Ups:

Date: 2000-Jul-31 11:00
By: gvanrossum

Comment:
I won't even look at this until you've supplied a test_zip.py module. :-)
Fred will probably like a doc patch, too...
-------------------------------------------------------

Date: 2000-Jul-31 11:27
By: bwarsaw

Comment:
regr test and doc patches added
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=101030&group_id=5470


From noreply@sourceforge.net  Mon Jul 31 19:27:46 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 31 Jul 2000 11:27:46 -0700
Subject: [Patches] [Patch #100979] support for out-of-tree "make TAGS"
Message-ID: <200007311827.LAA18683@bush.i.sourceforge.net>

Patch #100979 has been updated. 

Project: 
Category: None
Status: Closed
Summary: support for out-of-tree "make TAGS"

Follow-Ups:

Date: 2000-Jul-25 10:24
By: mwh

Comment:
this (dead simple!) patch lets "make TAGS" work when $(srcdir) != "." (which funnily enough is how I do it...).

"make tags" now fails with

$ make tags
ctags -w -t ../src/Include/*.h
ctags: Unknown option: -t

... but I don't know what the correct fix is (just remove the "-t"?)
-------------------------------------------------------

Date: 2000-Jul-25 13:51
By: gvanrossum

Comment:
Hm.  I thought, just what I need, because my build directory is also in a different place as my source directory. But it turns out I want my TAGS file in the source directory! So now I'm indifferent on this.

The "make tags" works for me -- maybe you have a nonstandard ctags?

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

Date: 2000-Jul-31 11:27
By: gvanrossum

Comment:
I checked in a slightly different version, which uses 'cd $(srcdir)'.
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=100979&group_id=5470


From noreply@sourceforge.net  Mon Jul 31 19:36:43 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 31 Jul 2000 11:36:43 -0700
Subject: [Patches] [Patch #100853] merging my*.h into pyport.h
Message-ID: <200007311836.LAA17853@delerium.i.sourceforge.net>

Patch #100853 has been updated. 

Project: 
Category: core (C code)
Status: Open
Summary: merging my*.h into pyport.h

Follow-Ups:

Date: 2000-Jul-11 09:34
By: gvanrossum

Comment:
Python.h already includes pyport.h, so you can eliminate all those #import pyport.h from the .c files. (Not from *all* C files, because a few may not include Python.h, but the majority do.)

Also, please ask Jack Jansen to see if  SYMANTEC_FFM68K and MC68K and other Mac symbols are still wanted.

Maybe much of the Mac-specific madness could be collected in a separate file included only #ifdef macintosh?
-------------------------------------------------------

Date: 2000-Jul-11 09:43
By: gvanrossum

Comment:
Also, you can delete the my*.h files (if indeed there are no references to them any more in the Python core source code).
-------------------------------------------------------

Date: 2000-Jul-11 15:45
By: nowonder

Comment:
Okay, I'll rework the patch. May take some time. Have to do some real work in between python sessions <wink>.
-------------------------------------------------------

Date: 2000-Jul-27 13:29
By: gvanrossum

Comment:
So, it's been a few weeks.  Do you still want to do this?
-------------------------------------------------------

Date: 2000-Jul-28 02:00
By: nowonder

Comment:
Yes. I just wanted to wait until Thomas has dealt with that platform specific clutter.

It's on my list for next week. Maybe that means I'll do something about it ...
-------------------------------------------------------

Date: 2000-Jul-31 01:40
By: nowonder

Comment:
reworked the patch. please review it.
-------------------------------------------------------

Date: 2000-Jul-31 08:02
By: gvanrossum

Comment:
Works for me, and looks pretty innocent.

Check it in so we get some more feedback!
-------------------------------------------------------

Date: 2000-Jul-31 08:16
By: marangoz

Comment:
Feedback: I'm not thrilled by the fact that Python interfaces are defined
in pyport.h. Defining only the ANY & _Mem_EXTRA compatibility issues
is fine, but official PyMem_ interfaces is not so fine.

I'd prefer a separate .h file, be it mymalloc.h or pymalloc.h.
-------------------------------------------------------

Date: 2000-Jul-31 09:20
By: nowonder

Comment:
I like pymalloc.h.

Could you (Vladimir) or anybody else with some understanding of this piece of code seperate the compatibility stuff from the interfaces?

I could only guess.
-------------------------------------------------------

Date: 2000-Jul-31 09:23
By: marangoz

Comment:
Include/pymem.h is a better suggestion.

pymem.h should include everything starting from the comment
/* Core memory allocator */

and should include: "pyport.h" and "config.h"
where NEED_TO_DECLARE_MALLOC_AND_FRIENDS is defined.
So the current state is clearly unacceptable, because pyport.h
does not include config.h

Also, if someone wants to redefine the core malloc
(cf. the macros) it should be able to do it from configure.

If Guido doesn't object (and I just received his request for
comments from me), could you please revamp this and take
into account the above suggestions. Otherwise, I'll submit
another patch.

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

Date: 2000-Jul-31 09:38
By: marangoz

Comment:
pyport.h needs to include config.h -- imperative.
Most defines used in pyport.h are in config.h.
Thus pymem.h/pymalloc.h would only include "pyport.h"
-------------------------------------------------------

Date: 2000-Jul-31 09:39
By: gvanrossum

Comment:
Once you two agree, assign it back to me for another review and I'll accept it.
-------------------------------------------------------

Date: 2000-Jul-31 11:36
By: nowonder

Comment:
okay, this puts all the stuff into pymem.h! Some questions remain for me:

- should I include both "pyport.h" and "pymem.h" in Python.h (and pgenheaders.h)?
- isn't pymalloc a much nicer nime? like PYthon Memory ALLOCator

... gone volleyballing ...
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=100853&group_id=5470


From noreply@sourceforge.net  Mon Jul 31 19:38:33 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 31 Jul 2000 11:38:33 -0700
Subject: [Patches] [Patch #101030] new zip() builtin
Message-ID: <200007311838.LAA19169@bush.i.sourceforge.net>

Patch #101030 has been updated. 

Project: 
Category: core (C code)
Status: Accepted
Summary: new zip() builtin

Follow-Ups:

Date: 2000-Jul-31 11:00
By: gvanrossum

Comment:
I won't even look at this until you've supplied a test_zip.py module. :-)
Fred will probably like a doc patch, too...
-------------------------------------------------------

Date: 2000-Jul-31 11:27
By: bwarsaw

Comment:
regr test and doc patches added
-------------------------------------------------------

Date: 2000-Jul-31 11:38
By: gvanrossum

Comment:
Great!

Note a minor bug in the test suite: exc=1 should only be set in the two except TypeError clauses, not in the mail try clauses!  (After all you want it to raise an exception, so falling through the main clause is an *error*.)
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=101030&group_id=5470


From noreply@sourceforge.net  Mon Jul 31 19:41:10 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 31 Jul 2000 11:41:10 -0700
Subject: [Patches] [Patch #100853] merging my*.h into pyport.h
Message-ID: <200007311841.LAA19229@bush.i.sourceforge.net>

Patch #100853 has been updated. 

Project: 
Category: core (C code)
Status: Accepted
Summary: merging my*.h into pyport.h

Follow-Ups:

Date: 2000-Jul-11 09:34
By: gvanrossum

Comment:
Python.h already includes pyport.h, so you can eliminate all those #import pyport.h from the .c files. (Not from *all* C files, because a few may not include Python.h, but the majority do.)

Also, please ask Jack Jansen to see if  SYMANTEC_FFM68K and MC68K and other Mac symbols are still wanted.

Maybe much of the Mac-specific madness could be collected in a separate file included only #ifdef macintosh?
-------------------------------------------------------

Date: 2000-Jul-11 09:43
By: gvanrossum

Comment:
Also, you can delete the my*.h files (if indeed there are no references to them any more in the Python core source code).
-------------------------------------------------------

Date: 2000-Jul-11 15:45
By: nowonder

Comment:
Okay, I'll rework the patch. May take some time. Have to do some real work in between python sessions <wink>.
-------------------------------------------------------

Date: 2000-Jul-27 13:29
By: gvanrossum

Comment:
So, it's been a few weeks.  Do you still want to do this?
-------------------------------------------------------

Date: 2000-Jul-28 02:00
By: nowonder

Comment:
Yes. I just wanted to wait until Thomas has dealt with that platform specific clutter.

It's on my list for next week. Maybe that means I'll do something about it ...
-------------------------------------------------------

Date: 2000-Jul-31 01:40
By: nowonder

Comment:
reworked the patch. please review it.
-------------------------------------------------------

Date: 2000-Jul-31 08:02
By: gvanrossum

Comment:
Works for me, and looks pretty innocent.

Check it in so we get some more feedback!
-------------------------------------------------------

Date: 2000-Jul-31 08:16
By: marangoz

Comment:
Feedback: I'm not thrilled by the fact that Python interfaces are defined
in pyport.h. Defining only the ANY & _Mem_EXTRA compatibility issues
is fine, but official PyMem_ interfaces is not so fine.

I'd prefer a separate .h file, be it mymalloc.h or pymalloc.h.
-------------------------------------------------------

Date: 2000-Jul-31 09:20
By: nowonder

Comment:
I like pymalloc.h.

Could you (Vladimir) or anybody else with some understanding of this piece of code seperate the compatibility stuff from the interfaces?

I could only guess.
-------------------------------------------------------

Date: 2000-Jul-31 09:23
By: marangoz

Comment:
Include/pymem.h is a better suggestion.

pymem.h should include everything starting from the comment
/* Core memory allocator */

and should include: "pyport.h" and "config.h"
where NEED_TO_DECLARE_MALLOC_AND_FRIENDS is defined.
So the current state is clearly unacceptable, because pyport.h
does not include config.h

Also, if someone wants to redefine the core malloc
(cf. the macros) it should be able to do it from configure.

If Guido doesn't object (and I just received his request for
comments from me), could you please revamp this and take
into account the above suggestions. Otherwise, I'll submit
another patch.

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

Date: 2000-Jul-31 09:38
By: marangoz

Comment:
pyport.h needs to include config.h -- imperative.
Most defines used in pyport.h are in config.h.
Thus pymem.h/pymalloc.h would only include "pyport.h"
-------------------------------------------------------

Date: 2000-Jul-31 09:39
By: gvanrossum

Comment:
Once you two agree, assign it back to me for another review and I'll accept it.
-------------------------------------------------------

Date: 2000-Jul-31 11:36
By: nowonder

Comment:
okay, this puts all the stuff into pymem.h! Some questions remain for me:

- should I include both "pyport.h" and "pymem.h" in Python.h (and pgenheaders.h)?
- isn't pymalloc a much nicer nime? like PYthon Memory ALLOCator

... gone volleyballing ...
-------------------------------------------------------

Date: 2000-Jul-31 11:41
By: gvanrossum

Comment:
Since it's Vladimir's code and he prefers pymem.h, let's do that.
Check it in!
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=100853&group_id=5470


From noreply@sourceforge.net  Mon Jul 31 21:05:40 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 31 Jul 2000 13:05:40 -0700
Subject: [Patches] [Patch #100853] merging my*.h into pyport.h
Message-ID: <200007312005.NAA22318@bush.i.sourceforge.net>

Patch #100853 has been updated. 

Project: 
Category: core (C code)
Status: Accepted
Summary: merging my*.h into pyport.h

Follow-Ups:

Date: 2000-Jul-11 09:34
By: gvanrossum

Comment:
Python.h already includes pyport.h, so you can eliminate all those #import pyport.h from the .c files. (Not from *all* C files, because a few may not include Python.h, but the majority do.)

Also, please ask Jack Jansen to see if  SYMANTEC_FFM68K and MC68K and other Mac symbols are still wanted.

Maybe much of the Mac-specific madness could be collected in a separate file included only #ifdef macintosh?
-------------------------------------------------------

Date: 2000-Jul-11 09:43
By: gvanrossum

Comment:
Also, you can delete the my*.h files (if indeed there are no references to them any more in the Python core source code).
-------------------------------------------------------

Date: 2000-Jul-11 15:45
By: nowonder

Comment:
Okay, I'll rework the patch. May take some time. Have to do some real work in between python sessions <wink>.
-------------------------------------------------------

Date: 2000-Jul-27 13:29
By: gvanrossum

Comment:
So, it's been a few weeks.  Do you still want to do this?
-------------------------------------------------------

Date: 2000-Jul-28 02:00
By: nowonder

Comment:
Yes. I just wanted to wait until Thomas has dealt with that platform specific clutter.

It's on my list for next week. Maybe that means I'll do something about it ...
-------------------------------------------------------

Date: 2000-Jul-31 01:40
By: nowonder

Comment:
reworked the patch. please review it.
-------------------------------------------------------

Date: 2000-Jul-31 08:02
By: gvanrossum

Comment:
Works for me, and looks pretty innocent.

Check it in so we get some more feedback!
-------------------------------------------------------

Date: 2000-Jul-31 08:16
By: marangoz

Comment:
Feedback: I'm not thrilled by the fact that Python interfaces are defined
in pyport.h. Defining only the ANY & _Mem_EXTRA compatibility issues
is fine, but official PyMem_ interfaces is not so fine.

I'd prefer a separate .h file, be it mymalloc.h or pymalloc.h.
-------------------------------------------------------

Date: 2000-Jul-31 09:20
By: nowonder

Comment:
I like pymalloc.h.

Could you (Vladimir) or anybody else with some understanding of this piece of code seperate the compatibility stuff from the interfaces?

I could only guess.
-------------------------------------------------------

Date: 2000-Jul-31 09:23
By: marangoz

Comment:
Include/pymem.h is a better suggestion.

pymem.h should include everything starting from the comment
/* Core memory allocator */

and should include: "pyport.h" and "config.h"
where NEED_TO_DECLARE_MALLOC_AND_FRIENDS is defined.
So the current state is clearly unacceptable, because pyport.h
does not include config.h

Also, if someone wants to redefine the core malloc
(cf. the macros) it should be able to do it from configure.

If Guido doesn't object (and I just received his request for
comments from me), could you please revamp this and take
into account the above suggestions. Otherwise, I'll submit
another patch.

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

Date: 2000-Jul-31 09:38
By: marangoz

Comment:
pyport.h needs to include config.h -- imperative.
Most defines used in pyport.h are in config.h.
Thus pymem.h/pymalloc.h would only include "pyport.h"
-------------------------------------------------------

Date: 2000-Jul-31 09:39
By: gvanrossum

Comment:
Once you two agree, assign it back to me for another review and I'll accept it.
-------------------------------------------------------

Date: 2000-Jul-31 11:36
By: nowonder

Comment:
okay, this puts all the stuff into pymem.h! Some questions remain for me:

- should I include both "pyport.h" and "pymem.h" in Python.h (and pgenheaders.h)?
- isn't pymalloc a much nicer nime? like PYthon Memory ALLOCator

... gone volleyballing ...
-------------------------------------------------------

Date: 2000-Jul-31 11:41
By: gvanrossum

Comment:
Since it's Vladimir's code and he prefers pymem.h, let's do that.
Check it in!
-------------------------------------------------------

Date: 2000-Jul-31 13:05
By: marangoz

Comment:
Sure, except that Peter went on playing volleyball and I can't update
my CVS copy for an hour in order to checkin a slightly modified version
which adds some missing dependencies. Since I am leaving too, I have
put my version on the web, in case someone wants to check that for
Peter & me in the meantime:
http://sirac.inrialpes.fr/~marangoz/tmp/h-patch
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=100853&group_id=5470


From noreply@sourceforge.net  Mon Jul 31 22:35:43 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 31 Jul 2000 14:35:43 -0700
Subject: [Patches] [Patch #101029] Call __getitem__ for slices when no __getslice__
Message-ID: <200007312135.OAA25852@bush.i.sourceforge.net>

Patch #101029 has been updated. 

Project: 
Category: core (C code)
Status: Open
Summary: Call __getitem__ for slices when no __getslice__

Follow-Ups:

Date: 2000-Jul-31 06:55
By: twouters

Comment:
Call __getitem__ if no __getslice__ is available. similar for __delslice__ and __setslice__, and for the C API: calls mp_subscript() with a slice object of (start, end, None) if there is no sq_slice(), and the same for sq_ass_slice().

Eventually the reverse should be done, too: call __getslice__ instead of __getitem__ if the object has a __getslice__, and the 3rd argument to the slice is None: That way, we can ditch the 12 silly SLICE* opcodes, and always use slice objects. This *will* result in x[::] being passed to __getslice__ (if available) instead of __getitem__, however, so it is not 100% backwards compatible.

This patch is not terribly tested: I'm not feeling well, and I want to post this patch before I head off to home and dive back in bed ;) It doesn't crash, it survives 'make test', it survives manual testing, but it might leak.


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

Date: 2000-Jul-31 07:55
By: gvanrossum

Comment:
Looks cool to me, except that there's a lot of code duplication.

Maybe you can add a static helper routine to create a slice out of two ints to abstract.c and one that creates a 1-tuple containing such a slice to classobject.c.  (Trying to share code across .c files would require turning it into an official API which I think is overkill.)
-------------------------------------------------------

Date: 2000-Jul-31 14:35
By: twouters

Comment:
New version with less code duplication. Less, not none, unfortunately, because both abstract.c and classobject.c need roughly the same function :P Making the classobject.c one return a 1-tuple is not very useful, because only one place needs a 1-tuple, the other needs a 2-tuple, and I don't fancy modifying the 1-tuple separately.

Don't you wish C was more like Python ? *sigh*

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

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=101029&group_id=5470


From noreply@sourceforge.net  Mon Jul 31 23:10:38 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 31 Jul 2000 15:10:38 -0700
Subject: [Patches] [Patch #100884] arraymodule: adding count, extend, index, pop, remove
Message-ID: <200007312210.PAA25774@delerium.i.sourceforge.net>

Patch #100884 has been updated. 

Project: 
Category: None
Status: Closed
Summary: arraymodule: adding count, extend, index, pop, remove

Follow-Ups:

Date: 2000-Jul-31 01:45
By: nowonder

Comment:
needs reviewing. includes test and documentation update. works fine on all tests.
-------------------------------------------------------

Date: 2000-Jul-31 06:30
By: gvanrossum

Comment:
Rejected: the idea is good, but the code buggy:

- getarrayitem() returns a new reference, so you must DECREF it after using the value (except the one place where you INCREF it unnecessarily)

- PyErr_BadArgument() is a poor diagnostic for extend() with an array of the wrong kind.

Please fix the patch and resubmit!
-------------------------------------------------------

Date: 2000-Jul-31 06:37
By: fdrake

Comment:
The documentation update looks fine to me.
The methods in the C module should use PyArg_ParseTuple() instead of PyArg_Parse(); there's rarely a good reason to use the older version, and the _ParseTuple() version allows the function nam e to be included in the error messages.
(Plus Guido's comments need to be addressed.)
-------------------------------------------------------

Date: 2000-Jul-31 09:08
By: nowonder

Comment:
changed _parse to _parsetuple

hopefully fixed refcounting (my first try at that)
-------------------------------------------------------

Date: 2000-Jul-31 09:31
By: fdrake

Comment:
Please don't hard code magic numbers in the methods table; use METH_VARARGS instead of 1.

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

Date: 2000-Jul-31 10:22
By: gvanrossum

Comment:
Thanks -- accepted now.  Thanks for the quick turn around!

Nit: the error messages for extend() refer to append -- I'd prefer these to use the verb "extend" just to be clear.

Go check it in!
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=100884&group_id=5470


From noreply@sourceforge.net  Mon Jul 31 23:19:46 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 31 Jul 2000 15:19:46 -0700
Subject: [Patches] [Patch #100853] merging my*.h into pyport.h
Message-ID: <200007312219.PAA27450@bush.i.sourceforge.net>

Patch #100853 has been updated. 

Project: 
Category: core (C code)
Status: Closed
Summary: merging my*.h into pyport.h

Follow-Ups:

Date: 2000-Jul-11 09:34
By: gvanrossum

Comment:
Python.h already includes pyport.h, so you can eliminate all those #import pyport.h from the .c files. (Not from *all* C files, because a few may not include Python.h, but the majority do.)

Also, please ask Jack Jansen to see if  SYMANTEC_FFM68K and MC68K and other Mac symbols are still wanted.

Maybe much of the Mac-specific madness could be collected in a separate file included only #ifdef macintosh?
-------------------------------------------------------

Date: 2000-Jul-11 09:43
By: gvanrossum

Comment:
Also, you can delete the my*.h files (if indeed there are no references to them any more in the Python core source code).
-------------------------------------------------------

Date: 2000-Jul-11 15:45
By: nowonder

Comment:
Okay, I'll rework the patch. May take some time. Have to do some real work in between python sessions <wink>.
-------------------------------------------------------

Date: 2000-Jul-27 13:29
By: gvanrossum

Comment:
So, it's been a few weeks.  Do you still want to do this?
-------------------------------------------------------

Date: 2000-Jul-28 02:00
By: nowonder

Comment:
Yes. I just wanted to wait until Thomas has dealt with that platform specific clutter.

It's on my list for next week. Maybe that means I'll do something about it ...
-------------------------------------------------------

Date: 2000-Jul-31 01:40
By: nowonder

Comment:
reworked the patch. please review it.
-------------------------------------------------------

Date: 2000-Jul-31 08:02
By: gvanrossum

Comment:
Works for me, and looks pretty innocent.

Check it in so we get some more feedback!
-------------------------------------------------------

Date: 2000-Jul-31 08:16
By: marangoz

Comment:
Feedback: I'm not thrilled by the fact that Python interfaces are defined
in pyport.h. Defining only the ANY & _Mem_EXTRA compatibility issues
is fine, but official PyMem_ interfaces is not so fine.

I'd prefer a separate .h file, be it mymalloc.h or pymalloc.h.
-------------------------------------------------------

Date: 2000-Jul-31 09:20
By: nowonder

Comment:
I like pymalloc.h.

Could you (Vladimir) or anybody else with some understanding of this piece of code seperate the compatibility stuff from the interfaces?

I could only guess.
-------------------------------------------------------

Date: 2000-Jul-31 09:23
By: marangoz

Comment:
Include/pymem.h is a better suggestion.

pymem.h should include everything starting from the comment
/* Core memory allocator */

and should include: "pyport.h" and "config.h"
where NEED_TO_DECLARE_MALLOC_AND_FRIENDS is defined.
So the current state is clearly unacceptable, because pyport.h
does not include config.h

Also, if someone wants to redefine the core malloc
(cf. the macros) it should be able to do it from configure.

If Guido doesn't object (and I just received his request for
comments from me), could you please revamp this and take
into account the above suggestions. Otherwise, I'll submit
another patch.

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

Date: 2000-Jul-31 09:38
By: marangoz

Comment:
pyport.h needs to include config.h -- imperative.
Most defines used in pyport.h are in config.h.
Thus pymem.h/pymalloc.h would only include "pyport.h"
-------------------------------------------------------

Date: 2000-Jul-31 09:39
By: gvanrossum

Comment:
Once you two agree, assign it back to me for another review and I'll accept it.
-------------------------------------------------------

Date: 2000-Jul-31 11:36
By: nowonder

Comment:
okay, this puts all the stuff into pymem.h! Some questions remain for me:

- should I include both "pyport.h" and "pymem.h" in Python.h (and pgenheaders.h)?
- isn't pymalloc a much nicer nime? like PYthon Memory ALLOCator

... gone volleyballing ...
-------------------------------------------------------

Date: 2000-Jul-31 11:41
By: gvanrossum

Comment:
Since it's Vladimir's code and he prefers pymem.h, let's do that.
Check it in!
-------------------------------------------------------

Date: 2000-Jul-31 13:05
By: marangoz

Comment:
Sure, except that Peter went on playing volleyball and I can't update
my CVS copy for an hour in order to checkin a slightly modified version
which adds some missing dependencies. Since I am leaving too, I have
put my version on the web, in case someone wants to check that for
Peter & me in the meantime:
http://sirac.inrialpes.fr/~marangoz/tmp/h-patch
-------------------------------------------------------

Date: 2000-Jul-31 15:19
By: nowonder

Comment:
this looks good to me. I'll check it in.
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=100853&group_id=5470